netdev - Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)

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: <CAEP_g=_bnr94YHKd40qipmniYs80CH4g3iFiHOgZHOnDQ82Epw@mail.gmail.com>
Date:	Mon, 15 Sep 2014 15:44:45 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Or Gerlitz <gerlitz.or@...il.com>,
	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)

On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@...gle.com> wrote:
> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@...gle.com> wrote:
>> [...]
>>> * Notes
>>>   - This patch set does not implement GSO for FOU. The UDP encapsulation
>>>     code assumes TEB, so that will need to be reimplemented.
>>
>> Can you please clarify this point little further? Specifically, today
>> few NICs are
>> advertizing NETIF_F_GSO_UDP_TUNNEL when they are practically GSO
>> capable only w.r.t to VXLAN. What happens when such NIC expose this
>> cap and a large guest frame goes through GRE over UDP or alike tunneling?
>>
> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
> encapsulation over UDP, not VXLAN. If the NIC implements things
> properly following the generic interface then I believe it should work
> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
> This presumes that any encapsulation headers doesn't require any per
> segment update (so no GRE csum for instance). The stack will set up
> inner headers as needed, which should enough to provide to devices the
> offsets inner IP and TCP header which are needed for the the TSO
> operation (outer IP and UDP can be deduced also).

>From the NICs that I am familiar with this is mostly true. The main
part that is missing from the current implementation is a length
limit: just because the hardware can skip over headers to an offset
doesn't mean that it can do so to an arbitrary depth. For example, in
the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
probably assume that this is limited to 8 bytes. With the Intel NICs
that were just announced with Geneve support, this limit has been
increased to 64. If we add a parameter to the driver interface to
expose this then it should be generic across tunnels.
--
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