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 http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf). 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.) Thanks, Tom >> >> Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
