netdev - Re: [PATCH NEXT 12/12] netxen: update version to 4.0.41

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] [day] [month] [year] [list]

Message-ID: <4A6E2160.1090704@qlogic.com>
Date:	Mon, 27 Jul 2009 14:51:28 -0700
From:	Dhananjay Phadke <dhananjay.phadke@...gic.com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH NEXT 12/12] netxen: update version to 4.0.41

Agreed that it duplicates work in individual drivers,
and the naming style followed by different vendors.

But the problem is ethtool can work only after driver
has successfully initialized interfaces. Otherwise,
ethtool gets no chance to tune up/down.

The driver defaults are for tuned for typical use cases.
On some frugal systems with lower amount of RAM, the
driver bails out failing to allocate enough ring space
or rx buffers [especially for 32-bit kernels]. This is
also a problem for multi-function (more than one PCI
function per physical port) mode, where number of
interfaces and hence the memory consumption gets
multiplied. For these cases something that can set
the bar before device initialization, is quite helpful.

Thanks,
Dhananjay

David Miller wrote:
> No, it is not good.
> 
> With module parameters we:
> 
> 1) duplicate functionality
> 
> 2) every device driver will name the module parms differently,
>    therefore the interface for the user is different for every device
>    type
> 
> We discuss this all the time, and this is a pretty deep rooted
> belief and requirement for all network drivers.

--
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