Re: NAPI and shared interrupt control

[David Miller <davem@davemloft.net>]

From: Eugene Surovegin <ebs@ebshome.net>
Date: Thu, 7 Dec 2006 02:15:55 -0800

> On Thu, Dec 07, 2006 at 01:59:54AM -0800, David Miller wrote:
> > From: Eugene Surovegin <ebs@ebshome.net>
> > Date: Thu, 7 Dec 2006 01:45:02 -0800
> > 
> > > I fail to see how this is not even more ugly and more complex than the 
> > > solution we have right now. Instead of trivial "orthogonal" polling 
> > > code you are suggesting adding additional complexity - handle 
> > > dynamic selection of that "master" EMAC and also handling situation 
> > > when this master device goes down and you have to switch to 
> > > another one without disturbing polling for other active devices. Why 
> > > all this? This hw is ugly enough as it is.
> > 
> > Don't do dynamic selection, that indeed would be dumb.
> > 
> > Instead, just pick one of them to act as the polling master.
> > Each EMAC has a backpointer to the master EMAC, and trigger
> > the poll via that indirection.
> 
> Well, dev_close() explicitly checks and modifies state bits related 
> to NAPI polling. From quick look I don't think it's safe to take down 
> "master" device and expect NAPI polling to still work.

Good point.

It also just occured to me that even if you use the dummy device
approach, it's the dummy device's quota that will be used by the
generic ->poll() downcall into the driver.