In message <20050610051334.GH892@bcd.geek.com.au>,
Daniel Carosone writes:

>On Thu, Jun 09, 2005 at 08:59:44PM -0700, Jonathan Stone wrote:
>> Well, the more I think about it, the more I agree Stefan's
>> observation, that the first item to attack is to get a device
>> interrupt on CPU 0 to scehedule a softint on a _different_ CPU.
>
>Yes, not least because of that key word (almost :) 'schedule'.  This
>also directly implies that the softint code is running (largely)
>outside the kernel_lock.

Not really; by `schedule' I meant simply schednetisr().

My intent to handle hardware interrupts on one CPU, and the softnet on
a different. At least one of those _has_ to be outside kernel_lock;
but with supporting machinery like, just for example, Yamamoto-san's
vintage-2003 patch, we could handle the device interrupt outside
kernel_lock, and leave the softnet inside[*].  But -- credit to Stefan
suggested -- with the code structure we have now, that means an IPI
directed to the sofint- target CPU.

Having both outside the kernel_lock would be even better, but (per
discussion with Tonnerre (sp?)), its a nontrivial delta to the
problem.

[*] Modulo a small problem of 3.2 million synchronization
ops, at 10GbE packet rates.

[...]