自旋变体在网络处理中的使用 [英] use of spin variants in network processing

问题描述

我编写了一个与网络过滤器挂钩交互的内核模块. 网络过滤器挂钩在Softirq上下文中运行.

I have written a Kernel module that is interacting with net-filter hooks. The net-filter hooks operate in Softirq context.

我正在访问一个全局数据结构 从softirq上下文以及Process上下文中哈希表" .进程上下文访问是由于 sysctl 文件用于修改哈希表的内容.

I am accessing a global data structure "Hash Table" from the softirq context as well as from Process context. The process context access is due to a sysctl file being used to modify the contents of the Hash-table.

我正在使用spinlock_irq_save.

I am using spinlock_irq_save.

spin_lock api的这种选择正确吗?在性能和锁定标准方面.

如果在另一个处理器上安排了中断，将会发生什么?而当前处理器上的锁已被进程上下文代码所占据?

推荐答案

首先:

因此，通过以上所有详细信息，我得出结论，我的softirq可以在两个内核上同时运行.

So, with all the above details I concluded that my softirqs can run concurrently on both cores.

是的，这是正确的.您的softirq处理程序可能在多个CPU上同时执行".

Yes, this is correct. Your softirq handler may be executed "simultaneously on more than one CPU".

您得出的使用自旋锁的结论对我来说是正确的.但是，这假定关键部分(即在保持自旋锁的情况下执行的部分)具有以下属性:

Your conclusion to use spinlocks sounds correct to me. However, this assumes that the critical section (ie., that which is executed with the spinlock held) has the following properties:

• 它一定不能睡觉(例如，获取一个互斥锁)
• 应该尽可能短

通常，如果您只是更新哈希表，那么在这里应该没问题.

Generally, if you're just updating your hash table, you should be fine here.

如果IRQ处理程序尝试获取由流程上下文持有的自旋锁，那很好.只要您的进程上下文在持有该锁的情况下不会进入睡眠状态，就应在短时间内释放该锁，以使IRQ处理程序能够向前进行.

If an IRQ handler tries to acquire a spinlock that is held by a process context, that's fine. As long as your process context does not sleep with that lock held, the lock should be released within a short amount of time, allowing the IRQ handler to make forward progress.

这篇关于自旋变体在网络处理中的使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！