netdev - Re: [PATCH] Make possible speeds known to ethtool

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

Message-ID: <20090109034804.GA11741@gondor.apana.org.au>
Date:	Fri, 9 Jan 2009 14:48:04 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	jgarzik@...ox.com
Cc:	herbert@...dor.apana.org.au, bhutchings@...arflare.com,
	rick.jones2@...com, davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH] Make possible speeds known to ethtool

Jeff Garzik <jgarzik@...ox.com> wrote:
> 
> The person who added this should have used the new flags interface, and 
> added ETH_FLAG_GRO right next to the pre-existing ETH_FLAG_LRO.
> 
> It is incorrect to add new ioctls just to toggle a boolean value.

Well you missed my earlier explanation.  GRO is a stack flag,
it's not something we want the device drivers to touch at all.

The generic flags interface appears to be designed for flags
that the device driver directly controls, such as LRO.  That's
why it is inappropriate for GRO, which like GSO is entirely done
in software.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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