lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