[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S36-CAWVme16XOT6Gj5HnkFCbkQgsSBPVjXbzWbRLnqYuw@mail.gmail.com>
Date: Wed, 2 Sep 2015 16:21:16 -0700
From: Tom Herbert <tom@...bertland.com>
To: "Rustad, Mark D" <mark.d.rustad@...el.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>,
"jogreene@...hat.com" <jogreene@...hat.com>
Subject: Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx
checksum offload
On Wed, Sep 2, 2015 at 9:46 AM, Rustad, Mark D <mark.d.rustad@...el.com> wrote:
>> On Sep 1, 2015, at 8:17 PM, Tom Herbert <tom@...bertland.com> wrote:
>>
>> I suspect this is not UDP-encapsulation specific, will it work with
>> TCP/IP/IP, TCP/IP/GRE etc.?
>
Mark, another question in this area of code. Looking at ixgbe_tx_csum,
I'm wondering what happens with those default cases for the switch
statements. If those are hit for whatever reason does that mean the
checksum is never resolved? It seems like if the device couldn't
handle these cases then skb_checksum_help should be called to set the
checksum. In particular I am wondering what happens in the case that a
TCP or UDP packet is sent in IPv6 with an extension header present (so
default is taken in switch (l4_hdr)). Would the checksum be properly
set in this case?
Thanks,
Tom
> It could do more, but this is what has been tested up to this point.
>
>> 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.
>
> --
> Mark Rustad, Networking Division, Intel Corporation
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists