linux-kernel - Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll

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: <519B30CE.9020704@linux.intel.com>
Date:	Tue, 21 May 2013 11:31:10 +0300
From:	Eliezer Tamir <eliezer.tamir@...ux.intel.com>
To:	Or Gerlitz <or.gerlitz@...il.com>
CC:	David Miller <davem@...emloft.net>, eilong@...adcom.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	jesse.brandeburg@...el.com, donald.c.skidmore@...el.com,
	e1000-devel@...ts.sourceforge.net, willemb@...gle.com,
	andi@...stfloor.org, hpa@...or.com, eliezer@...ir.org.il
Subject: Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll

On 21/05/2013 11:24, Or Gerlitz wrote:
> On Tue, May 21, 2013 at 10:14 AM, David Miller <davem@...emloft.net> wrote:
>> From: "Eilon Greenstein" <eilong@...adcom.com>
>> Date: Tue, 21 May 2013 10:06:43 +0300
>>
>>> Hopefully this series will be accepted so we can send follow up support
>>> for the bnx2x as well.
>>
>> I think in two or three more iterations it will be merged.
>>
>> There are no objections on the fundamentals, it's just implementation
>> details and coding style at this point.
>
> Dave, sorry, I might be a bit behind the rest of the reviewers, but I
> just fail to understand nor find any reference that explains the
> module param of ixgbe nor it makes sense to me to merge that piece of
> the code upstream (its not for staging, correct?), as I wrote here
> http://marc.info/?l=linux-netdev&m=136908123432072&w=2 basically, I
> know you're not a great fun of module params (to say the least) and
> surely not something named  "allow_unsafe_removal", thoughts?

from v2 0/4

6. To avoid the overhead of reference counting napi structs by skbs
and sockets in the fastpath, and increasing the size of the skb struct,
we no longer allow unloading the module once this feature has been used.

It seems that for most of the people interested in busy-polling, giving
up the ability to blindly remove the module for a slight but measurable
performance gain is a good tradeoff.
(There is a module parameter to override this behavior and if you know
what you are doing and are careful to stop the processes you can safely
unload, but we don't enforce this.)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/