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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Sep 2014 22:14:21 +0300 From: Or Gerlitz <gerlitz.or@...il.com> To: Tom Herbert <therbert@...gle.com> Cc: Jesse Gross <jesse@...ira.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 Tue, Sep 16, 2014 at 9:34 PM, Tom Herbert <therbert@...gle.com> wrote: > On Tue, Sep 16, 2014 at 5:44 AM, Or Gerlitz <gerlitz.or@...il.com> wrote: >> On Tue, Sep 16, 2014 at 1:44 AM, Jesse Gross <jesse@...ira.com> wrote: >>> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@...gle.com> wrote: >> >>>> 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. >> >> I'm not sure to see why the length limit became our primary concern here... > Like Jesse mentioned above, looks like some NICs may have assumed all > encapsulation headers are eight bytes (which allows HW to implement > everything in fixed offsets). But this length is not a universal > constant: FOU is zero length encapsulation headers, GUE or geneve is > variable. The driver should really be checking if NIC can handle the > length and if it can't perform GSO in software-- I don't think we'll > need to expose this in the features. I understand that for some NICs there's a claim saying the essence of the limitation lies in an assumption on fixed length of the encapsulation headers -- and BTW for VXLAN it's 50 (= 14 + 20 + 8 + 8) bytes, not eight. So newer NICs or new brands of existing NICs should be more flexible. If I correctly read your comment "The driver should really be checking if NIC can handle the length and if it can't perform GSO in software" as saying that a SW GSO call should be made from within the driver when they can't serve GSO under some encap scheme -- I don't think this is the correct track, the driver should advertize up what they can do in HW so the stack does in SW what's not supported. Another clarification - so FOU doesn't supersedes GUE? what's their difference...? Or. -- 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
Powered by blists - more mailing lists