On Tue, Sep 06, 2005 at 07:37:45PM -0700, David S. Miller wrote: > 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.
My proposal is for drivers to expose enough internal state in a consistent fashion so that netpoll can avoid lock recursion deadlocks. I don't particularly care how. > 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. That's sounds like a per-driver limitation, albeit likely a very hard one to work around. > 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. ...And that's been tried and does indeed lose most of the time. Which is why it's been abandoned. Think upon the kgdb-over-ethernet case, please. The kernel hits a breakpoint, the kgdb stub stops everything, sends a packet to the debugging client, waits for a packet back.. This simply can't work if we delay send/receive to the next softirq processing. -- Mathematics is the supreme nostalgia of our time. - 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
