| Message ID | 20121109233354.17208.36271.stgit@gitlad.jf.intel.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
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
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
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.
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
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!
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.
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
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
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. */
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