On 21/05/2013 11:24, Or Gerlitz wrote: > On Tue, May 21, 2013 at 10:14 AM, David Miller <da...@davemloft.net> wrote: >> From: "Eilon Greenstein" <eil...@broadcom.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.) ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
