* [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
@ 2012-11-09 23:35 Alexander Duyck
2012-11-13 19:37 ` David Miller
0 siblings, 1 reply; 12+ messages in thread
From: Alexander Duyck @ 2012-11-09 23:35 UTC (permalink / raw)
To: netdev; +Cc: davem, shemminger
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. */
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-09 23:35 [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Alexander Duyck
@ 2012-11-13 19:37 ` David Miller
2012-11-13 21:33 ` Stephen Hemminger
0 siblings, 1 reply; 12+ messages in thread
From: David Miller @ 2012-11-13 19:37 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, shemminger
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-13 19:37 ` David Miller
@ 2012-11-13 21:33 ` Stephen Hemminger
2012-11-13 23:10 ` [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN Alexander Duyck
2012-11-19 11:33 ` [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Joseph Glanville
0 siblings, 2 replies; 12+ messages in thread
From: Stephen Hemminger @ 2012-11-13 21:33 UTC (permalink / raw)
To: David Miller; +Cc: alexander.h.duyck, netdev
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN
2012-11-13 21:33 ` Stephen Hemminger
@ 2012-11-13 23:10 ` Alexander Duyck
2012-11-13 23:12 ` Stephen Hemminger
2012-11-19 11:33 ` [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Joseph Glanville
1 sibling, 1 reply; 12+ messages in thread
From: Alexander Duyck @ 2012-11-13 23:10 UTC (permalink / raw)
To: netdev; +Cc: shemminger, davem
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])
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN
2012-11-13 23:10 ` [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN Alexander Duyck
@ 2012-11-13 23:12 ` Stephen Hemminger
2012-11-13 23:20 ` David Miller
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Hemminger @ 2012-11-13 23:12 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, davem
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN
2012-11-13 23:12 ` Stephen Hemminger
@ 2012-11-13 23:20 ` David Miller
0 siblings, 0 replies; 12+ messages in thread
From: David Miller @ 2012-11-13 23:20 UTC (permalink / raw)
To: shemminger; +Cc: alexander.h.duyck, netdev
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-13 21:33 ` Stephen Hemminger
2012-11-13 23:10 ` [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN Alexander Duyck
@ 2012-11-19 11:33 ` Joseph Glanville
2012-11-19 16:03 ` Stephen Hemminger
1 sibling, 1 reply; 12+ messages in thread
From: Joseph Glanville @ 2012-11-19 11:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, alexander.h.duyck, netdev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-19 11:33 ` [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Joseph Glanville
@ 2012-11-19 16:03 ` Stephen Hemminger
2012-11-19 23:37 ` Joseph Glanville
2012-12-03 15:26 ` Joseph Glanville
0 siblings, 2 replies; 12+ messages in thread
From: Stephen Hemminger @ 2012-11-19 16:03 UTC (permalink / raw)
To: Joseph Glanville; +Cc: David Miller, alexander.h.duyck, netdev
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-19 16:03 ` Stephen Hemminger
@ 2012-11-19 23:37 ` Joseph Glanville
2012-12-03 15:26 ` Joseph Glanville
1 sibling, 0 replies; 12+ messages in thread
From: Joseph Glanville @ 2012-11-19 23:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, alexander.h.duyck, netdev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-11-19 16:03 ` Stephen Hemminger
2012-11-19 23:37 ` Joseph Glanville
@ 2012-12-03 15:26 ` Joseph Glanville
2012-12-04 0:48 ` Re[2]: " Naoto MATSUMOTO
1 sibling, 1 reply; 12+ messages in thread
From: Joseph Glanville @ 2012-12-03 15:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, alexander.h.duyck, netdev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re[2]: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-12-03 15:26 ` Joseph Glanville
@ 2012-12-04 0:48 ` Naoto MATSUMOTO
2012-12-04 17:12 ` Alexander Duyck
0 siblings, 1 reply; 12+ messages in thread
From: Naoto MATSUMOTO @ 2012-12-04 0:48 UTC (permalink / raw)
To: Joseph Glanville
Cc: Stephen Hemminger, David Miller, alexander.h.duyck, netdev
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/>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
2012-12-04 0:48 ` Re[2]: " Naoto MATSUMOTO
@ 2012-12-04 17:12 ` Alexander Duyck
0 siblings, 0 replies; 12+ messages in thread
From: Alexander Duyck @ 2012-12-04 17:12 UTC (permalink / raw)
To: Naoto MATSUMOTO; +Cc: Joseph Glanville, Stephen Hemminger, David Miller, netdev
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-12-04 17:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-09 23:35 [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Alexander Duyck
2012-11-13 19:37 ` David Miller
2012-11-13 21:33 ` Stephen Hemminger
2012-11-13 23:10 ` [PATCH] vxlan: Update hard_header_len based on lowerdev when instantiating VXLAN Alexander Duyck
2012-11-13 23:12 ` Stephen Hemminger
2012-11-13 23:20 ` David Miller
2012-11-19 11:33 ` [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large Joseph Glanville
2012-11-19 16:03 ` Stephen Hemminger
2012-11-19 23:37 ` Joseph Glanville
2012-12-03 15:26 ` Joseph Glanville
2012-12-04 0:48 ` Re[2]: " Naoto MATSUMOTO
2012-12-04 17:12 ` Alexander Duyck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).