On Thu, Oct 29, 2015 at 1:19 PM, Pankaj Garg <[email protected]> wrote: > Inline. > >> -----Original Message----- >> From: Tom Herbert [mailto:[email protected]] >> Sent: Thursday, October 29, 2015 12:55 PM >> To: Pankaj Garg <[email protected]> >> Cc: Dino Farinacci <[email protected]>; Manish Kumar (manishkr) >> <[email protected]>; Lucy Yong <[email protected]>; >> [email protected] >> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >> Generic Routing Encapsulation >> >> On Thu, Oct 29, 2015 at 12:41 PM, Pankaj Garg <[email protected]> >> wrote: >> > Inline. >> > >> >> -----Original Message----- >> >> From: Tom Herbert [mailto:[email protected]] >> >> Sent: Thursday, October 29, 2015 12:25 PM >> >> To: Pankaj Garg <[email protected]> >> >> Cc: Dino Farinacci <[email protected]>; Manish Kumar (manishkr) >> >> <[email protected]>; Lucy Yong <[email protected]>; >> [email protected] >> >> Subject: Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using >> >> Generic Routing Encapsulation >> >> >> >> > A key limitation that prevents software from using extensions is >> >> > NIC >> >> offloads. Both Geneve and VXLAN-GPE+NSH allows extension of these >> >> protocols without breaking NIC offloads. >> >> >> >> Can you describe why you think this is? Both Geneve and VXLAN- >> GPE+NSH >> >> are not usable with most implementations of checksum offloads and >> >> probably TSO. As we demonstrated in GUE it is possible to offload >> >> encapsulated checksums by enabling the other UDP checksum and using >> >> the remote checksum offload option (which we also implemented for >> VXLAN). >> > [PG] We can define newer TLVs and extend Geneve or NSH without >> breaking NIC offloads. NIC has to support Geneve/NSH offload in the first >> place, but after that we can safely extend using TLVs as needed without >> dealing with NIC offload changes etc. This includes the range of offload from >> Checksum, LSO, LRO, VMQ, RSS etc. >> >> Okay, you are assuming that we would go out an buy NICs that specifically >> support these protocols in the first place. My belief is that if NIC vendors >> implement generic offload mechanisms it is a far a better route and could >> support a multitude of encapsulation protocols (see > [PG] It is up to hardware vendors to decide how to optimally and/or > generically do this in hardware, but from software interface perspective, > there is non-trivial amount of work that needs to be done for each new > offload. It took significant time to get NVGRE and VXLAN offloads working > correctly. We don't want to go through that pain, at least not unless we > _have_ to and that is the promise of NSH and Geneve. If we can build a > generic interface for offloads that NICs implement, that would be great as > well, but I am skeptical of the viability of that given the variation in > formats of various protocols.
The generic interfaces already exists. Please look at my paper on UDP encapsulation. We have simple well defined interfaces to handle four of the five basic NIC offloads in a generic way (RX csum, TX csum, RSS, and LSO). The fifth, LRO, would require NIC support per protocol but it's pretty straightforward to make a software cognate for that (but LRO has it own problems anyway...). This applies to VXLAN, GUE, geneve, MPLS/UDP, GRE/UDP, IP/UDP and whatever new encapsulations we would dream up. Tom >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpeople. >> netfilter.org%2fpablo%2fnetdev0.1%2fpapers%2fUDP-Encapsulation-in- >> Linux.pdf&data=01%7c01%7cpankajg%40microsoft.com%7cc9ceeee9e5f6433 >> 9c07c08d2e09ad904%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MS >> vIxq6ldUFWP5v0g%2foPBZuC95iJYWPHfirUdYeA%2bPQ%3d). > [PG] I haven't read this fully yet, but will read it sometime. >> >> As for "safely extend using TLVs" have you actually verified that works with >> HW, performance is unaffected, and this does not create new vectors of DOS >> attacks? (Given the unmitigated disappointment with IP options I'm very >> skeptical of and deployment of TLVs at L3 or below in the data center.) > [PG] We have not tested it but maybe some IHVs who are supporting Geneve (or > NSH) offload can comment. I have no technical evidence, though, as to why it > would _not_ work (sans some implementation constraints on maximum header size > etc, which is pretty reasonable). >> >> Thanks, >> Tom >> >> >> >> >> Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
