[net-next] net: increase the size of priv_flags and add IFF_OVS_DATAPATH

IFF_OVS_DATAPATH is a place-holder for the Open vSwitch datapath
which I am preparing to submit for merging.

As all 16 bits of priv_flags are already assigned flags, also increase
the size of priv_flags to 32 bits.

Unfortunately, by my calculations this increases the size of
struct net_device by 4 bytes on 32bit architectures and
8 bytes on 64 bit architectures. I couldn't see an obvious
way to avoid that.

Cc: Jesse Gross <jesse@nicira.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

I had hoped this patch would be much cleaner :^)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Simon Horman <horms@verge.net.au>
Date: Tue, 24 Aug 2010 11:26:41 +0900

> IFF_OVS_DATAPATH is a place-holder for the Open vSwitch datapath
> which I am preparing to submit for merging.
> 
> As all 16 bits of priv_flags are already assigned flags, also increase
> the size of priv_flags to 32 bits.
> 
> Unfortunately, by my calculations this increases the size of
> struct net_device by 4 bytes on 32bit architectures and
> 8 bytes on 64 bit architectures. I couldn't see an obvious
> way to avoid that.
> 
> Cc: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>

I can't think of a better way out of this, so applied for now.

Maybe somehow some of those bonding specific flags can get put
down into the bonding private structure.  However, that might
not be possible if the sole reason those live in ->priv_flags
is to allow tests of the flags outside of the bonding code.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Aug 23, 2010 at 08:44:08PM -0700, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Tue, 24 Aug 2010 11:26:41 +0900
> 
> > IFF_OVS_DATAPATH is a place-holder for the Open vSwitch datapath
> > which I am preparing to submit for merging.
> > 
> > As all 16 bits of priv_flags are already assigned flags, also increase
> > the size of priv_flags to 32 bits.
> > 
> > Unfortunately, by my calculations this increases the size of
> > struct net_device by 4 bytes on 32bit architectures and
> > 8 bytes on 64 bit architectures. I couldn't see an obvious
> > way to avoid that.
> > 
> > Cc: Jesse Gross <jesse@nicira.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> I can't think of a better way out of this, so applied for now.
> 
> Maybe somehow some of those bonding specific flags can get put
> down into the bonding private structure.  However, that might
> not be possible if the sole reason those live in ->priv_flags
> is to allow tests of the flags outside of the bonding code.

Thanks.

It seems to me that there is ample scope to do something.
But nothing seems obviously correct.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller <davem@davemloft.net> wrote:

>From: Simon Horman <horms@verge.net.au>
>Date: Tue, 24 Aug 2010 11:26:41 +0900
>
>> IFF_OVS_DATAPATH is a place-holder for the Open vSwitch datapath
>> which I am preparing to submit for merging.
>> 
>> As all 16 bits of priv_flags are already assigned flags, also increase
>> the size of priv_flags to 32 bits.
>> 
>> Unfortunately, by my calculations this increases the size of
>> struct net_device by 4 bytes on 32bit architectures and
>> 8 bytes on 64 bit architectures. I couldn't see an obvious
>> way to avoid that.
>> 
>> Cc: Jesse Gross <jesse@nicira.com>
>> Signed-off-by: Simon Horman <horms@verge.net.au>
>
>I can't think of a better way out of this, so applied for now.
>
>Maybe somehow some of those bonding specific flags can get put
>down into the bonding private structure.  However, that might
>not be possible if the sole reason those live in ->priv_flags
>is to allow tests of the flags outside of the bonding code.

	That is indeed the case: it's to permit the flags to be tested
primarily in the netif_receive_skb path (inside __skb_bond_should_drop)
without calling into bonding via a hook or the like.  There's also one
check in fcoe to not support fcoe over a subset of bonding modes, from
the looks of it.

	I don't think the bonding tests could be rolled up into a
dev->rx_handler, either, because the bonding stuff has to happen before
any delivery attempts (it may affect skb->dev or packet delivery).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html