[PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Alexander Duyck]

This change fixes an issue I found where VXLAN frames were fragmented when
they were up to the VXLAN MTU size.  I root caused the issue to the fact that
the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
extra headers that are inserted for VXLAN.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---

 drivers/net/vxlan.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 410ebc8..0b75c19 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -51,8 +51,8 @@
 
 #define VXLAN_N_VID	(1u << 24)
 #define VXLAN_VID_MASK	(VXLAN_N_VID - 1)
-/* VLAN + IP header + UDP + VXLAN */
-#define VXLAN_HEADROOM (4 + 20 + 8 + 8)
+/* IP header + UDP + VXLAN + Ethernet header */
+#define VXLAN_HEADROOM (20 + 8 + 8 + 14)
 
 #define VXLAN_FLAGS 0x08000000	/* struct vxlanhdr.vx_flags required value. */
 

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[David Miller]

From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 09 Nov 2012 15:35:24 -0800

> This change fixes an issue I found where VXLAN frames were fragmented when
> they were up to the VXLAN MTU size.  I root caused the issue to the fact that
> the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
> because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
> As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
> extra headers that are inserted for VXLAN.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>

Applied, thanks for the detailed commit message.

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Stephen Hemminger]

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller <davem@davemloft.net> wrote:

> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Fri, 09 Nov 2012 15:35:24 -0800
> 
> > This change fixes an issue I found where VXLAN frames were fragmented when
> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
> > extra headers that are inserted for VXLAN.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> Applied, thanks for the detailed commit message.

Probably need smarter code there to look at header length requirement
of underlying device as well, maybe someone will be perverse and runn
vxlan over a tunnel or IPoIB.

[PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN

[Alexander Duyck]

In the event of a VXLAN device being linked to a device that has a
hard_header_len greater than that of standard ethernet we could end up with
the hard_header_len not being large enough for outgoing frames.  In order to
prevent this we should update the length when a lowerdev is provided.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---

 drivers/net/vxlan.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 44bcc20..6b666eb 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1110,6 +1110,10 @@ static int vxlan_newlink(struct net *net, struct net_device *dev,
 
 		if (!tb[IFLA_MTU])
 			dev->mtu = lowerdev->mtu - VXLAN_HEADROOM;
+
+		/* update header length based on lower device */
+		dev->hard_header_len = lowerdev->hard_header_len +
+				       VXLAN_HEADROOM;
 	}
 
 	if (data[IFLA_VXLAN_TOS])

Re: [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN

[Stephen Hemminger]

On Tue, 13 Nov 2012 15:10:59 -0800
Alexander Duyck <alexander.h.duyck@intel.com> wrote:

> In the event of a VXLAN device being linked to a device that has a
> hard_header_len greater than that of standard ethernet we could end up with
> the hard_header_len not being large enough for outgoing frames.  In order to
> prevent this we should update the length when a lowerdev is provided.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> 
>  drivers/net/vxlan.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 44bcc20..6b666eb 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -1110,6 +1110,10 @@ static int vxlan_newlink(struct net *net, struct net_device *dev,
>  
>  		if (!tb[IFLA_MTU])
>  			dev->mtu = lowerdev->mtu - VXLAN_HEADROOM;
> +
> +		/* update header length based on lower device */
> +		dev->hard_header_len = lowerdev->hard_header_len +
> +				       VXLAN_HEADROOM;
>  	}
>  
>  	if (data[IFLA_VXLAN_TOS])
> 

Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Re: [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 13 Nov 2012 15:12:00 -0800

> On Tue, 13 Nov 2012 15:10:59 -0800
> Alexander Duyck <alexander.h.duyck@intel.com> wrote:
> 
>> In the event of a VXLAN device being linked to a device that has a
>> hard_header_len greater than that of standard ethernet we could end up with
>> the hard_header_len not being large enough for outgoing frames.  In order to
>> prevent this we should update the length when a lowerdev is provided.
>> 
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
 ...
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>

Applied, thanks.

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Joseph Glanville]

On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> Date: Fri, 09 Nov 2012 15:35:24 -0800
>>
>> > This change fixes an issue I found where VXLAN frames were fragmented when
>> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
>> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
>> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
>> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
>> > extra headers that are inserted for VXLAN.
>> >
>> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> Applied, thanks for the detailed commit message.
>
> Probably need smarter code there to look at header length requirement
> of underlying device as well, maybe someone will be perverse and runn
> vxlan over a tunnel or IPoIB.

Forgive my ignorance but why would running VXLAN on IPoIB require
special header handling? (and would it work or behave strangely?)

I was planning on giving this a go when 3.7 is released but I might do
that sooner if problems are anticipated.

> --
> 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

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Stephen Hemminger]

On Mon, 19 Nov 2012 22:33:50 +1100
Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:

> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
> >>
> >> > This change fixes an issue I found where VXLAN frames were fragmented when
> >> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
> >> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
> >> > extra headers that are inserted for VXLAN.
> >> >
> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> >>
> >> Applied, thanks for the detailed commit message.
> >
> > Probably need smarter code there to look at header length requirement
> > of underlying device as well, maybe someone will be perverse and runn
> > vxlan over a tunnel or IPoIB.
> 
> Forgive my ignorance but why would running VXLAN on IPoIB require
> special header handling? (and would it work or behave strangely?)
> 
> I was planning on giving this a go when 3.7 is released but I might do
> that sooner if problems are anticipated.
> 
> > --
> > 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
> 
> Joseph.
> 

Some lower layers require bigger (or smaller headers). As it was, vxlan
was only allocating skb with a fixed amount of headroom. This would lead to
lower layers having to copy the skb.

My suggestion has already been addressed by a later patch.

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Joseph Glanville]

