All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next PATCH v3 11/15] i40e/i40evf: Enable support for SKB_GSO_UDP_TUNNEL_CSUM
Date: Tue, 2 Feb 2016 16:06:56 -0800	[thread overview]
Message-ID: <CAKgT0UfXKTyxaf35aO-eyizhsNyDVLMTLNi3KB7XpPeQ8k44KA@mail.gmail.com> (raw)
In-Reply-To: <20160202144924.0000795d@unknown>

On Tue, Feb 2, 2016 at 2:49 PM, Jesse Brandeburg
<jesse.brandeburg@intel.com> wrote:
> On Sun, 24 Jan 2016 21:17:29 -0800
> Alexander Duyck <aduyck@mirantis.com> wrote:
>
>> The XL722 has support for providing the outer UDP tunnel checksum on
>
> X722, not XL722
>
>> transmits.  Make use of this feature to support segmenting UDP tunnels with
>> outer checksums enabled.
>>
>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>> ---
>
> ...
>
>> +             if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM) {
>> +                     /* determine offset of outer transport header */
>> +                     l4_offset = l4.hdr - skb->data;
>> +
>> +                     /* remove payload length from outer checksum */
>> +                     paylen = (__force u16)l4.udp->check;
>> +                     paylen += ntohs(1) * (u16)~(skb->len - l4_offset);
>
> Can we get a comment about how this is supposed to work?  Doesn't it
> have endian problems?  I understand these lines are removing the payload
> length from the checksum by getting the length of the payload,
> inverting it and removing it from the checksum, and then below,
> updating the checksum, but it is really hard to follow why you use
> ntohs(1) without some explanation.

The logic is actually based off of
csum_tcpudp_nofold(http://lxr.free-electrons.com/source/lib/checksum.c#L193).
The byte swapping is taken care of via a combination of the ntohs
which converts to a shift, and the csum_fold call below.  What happens
is that by shifting by 8 we push the lower byte into the upper slot,
and the upper slot into the next 16 bits.  Then when csum_fold is run
it shifts the upper 16 bits down by 16 and adds them to the lower 16
which takes care of the other half of the rotation.

>> +                     l4.udp->check = ~csum_fold((__force __wsum)paylen);
>> +             }
>> +

  parent reply	other threads:[~2016-02-03  0:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25  5:16 [Intel-wired-lan] [next PATCH v3 00/15] TSO and checksum fixes for i40e Alexander Duyck
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 01/15] i40e/i40evf: Drop outer checksum offload that was not requested Alexander Duyck
2016-01-27 16:00   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 02/15] i40e/i40evf: Use u64 values instead of casting them in TSO function Alexander Duyck
2016-01-27 16:03   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 03/15] i40e/i40evf: Factor out L4 header and checksum from L3 bits in TSO path Alexander Duyck
2016-01-27 16:09   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 04/15] i40e/i40evf: Consolidate all header changes into TSO function Alexander Duyck
2016-01-27 16:14   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 05/15] i40e/i40evf: Replace header pointers with unions of pointers in Tx checksum path Alexander Duyck
2016-01-27 16:27   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 06/15] i40e/i40evf: Add support for IPv4 encapsulated in IPv6 Alexander Duyck
2016-01-27 18:04   ` Bowers, AndrewX
2016-01-25  5:16 ` [Intel-wired-lan] [next PATCH v3 07/15] i40e/i40evf: Handle IPv6 extension headers in checksum offload Alexander Duyck
2016-01-27 18:05   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 08/15] i40e/i40evf: Do not write to descriptor unless we complete Alexander Duyck
2016-01-27 18:07   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 09/15] i40e/i40evf: Add exception handling for Tx checksum Alexander Duyck
2016-01-27 18:08   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 10/15] i40e/i40evf: Clean-up Rx packet checksum handling Alexander Duyck
2016-01-27 18:09   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 11/15] i40e/i40evf: Enable support for SKB_GSO_UDP_TUNNEL_CSUM Alexander Duyck
2016-01-27 18:17   ` Bowers, AndrewX
2016-02-02 22:49   ` Jesse Brandeburg
2016-02-02 23:10     ` Jesse Brandeburg
2016-02-02 23:18       ` Jesse Brandeburg
2016-02-03  0:06     ` Alexander Duyck [this message]
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 12/15] i40e: Fix ATR in relation to tunnels Alexander Duyck
2016-01-25 19:27   ` Patil, Kiran
2016-01-25 22:21     ` Alexander Duyck
2016-01-26  0:16       ` Patil, Kiran
2016-01-27 18:18   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 13/15] i40e: Do not drop support for IPv6 VXLAN or GENEVE tunnels Alexander Duyck
2016-01-27 18:26   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 14/15] i40e: Update feature flags to reflect newly enabled features Alexander Duyck
2016-01-27 18:44   ` Bowers, AndrewX
2016-01-25  5:17 ` [Intel-wired-lan] [next PATCH v3 15/15] i40evf: " Alexander Duyck
2016-01-25 19:43   ` Singhai, Anjali
2016-01-27 18:45   ` Bowers, AndrewX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKgT0UfXKTyxaf35aO-eyizhsNyDVLMTLNi3KB7XpPeQ8k44KA@mail.gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.