net: increase the size of priv_flags and add IFF_OVS_DATAPATH
Subsystems (2)
PATCH 1/1 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.
---
I had hoped this patch would be much cleaner :^)
include/linux/if.h +2 -0
@@ -75,6 +75,8 @@#define IFF_DISABLE_NETPOLL 0x2000/* disable netpoll at run-time */ #define IFF_MACVLAN_PORT 0x4000/* device used as macvlan port */ #define IFF_BRIDGE_PORT 0x8000/* device used as bridge port */ +#define IFF_OVS_DATAPATH 0x10000/* device used as Open vSwitch +* dapath port */ #define IF_GET_IFACE 0x0001/* for querying only */ #define IF_GET_PROTO 0x0002
include/linux/netdevice.h +1 -1
@@ -907,7 +907,7 @@ struct net_device {unsigned int flags;/* interface flags (a la BSD) */ unsigned short gflags; -unsigned short priv_flags;/* Like 'flags' but invisible to userspace. */ +unsigned int priv_flags;/* Like 'flags' but invisible to userspace. */ unsigned short padded;/* How much padding added by alloc_netdev() */ unsigned char operstate;/* RFC2863 operstate */
David Miller
maintainerFrom: Simon Horman <[email protected]>
Date: Tue, 24 Aug 2010 11:26:41 +0900
Quoted 6 lines
IFF_OVS_DATAPATHis a place-holder for the Open vSwitch datapath which I am preparing to submit for merging.As all 16 bits of
priv_flagsare already assigned flags, also increase the size ofpriv_flagsto 32 bits.
Quoted 7 lines
Unfortunately, by my calculations this increases the size of struct
net_deviceby 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 <[email protected]>Signed-off-by Simon Horman <[email protected]>
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.
Quoted 17 lines · David Miller
From: Simon Horman <[email protected]>
Date: Tue, 24 Aug 2010 11:26:41 +0900Quoted 6 lines
IFF_OVS_DATAPATHis a place-holder for the Open vSwitch datapath which I am preparing to submit for merging.As all 16 bits of
priv_flagsare already assigned flags, also increase the size ofpriv_flagsto 32 bits.Quoted 7 lines
Unfortunately, by my calculations this increases the size of struct
net_deviceby 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 <[email protected]>Signed-off-by Simon Horman <[email protected]>
Quoted 6 lines
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.
Quoted 17 lines · David Miller
From: Simon Horman <[email protected]>
Date: Tue, 24 Aug 2010 11:26:41 +0900Quoted 6 lines
IFF_OVS_DATAPATHis a place-holder for the Open vSwitch datapath which I am preparing to submit for merging.As all 16 bits of
priv_flagsare already assigned flags, also increase the size ofpriv_flagsto 32 bits.Quoted 7 lines
Unfortunately, by my calculations this increases the size of struct
net_deviceby 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 <[email protected]>Signed-off-by Simon Horman <[email protected]>
Quoted 6 lines
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 adev->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, [email protected]