From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Thu, 07 Dec 2006 21:56:02 +1100
> Dave, the main point of my initial email was: should we provide a
> routine from the net core to initialize such dummy devices properly ?
> I'm a little worried that some day, the NAPI code will change and the
On Thu, 2006-12-07 at 02:22 -0800, Eugene Surovegin wrote:
> On Thu, Dec 07, 2006 at 02:20:10AM -0800, David Miller wrote:
> > 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
On Thu, Dec 07, 2006 at 02:20:10AM -0800, David Miller wrote:
> 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.
Yes, that's true. That's why I made this parameter
Konfi
From: Eugene Surovegin <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> > Date: Thu, 7 Dec 2006 01:45:02 -0800
> >
> > > I fail to see how this is not even more ugly and more c
On Thu, Dec 07, 2006 at 01:59:54AM -0800, David Miller wrote:
> From: Eugene Surovegin <[EMAIL PROTECTED]>
> 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
>
From: Eugene Surovegin <[EMAIL PROTECTED]>
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
> dynami
On Thu, Dec 07, 2006 at 01:16:27AM -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Thu, 07 Dec 2006 15:24:06 +1100
>
> >
> > > What Eugene does currently, which seems to me like it's actually the
> > > only proper solution, is to create a separate net_device
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Thu, 07 Dec 2006 15:24:06 +1100
>
> > What Eugene does currently, which seems to me like it's actually the
> > only proper solution, is to create a separate net_device structure for
> > the DMA engine and thus have a single NAPI poll & weight
> What Eugene does currently, which seems to me like it's actually the
> only proper solution, is to create a separate net_device structure for
> the DMA engine and thus have a single NAPI poll & weighting for all the
> EMACs sharing a given MAL (MAL is the name of that DMA engine). This
> means t
