> Date: Wed, 26 Aug 2015 17:30:14 +0200 > From: Alexandr Nedvedicky <[email protected]> > > Hello, > > I'm not sure I got everything right in Calgary. So this patch should > roughly illustrates how I think we should start moving forward to > make PF MULTIPROCESSOR friendly. It's quite likely my proposal/way > is completely off, I'll be happy if you put me back to ground. > > The brief summary of what patch is trying to achieve is as follows: > > patch trades all splsoftnet() for KERNEL_LOCK() when it gets compiled > with MULTIPROCESSOR option on. > > if MULTIPROCESSOR option is off, the compiler produces PF, which uses > splsoftnet. > > To achieve this the patch introduces macros PF_LOCK()/PF_UNLOCK(), > which expand to KERNEL_LOCK()/KERNEL_UNLOCK(), when MULTIPROCESSOR is > on. > On the other hand if MULTIPROCESSOR is off the PF_*LOCK() macros become > splsoftnet()/splx()
I don't think this will work. Even on MULTIPROCESSOR kernels you'll need to raise the spl to prevent soft interrupts from running on the same CPU. KERNEL_LOCK() will not prevent this from happening as it is a recursive lock. This is why OpenBSD's mutexes (spinning locks) raise the spl. So I think you'll have to define PF_LOCK()/PF_UNLOCK() to do the spl stuff even for MULTIPROCESSOR kernels.
