From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 18:03:38 -0700
> Option c) is obviously a big project but maybe we can get from here to
> there. One possible step in that direction would be exposing a
> standard driver lock that netpoll can see and switching drivers that
> have trouble (bnx2 and tg3 for starters) over to using it.
If this means moving them over to hw IRQ locking, this I totally
cannot agree with. It's a non-starter.
I worked way too hard to eliminate all of the hw IRQ locking from the
tg3 driver. There is no way we'll have it undone for something like
netpoll.
Only using software IRQ locking is the biggest win in net driver
locking strategies we've had in a long time, moving away from this
would be a huge regression. And you can expect more, not less,
drivers to move in this direction because of how much of a win it is.
It means that all of the networking runs in software IRQ context, with
only brief sequences run %100 unlocked in network card interrupt
handlers just to schedule the dev->poll().
As a consequence, it is possible to get very meaningful oprofile
analysis of the entire networking path when the cpu timer interrupt is
the profiling source. And this is only one of several huge gains
to be had from purely software IRQ locking strategies in net drivers.
And as I stated, you absolutely cannot call some drivers
->hard_start_xmit() routine with hw IRQs disabled. It's just not
possible at all. I even tried this myself last year in order to deal
with a seperate locking issue, and it failed miserably. To reiterate:
Drivers need to be able to let things like jiffies
advance in their ->hard_start_xmit() routine. Thus
disabling HW interrupts during ->hard_start_xmit()'s
execution cannot ever be allowed.
All of this points to the fact that network stuff needs to be done
within software IRQ context.
I also do not agree with your assertion that netpoll cannot be useful
if run from software IRQ context. Someone trying to implement block
device based core dumping would run into the same exact issue in the
SCSI layer, which runs command completion from sw IRQs and whose
locking totally depends upon it.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
