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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20121204094809.9689.C42C3789@sakura.ad.jp>
Date:	Tue, 04 Dec 2012 09:48:12 +0900
From:	Naoto MATSUMOTO <n-matsumoto@...ura.ad.jp>
To:	Joseph Glanville <joseph.glanville@...onvm.com.au>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>,
	alexander.h.duyck@...el.com, netdev@...r.kernel.org
Subject: Re[2]: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large


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@...onvm.com.au> wrote:

> On 20 November 2012 03:03, Stephen Hemminger <shemminger@...tta.com> wrote:
> > On Mon, 19 Nov 2012 22:33:50 +1100
> > Joseph Glanville <joseph.glanville@...onvm.com.au> wrote:
> >
> >> On 14 November 2012 08:33, Stephen Hemminger <shemminger@...tta.com> wrote:
> >> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
> >> > David Miller <davem@...emloft.net> wrote:
> >> >
> >> >> From: Alexander Duyck <alexander.h.duyck@...el.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@...el.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@...r.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html