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

Subsystems: networking drivers, the rest

STALE5052d

12 messages, 5 authors, 2012-12-04 · open the first message on its own page

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

From: Alexander Duyck <hidden>
Date: 2012-11-09 23:35:09

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

 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

From: David Miller <davem@davemloft.net>
Date: 2012-11-13 19:37:20

From: Alexander Duyck <redacted>
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 <redacted>

Applied, thanks for the detailed commit message.

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

From: Stephen Hemminger <hidden>
Date: 2012-11-13 21:34:55

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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

From: Alexander Duyck <hidden>
Date: 2012-11-13 23:12:08

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

 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

From: Stephen Hemminger <hidden>
Date: 2012-11-13 23:13:02

On Tue, 13 Nov 2012 15:10:59 -0800
Alexander Duyck [off-list ref] wrote:

quoted hunk

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

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

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

From: David Miller <davem@davemloft.net>
Date: 2012-11-13 23:20:12

From: Stephen Hemminger <redacted>
Date: Tue, 13 Nov 2012 15:12:00 -0800

On Tue, 13 Nov 2012 15:10:59 -0800
Alexander Duyck [off-list ref] wrote:

quoted

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

...

Acked-by: Stephen Hemminger <redacted>

Applied, thanks.

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

From: Joseph Glanville <hidden>
Date: 2012-11-19 11:33:50

On 14 November 2012 08:33, Stephen Hemminger [off-list ref] wrote:

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

quoted

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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

From: Stephen Hemminger <hidden>
Date: 2012-11-19 16:04:57

On Mon, 19 Nov 2012 22:33:50 +1100
Joseph Glanville [off-list ref] wrote:

On 14 November 2012 08:33, Stephen Hemminger [off-list ref] wrote:

quoted

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

quoted

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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.

quoted

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

From: Joseph Glanville <hidden>
Date: 2012-11-19 23:37:40

On 20 November 2012 03:03, Stephen Hemminger [off-list ref] wrote:

On Mon, 19 Nov 2012 22:33:50 +1100
Joseph Glanville [off-list ref] wrote:

quoted

On 14 November 2012 08:33, Stephen Hemminger [off-list ref] wrote:

quoted

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

quoted

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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.

quoted

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

From: Joseph Glanville <hidden>
Date: 2012-12-03 15:26:19

On 20 November 2012 03:03, Stephen Hemminger [off-list ref] wrote:

On Mon, 19 Nov 2012 22:33:50 +1100
Joseph Glanville [off-list ref] wrote:

quoted

On 14 November 2012 08:33, Stephen Hemminger [off-list ref] wrote:

quoted

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

quoted

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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.

quoted

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

From: Naoto MATSUMOTO <hidden>
Date: 2012-12-04 01:03:16

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 [off-list ref] wrote:

On 20 November 2012 03:03, Stephen Hemminger [off-list ref] wrote:

quoted

On Mon, 19 Nov 2012 22:33:50 +1100
Joseph Glanville [off-list ref] wrote:

quoted

On 14 November 2012 08:33, Stephen Hemminger [off-list ref] wrote:

quoted

On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
David Miller [off-list ref] wrote:

quoted

From: Alexander Duyck <redacted>
Date: Fri, 09 Nov 2012 15:35:24 -0800

quoted

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

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.

quoted

--
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 [off-list ref]
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

From: Alexander Duyck <hidden>
Date: 2012-12-04 17:12:30

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

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help