Inline. > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Thursday, October 29, 2015 1:34 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 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.
[PG] Yes I plan to read it, it looks pretty interesting paper, appreciate the link. > > 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
