[PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE

[PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE

[Thadeu Lima de Souza Cascardo]

Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
to allow GPE interfaces to be added as openvswitch ports.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Cc: Jiri Benc <jbenc@redhat.com>
Cc: Simon Horman <simon.horman@netronome.com>
---
 drivers/net/vxlan.c         | 2 +-
 include/uapi/linux/if_arp.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2668e52..9da962f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2603,7 +2603,7 @@ static void vxlan_ether_setup(struct net_device *dev)
 static void vxlan_raw_setup(struct net_device *dev)
 {
 	dev->header_ops = NULL;
-	dev->type = ARPHRD_NONE;
+	dev->type = ARPHRD_VXLANGPE;
 	dev->hard_header_len = 0;
 	dev->addr_len = 0;
 	dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
index 4d024d7..52a8175 100644
--- a/include/uapi/linux/if_arp.h
+++ b/include/uapi/linux/if_arp.h
@@ -95,6 +95,7 @@
 #define ARPHRD_IP6GRE	823		/* GRE over IPv6		*/
 #define ARPHRD_NETLINK	824		/* Netlink header		*/
 #define ARPHRD_6LOWPAN	825		/* IPv6 over LoWPAN             */
+#define ARPHRD_VXLANGPE 826		/* VxLAN GPE */
 
 #define ARPHRD_VOID	  0xFFFF	/* Void type, nothing is known */
 #define ARPHRD_NONE	  0xFFFE	/* zero header length */
-- 
2.5.5

Re: [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE

[Jiri Benc]

On Thu,  5 May 2016 13:36:44 -0300, Thadeu Lima de Souza Cascardo wrote:
> Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
> to allow GPE interfaces to be added as openvswitch ports.

What's wrong with ARPHRD_NONE? I don't think we need a separate type
for VXLAN-GPE. Just use ARPHRD_NONE in ovs and things should work, for
all ARPHRD_NONE interfaces as a bonus.

> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
> Cc: Jiri Benc <jbenc@redhat.com>
> Cc: Simon Horman <simon.horman@netronome.com>

You did not CC me nor Simon :-)

 Jiri

Re: [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE

[Thadeu Lima de Souza Cascardo]

On Thu, May 05, 2016 at 09:31:41PM +0200, Jiri Benc wrote:
> On Thu,  5 May 2016 13:36:44 -0300, Thadeu Lima de Souza Cascardo wrote:
> > Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
> > to allow GPE interfaces to be added as openvswitch ports.
> 
> What's wrong with ARPHRD_NONE? I don't think we need a separate type
> for VXLAN-GPE. Just use ARPHRD_NONE in ovs and things should work, for
> all ARPHRD_NONE interfaces as a bonus.
> 

That's fine for me. I looked quickly at the few devices using ARPHRD_NONE in
upstream kernel, not sure if there are broken out-of-tree drivers out there. And
should we care?

> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
> > Cc: Jiri Benc <jbenc@redhat.com>
> > Cc: Simon Horman <simon.horman@netronome.com>
> 
> You did not CC me nor Simon :-)
> 

I am using sendemail.suppresscc=all to prevent some accidents. I am adding
confirm=always so I can double check before really sending.

Thanks.
Cascardo.

>  Jiri

Re: [PATCH net-next] vxlan: if_arp: introduce ARPHRD_VXLANGPE

[Simon Horman]

On Thu, May 05, 2016 at 04:56:43PM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Thu, May 05, 2016 at 09:31:41PM +0200, Jiri Benc wrote:
> > On Thu,  5 May 2016 13:36:44 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > Use ARPHRD_VXLANGPE to identify VxLAN GPE interfaces. This is going to be used
> > > to allow GPE interfaces to be added as openvswitch ports.
> > 
> > What's wrong with ARPHRD_NONE? I don't think we need a separate type
> > for VXLAN-GPE. Just use ARPHRD_NONE in ovs and things should work, for
> > all ARPHRD_NONE interfaces as a bonus.
> > 
> 
> That's fine for me. I looked quickly at the few devices using ARPHRD_NONE in
> upstream kernel, not sure if there are broken out-of-tree drivers out there. And
> should we care?

It seems unlikely to me that we should.