On 20 November 2012 03:03, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 19 Nov 2012 22:33:50 +1100
> Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
>
>> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
>> > David Miller <davem@davemloft.net> wrote:
>> >
>> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
>> >>
>> >> > This change fixes an issue I found where VXLAN frames were fragmented when
>> >> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
>> >> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
>> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
>> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
>> >> > extra headers that are inserted for VXLAN.
>> >> >
>> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> >>
>> >> Applied, thanks for the detailed commit message.
>> >
>> > Probably need smarter code there to look at header length requirement
>> > of underlying device as well, maybe someone will be perverse and runn
>> > vxlan over a tunnel or IPoIB.
>>
>> Forgive my ignorance but why would running VXLAN on IPoIB require
>> special header handling? (and would it work or behave strangely?)
>>
>> I was planning on giving this a go when 3.7 is released but I might do
>> that sooner if problems are anticipated.
>>
>> > --
>> > 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
>>
>> Joseph.
>>
>
> Some lower layers require bigger (or smaller headers). As it was, vxlan
> was only allocating skb with a fixed amount of headroom. This would lead to
> lower layers having to copy the skb.
>
> My suggestion has already been addressed by a later patch.

Thankyou for the clarification, I found the patch about the lower_dev
hard_header_len!

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Joseph Glanville]

On 20 November 2012 03:03, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 19 Nov 2012 22:33:50 +1100
> Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
>
>> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
>> > David Miller <davem@davemloft.net> wrote:
>> >
>> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
>> >>
>> >> > This change fixes an issue I found where VXLAN frames were fragmented when
>> >> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
>> >> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
>> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
>> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
>> >> > extra headers that are inserted for VXLAN.
>> >> >
>> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> >>
>> >> Applied, thanks for the detailed commit message.
>> >
>> > Probably need smarter code there to look at header length requirement
>> > of underlying device as well, maybe someone will be perverse and runn
>> > vxlan over a tunnel or IPoIB.
>>
>> Forgive my ignorance but why would running VXLAN on IPoIB require
>> special header handling? (and would it work or behave strangely?)
>>
>> I was planning on giving this a go when 3.7 is released but I might do
>> that sooner if problems are anticipated.
>>
>> > --
>> > 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
>>
>> Joseph.
>>
>
> Some lower layers require bigger (or smaller headers). As it was, vxlan
> was only allocating skb with a fixed amount of headroom. This would lead to
> lower layers having to copy the skb.
>
> My suggestion has already been addressed by a later patch.

Hi,

I have tested VXLAN on IPoIB and it works perfectly. :)

Joseph.


-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

Re[2]: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Naoto MATSUMOTO]

Hi all

Sharing my testlab resut for you ;-)

A First Look At VXLAN over Infiniband Network On Linux 3.7-rc7
http://slidesha.re/TsCKWc

plz enjyoi it.

--
Naoto

On Tue, 4 Dec 2012 02:26:18 +1100
Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:

> On 20 November 2012 03:03, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Mon, 19 Nov 2012 22:33:50 +1100
> > Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
> >
> >> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
> >> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
> >> > David Miller <davem@davemloft.net> wrote:
> >> >
> >> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
> >> >>
> >> >> > This change fixes an issue I found where VXLAN frames were fragmented when
> >> >> > they were up to the VXLAN MTU size.  I root caused the issue to the fact that
> >> >> > the headroom was 4 + 20 + 8 + 8.  This math doesn't appear to be correct
> >> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
> >> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
> >> >> > extra headers that are inserted for VXLAN.
> >> >> >
> >> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> >> >>
> >> >> Applied, thanks for the detailed commit message.
> >> >
> >> > Probably need smarter code there to look at header length requirement
> >> > of underlying device as well, maybe someone will be perverse and runn
> >> > vxlan over a tunnel or IPoIB.
> >>
> >> Forgive my ignorance but why would running VXLAN on IPoIB require
> >> special header handling? (and would it work or behave strangely?)
> >>
> >> I was planning on giving this a go when 3.7 is released but I might do
> >> that sooner if problems are anticipated.
> >>
> >> > --
> >> > 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
> >>
> >> Joseph.
> >>
> >
> > Some lower layers require bigger (or smaller headers). As it was, vxlan
> > was only allocating skb with a fixed amount of headroom. This would lead to
> > lower layers having to copy the skb.
> >
> > My suggestion has already been addressed by a later patch.
> 
> Hi,
> 
> I have tested VXLAN on IPoIB and it works perfectly. :)
> 
> Joseph.
> 
> 
> -- 
> CTO | Orion Virtualisation Solutions | www.orionvm.com.au
> Phone: 1300 56 99 52 | Mobile: 0428 754 846
> --
> 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

-- 
SAKURA Internet Inc. / Senior Researcher
Naoto MATSUMOTO <n-matsumoto@sakura.ad.jp>
SAKURA Research Center <http://research.sakura.ad.jp/>

Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large

[Alexander Duyck]

On 12/03/2012 04:48 PM, Naoto MATSUMOTO wrote:
> 
> Hi all
> 
> Sharing my testlab resut for you ;-)
> 
> A First Look At VXLAN over Infiniband Network On Linux 3.7-rc7
> http://slidesha.re/TsCKWc
> 
> plz enjyoi it.
> 
> --
> Naoto

What was the MTU for the underlying IPoIB devices in your test?  Just
wondering because the MTU on the VXLAN is showing as 65470 which would
imply the IPoIB devices should have a 65520 MTU and I just wanted to
confirm that.

Thanks,

Alex