From: Jeff Garzik <jgarzik@pobox.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: bhutchings@solarflare.com, rick.jones2@hp.com,
davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH] Make possible speeds known to ethtool
Date: Thu, 08 Jan 2009 22:58:17 -0500 [thread overview]
Message-ID: <4966CB59.4090202@pobox.com> (raw)
In-Reply-To: <20090109034804.GA11741@gondor.apana.org.au>
Herbert Xu wrote:
> Jeff Garzik <jgarzik@pobox.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.
Nope, the generic flags interface is for any time you have a boolean
flag to control on a per-interface basis.
The generic flags interface was created precisely because it is silly to
keep creating _two_ ethtool sub-ioctls (get, set) just for single
boolean flags.
For generic net stack flags outside the driver's control, that can
easily be added to ethtool_{get,set}_flags() overriding or ignoring
whatever the driver may have done.
Jeff
next prev parent reply other threads:[~2009-01-09 3:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-09 3:48 [PATCH] Make possible speeds known to ethtool Herbert Xu
2009-01-09 3:58 ` Jeff Garzik [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-01-09 4:19 Herbert Xu
2009-01-09 5:00 ` David Miller
2009-01-09 5:05 ` Jeff Garzik
2009-01-09 5:03 ` Jeff Garzik
2009-01-09 5:15 ` Herbert Xu
2009-01-09 5:30 ` Jeff Garzik
2009-01-09 5:35 ` Herbert Xu
2009-01-09 6:28 ` Jeff Garzik
2009-01-09 6:30 ` Herbert Xu
2009-01-08 2:03 Rick Jones
2009-01-08 3:14 ` Ben Hutchings
2009-01-08 3:12 ` Jeff Garzik
2009-01-08 19:11 ` Rick Jones
2009-01-08 19:25 ` Ben Hutchings
2009-01-08 19:50 ` Rick Jones
2009-01-09 2:52 ` Herbert Xu
2009-01-09 3:20 ` Jeff Garzik
2009-03-06 11:19 ` Jeff Garzik
2009-03-06 13:52 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4966CB59.4090202@pobox.com \
--to=jgarzik@pobox.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.