From: Ben Hutchings <bhutchings@solarflare.com>
To: Simon Horman <horms@verge.net.au>
Cc: netdev@vger.kernel.org, Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH] rfc: ethtool: early-orphan control
Date: Sat, 11 Dec 2010 05:46:20 +0000 [thread overview]
Message-ID: <1292046380.3136.24.camel@localhost> (raw)
In-Reply-To: <20101211053945.GA2101@verge.net.au>
On Sat, 2010-12-11 at 14:39 +0900, Simon Horman wrote:
> On Sat, Dec 11, 2010 at 02:04:47PM +0900, Simon Horman wrote:
> > On Sat, Dec 11, 2010 at 04:37:58AM +0000, Ben Hutchings wrote:
> > > On Sat, 2010-12-11 at 13:13 +0900, Simon Horman wrote:
> > > > Early orphaning is an optimisation which avoids unnecessary cache misses by
> > > > orphaning an skb just before it is handed to a device for transmit thus
> > > > avoiding the case where the orphaning occurs on a different CPU.
> > > >
> > > > In the case of bonded devices this has the unfortunate side-effect of
> > > > breaking down flow control allowing a socket to send UDP packets as fast as
> > > > the CPU will allow. This is particularly undesirable in virtualised
> > > > network environments.
> > > >
> > > > This patch introduces ethtool control of early orphaning.
> > > > It remains on by default by it now may be disabled on a per-interface basis.
> > > >
> > > > I have implemented this as a generic flag.
> > > > As it seems to be the first generic flag that requires
> > > > no driver awareness I also supplied a default flag handler.
> > > > I am unsure if any aspect of this approach is acceptable.
> > >
> > > I'm not convinced that this belongs in the ethtool API. It doesn't seem
> > > to have anything to do with hardware or driver behaviour. The flag
> > > belongs in priv_flags, not features.
> >
> > Ok, I have no objection to it going in priv_flags so long
> > as it can be exposed to user-space in some sensible fashion.
> > Do you have any thoughts on how best to achieve that?
>
> Sorry, I realise that was a pretty silly question
> as I now see ETHTOOL_GPFLAGS and ETHTOOL_SPFLAGS.
Not a silly question. The ETHTOOL_{G,S}PFLAGS commands are for
driver-specific flags while net_device::priv_flags is used by the
networking core and some special drivers (IFF_802_1Q_VLAN etc. in
<linux/if.h>).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2010-12-11 5:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-11 4:13 [PATCH] rfc: ethtool: early-orphan control Simon Horman
2010-12-11 4:24 ` Simon Horman
2010-12-11 8:03 ` Eric Dumazet
[not found] ` <1292087480.2746.54.camel@edumazet-laptop>
2010-12-11 22:40 ` Simon Horman
2010-12-11 4:37 ` Ben Hutchings
2010-12-11 5:04 ` Simon Horman
2010-12-11 5:39 ` Simon Horman
2010-12-11 5:46 ` Ben Hutchings [this message]
2010-12-14 19:30 ` Ben Hutchings
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=1292046380.3136.24.camel@localhost \
--to=bhutchings@solarflare.com \
--cc=eric.dumazet@gmail.com \
--cc=horms@verge.net.au \
--cc=netdev@vger.kernel.org \
/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.