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

login
register
mail settings
Submitter Alexander Duyck
Date Nov. 9, 2012, 11:35 p.m.
Message ID <20121109233354.17208.36271.stgit@gitlad.jf.intel.com>
Download mbox | patch
Permalink /patch/198161/
State Accepted
Delegated to: David Miller
Headers show

Comments

Alexander Duyck - Nov. 9, 2012, 11:35 p.m.
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(-)


--
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 - Nov. 13, 2012, 7:37 p.m.
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.
--
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
stephen hemminger - Nov. 13, 2012, 9:33 p.m.
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.
--
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 Glanville - Nov. 19, 2012, 11:33 a.m.
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.
stephen hemminger - Nov. 19, 2012, 4:03 p.m.
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.
--
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 Glanville - Nov. 19, 2012, 11:37 p.m.
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!
Joseph Glanville - Dec. 3, 2012, 3:26 p.m.
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.
Naoto MATSUMOTO - Dec. 4, 2012, 12:48 a.m.
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
Alexander Duyck - Dec. 4, 2012, 5:12 p.m.
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

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

Patch

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. */