public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: netdev@vger.kernel.org, Jay Vosburgh <fubar@us.ibm.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	Stephen Hemminger <shemminger@linux-foundation.org>,
	bridge@lists.linux-foundation.org
Subject: Re: [PATCH] net: fix netdev_increment_features()
Date: Wed, 27 Apr 2011 01:26:10 +0100	[thread overview]
Message-ID: <1303863970.2850.31.camel@bwh-desktop> (raw)
In-Reply-To: <20110422163116.3C5C3138DD@rere.qmqm.pl>

On Fri, 2011-04-22 at 18:31 +0200, Michał Mirosław wrote:
> Simplify and fix netdev_increment_features() to conform to what is
> stated in netdevice.h comments about NETIF_F_ONE_FOR_ALL.
> Include FCoE segmentation and VLAN-challedged flags in computation.
> 
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> 
> I noticed this while converting bridge code to hw_features. After
> adding devices to the bridge all features were always cleared regardless
> of features active in those devices.
> 
>  include/linux/netdevice.h |    7 ++++++-
>  net/core/dev.c            |   37 ++++++++++++-------------------------
>  2 files changed, 18 insertions(+), 26 deletions(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 405ce21..86140e4 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1107,7 +1107,12 @@ struct net_device {
>  	 */
>  #define NETIF_F_ONE_FOR_ALL	(NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ROBUST | \
>  				 NETIF_F_SG | NETIF_F_HIGHDMA |		\
> -				 NETIF_F_FRAGLIST)
> +				 NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED)

I think we can also add NETIF_F_HW_VLAN_TX, now that
dev_hard_start_xmit() handles VLAN tag insertion.

> +	/*
> +	 * If one device doesn't support one of these features, then disable it
> +	 * for all in netdev_increment_features.
> +	 */
> +#define NETIF_F_ALL_FOR_ALL	(NETIF_F_NOCACHE_COPY | NETIF_F_FSO)

Shouldn't most RX offloads be included in this?  Though it doesn't
really matter that much.

>  	/* changeable features with no special hardware requirements */
>  #define NETIF_F_SOFT_FEATURES	(NETIF_F_GSO | NETIF_F_GRO)
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3871bf6..1a2c91c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6184,33 +6184,20 @@ static int dev_cpu_callback(struct notifier_block *nfb,
>   */
>  u32 netdev_increment_features(u32 all, u32 one, u32 mask)
>  {
> +	if (mask & NETIF_F_GEN_CSUM)
> +		mask |= NETIF_F_ALL_CSUM;
> +	mask |= NETIF_F_VLAN_CHALLENGED;
> +
> +	all |= one & (NETIF_F_ONE_FOR_ALL|NETIF_F_ALL_CSUM) & mask;
> +	all &= one | ~NETIF_F_ALL_FOR_ALL;
> +
>  	/* If device needs checksumming, downgrade to it. */
> -	if (all & NETIF_F_NO_CSUM && !(one & NETIF_F_NO_CSUM))
> -		all ^= NETIF_F_NO_CSUM | (one & NETIF_F_ALL_CSUM);
> -	else if (mask & NETIF_F_ALL_CSUM) {
> -		/* If one device supports v4/v6 checksumming, set for all. */
> -		if (one & (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM) &&
> -		    !(all & NETIF_F_GEN_CSUM)) {
> -			all &= ~NETIF_F_ALL_CSUM;
> -			all |= one & (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM);
> -		}
> +	if (all & (NETIF_F_ALL_CSUM & ~NETIF_F_NO_CSUM))
> +		all &= ~NETIF_F_NO_CSUM;
>  
> -		/* If one device supports hw checksumming, set for all. */
> -		if (one & NETIF_F_GEN_CSUM && !(all & NETIF_F_GEN_CSUM)) {
> -			all &= ~NETIF_F_ALL_CSUM;
> -			all |= NETIF_F_HW_CSUM;
> -		}
> -	}
> -
> -	/* If device can't no cache copy, don't do for all */
> -	if (!(one & NETIF_F_NOCACHE_COPY))
> -		all &= ~NETIF_F_NOCACHE_COPY;
> -
> -	one |= NETIF_F_ALL_CSUM;
> -
> -	one |= all & NETIF_F_ONE_FOR_ALL;
> -	all &= one | NETIF_F_LLTX | NETIF_F_GSO | NETIF_F_UFO;
> -	all |= one & mask & NETIF_F_ONE_FOR_ALL;
> +	/* If one device supports hw checksumming, set for all. */
> +	if (all & NETIF_F_GEN_CSUM)
> +		all &= ~(NETIF_F_ALL_CSUM & ~NETIF_F_GEN_CSUM);
>  
>  	return all;
>  }

Well it might be correct, but it's hard to tell.  Can we see your unit
tests, please?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


  reply	other threads:[~2011-04-27  0:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-22 16:31 [PATCH] net: fix netdev_increment_features() Michał Mirosław
2011-04-27  0:26 ` Ben Hutchings [this message]
2011-04-28 20:33 ` David Miller

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=1303863970.2850.31.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=andy@greyhouse.net \
    --cc=bridge@lists.linux-foundation.org \
    --cc=fubar@us.ibm.com \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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