From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx checksum offload Date: Wed, 2 Sep 2015 23:56:46 +0300 Message-ID: References: <1441156443-33381-1-git-send-email-jeffrey.t.kirsher@intel.com> <1441156443-33381-6-git-send-email-jeffrey.t.kirsher@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "Rustad, Mark D" , "Kirsher, Jeffrey T" , "David S. Miller" , Linux Kernel Network Developers , "nhorman@redhat.com" , "sassmann@redhat.com" , "jogreene@redhat.com" To: Tom Herbert Return-path: Received: from mail-oi0-f47.google.com ([209.85.218.47]:35325 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932337AbbIBU4r (ORCPT ); Wed, 2 Sep 2015 16:56:47 -0400 Received: by oiww128 with SMTP id w128so13582555oiw.2 for ; Wed, 02 Sep 2015 13:56:46 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Sep 2, 2015 at 8:38 PM, Tom Herbert wrote: > On Wed, Sep 2, 2015 at 9:46 AM, Rustad, Mark D wrote: >>> On Sep 1, 2015, at 8:17 PM, Tom Herbert wrote: >>> >>> I suspect this is not UDP-encapsulation specific, will it work with >>> TCP/IP/IP, TCP/IP/GRE etc.? >> >> It could do more, but this is what has been tested up to this point. >> > Well, please test the those other encapsulations too! It's nice and > all if they get the benefit, but it's really bad news if these changes > were to screw them up (i.e. you don't want users of the GRE, IPIP to > find out that they're now broken). > >>> Isn't there anyway the ixgbe could just be made to NETIF_HW_CSUM? That >>> would be so much more straightforward and support nearly all use cases >>> without needing to jump through all these hoops. >> >> Well, the description says: >> >> --- >> Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM. >> It means that device can fill TCP/UDP-like checksum anywhere in the packets >> whatever headers there might be. >> --- >> >> The device can't do whatever, wherever. There is always a limit to the offset to the inner headers that can be handled, for instance. >> > If the device does NETIF_F_HW_CSUM then inner/outer headers are > irrelevant at least in the non-GSO case. All the device needs to do is > compute the checksum from start and write the answer at the given > offset. No protocol awareness needed in the device, no need to parse > headers on transmit. Tom, could you elaborate a little further on the semantics/requirements for devices supporting NETIF_F_HW_CSUM, clearly (as mentioned in > I have the same complaint that ixgbe requires a bunch of driver logic > to offload VXLAN checksum unnecessary instead of just providing > CHECKSUM_COMPLETE which would work with any encapsulation protocol, > require no encapsulation awareness in the device, and should be a much > simpler driver implementation.