On 26/08/14 22:42, Tom Herbert wrote: > On Tue, Aug 26, 2014 at 2:09 PM, Anton Ivanov > <[email protected]> wrote: >> On 26/08/14 21:47, Tom Herbert wrote: >>> Remote checksum offload is intended to be used to get checksum offload >>> of encapsulated packets to work with legacy NICs (those that don't >>> understand encapsulation protocols). I will be posting an >>> implementation to Linux shortly for GUE and/or Geneve. >> This one was floated on the mailing list during the IETF-89 (and >> immediately thereabouts) discussions around geneve, fixed/floating >> headers, etc a while back. >> >> We have had a working implementation for the GRE case for a while now >> (we have it in a limited release product based around UML in customer >> labs). I need to get around to contribute it upstream (in fact, I was >> going to work on the patchsets this week). >> > You extended GRE with fields for checksum offload?
GRE has an optional checksum already as per RFC 2784 - nothing to extend. If it is computed at source and checked by hardware or hypervisor at destination you can compute the payload checksum from the GRE checksum and pass it to the guest. It is an excellent reference example for your idea because it can be implemented today using IP_HDRINCL which is not yet possible for the UDP encaps as there is no sane way to get to the header and get the csum from it for those without changing the kernel. If nvGRE had the checksum specified (which it presently does not) it could have been subjected to the same technique. We discussed this in the context of CHECKSUM_COMPLETE vs TCP/UDP/PROTOCOL_OF_CHOICE specific checksums 6 months ago and I wrote exactly what you need to do to get remote checksums working at the time. I was actually looking at sources at the time when writing that :) If I have the time I will post the finalized UML driver sources on the uml-devel list within a week and cc you. A. > >> The implementation for UDP based is trivial if you go for generic (not >> protocol specific) checksum options in the linux kernel stack - as >> discussed on the list 6 months ago. All you need is to implement the >> IP_HDRINCL option for UDP in the kernel so you can get to the checksum. >> After that you can use f.e. what we have contributed as a L2TPv3 >> direct-in-vNIC decaps driver for qemu (to ship in qemu-kvm 2.1) or the >> legacy socket driver and extend it to use this option. >> >> A. >> >>> Thanks, >>> Tom >>> >>> ---------- Forwarded message ---------- >>> From: <[email protected]> >>> Date: Tue, Aug 26, 2014 at 1:39 PM >>> Subject: New Version Notification for draft-herbert-remotecsumoffload-00.txt >>> To: Tom Herbert <[email protected]> >>> >>> >>> >>> A new version of I-D, draft-herbert-remotecsumoffload-00.txt >>> has been successfully submitted by Tom Herbert and posted to the >>> IETF repository. >>> >>> Name: draft-herbert-remotecsumoffload >>> Revision: 00 >>> Title: Remote checksum offload for encapsulation >>> Document date: 2014-08-27 >>> Group: Individual Submission >>> Pages: 9 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-herbert-remotecsumoffload-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-herbert-remotecsumoffload/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00 >>> >>> >>> Abstract: >>> This specification describes remote checksum offload for >>> encapsulation, which is a mechanism that provides checksum offload of >>> encapsulated packets using rudimentary offload capabilities found in >>> most Network Interface Card (NIC) devices. The outer header checksum >>> (e.g. that in UDP or GRE) is enabled in packets and, with some >>> additional meta information, a receiver is able to deduce the >>> checksum to be set for an inner encapsulated packet. Effectively this >>> offloads the computation of the inner checksum. Enabling the outer >>> checksum in encapsulation has the additional advantage that it covers >>> more of the packet than the inner checksum including the >>> encapsulation headers. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
