[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4693CEAD.5050900@garzik.org>
Date: Tue, 10 Jul 2007 14:23:41 -0400
From: Jeff Garzik <jeff@...zik.org>
To: "Veeraiyan, Ayyappan" <ayyappan.veeraiyan@...el.com>
CC: netdev@...r.kernel.org, arjan@...ux.intel.com,
akpm@...ux-foundation.org,
"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>, hch@...radead.org,
shemminger@...ux-foundation.org, nhorman@...driver.com,
inaky@...ux.intel.com, mb@...sch.de
Subject: Re: [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters
- Take #2
Veeraiyan, Ayyappan wrote:
> On 7/10/07, Jeff Garzik <jeff@...zik.org> wrote:
>> Ayyappan.Veeraiyan@...el.com wrote:
>>
>> Doing both tends to signal that the author hasn't bothered to measure
>> the differences between various approaches, and pick a clear winner.
>>
>
> I did pick NAPI in our previous submission based on various tests. But
> to get 10Gig line rate we need to use multiple Rx queues which will need
> fake netdevs.. Since fake netdevs weren't acceptable, I added non-NAPI
> support which gets 10Gig line rate with multi-rx. I am ok with removing
> NAPI support till the work of separating the netdevs and NAPI work is
> done..
That sounds fine to me. Separating netdev and NAPI is the right way to
go. Maybe note that in a TODO list at the top of the driver.
> With SW LRO, non-NAPI is better but without LRO, NAPI is better but NAPI
> needs multiple Rx queues. So given the limitations, non-NPAI is my
> preference now.
On the subject of SW LRO: We are really looking for a generic
implementation, hopefully authored by one or more interested parties.
This is something we definitely do not want to reinvent over and over in
new drivers -- and in the one or two drivers it exists today, should be
removed once the generic code is in place.
If Intel could assist with that effort, that would be very helpful.
> I will post the performance numbers later today..
Thanks,
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists