All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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.