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 04:37:58 +0000 [thread overview]
Message-ID: <1292042278.3136.14.camel@localhost> (raw)
In-Reply-To: <1292040815-10439-1-git-send-email-horms@verge.net.au>
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.
But if it is to be a feature flag...
[...]
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 1774178..f63bdce 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
[...]
> @@ -157,6 +158,13 @@ int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
> }
> EXPORT_SYMBOL(ethtool_op_set_flags);
>
> +static int ethtool_op_set_flags_early_orphan(struct net_device *dev, u32 data)
> +{
> + dev->features = ((dev->features & ~NETIF_F_EARLY_ORPHAN) |
> + (data & NETIF_F_EARLY_ORPHAN));
> + return 0;
this needs to check that no unsupported flags are set, i.e.
return ethtool_op_set_flags(dev, data, NETIF_F_EARLY_ORPHAN);
> +}
> +
> void ethtool_ntuple_flush(struct net_device *dev)
> {
> struct ethtool_rx_ntuple_flow_spec_container *fsc, *f;
> @@ -1644,7 +1652,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
> break;
> case ETHTOOL_SFLAGS:
> rc = ethtool_set_value(dev, useraddr,
> - dev->ethtool_ops->set_flags);
> + dev->ethtool_ops->set_flags ?
> + dev->ethtool_ops->set_flags :
> + ethtool_op_set_flags_early_orphan);
[...]
and this fallback needs to be done further up along with ETHTOOL_DRVINFO
so that it doesn't depend on the driver setting dev->ethtool_ops at all.
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 4:38 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 [this message]
2010-12-11 5:04 ` Simon Horman
2010-12-11 5:39 ` Simon Horman
2010-12-11 5:46 ` Ben Hutchings
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=1292042278.3136.14.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).