All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [net-next PATCH v2 4/8] udp: Do not pass checksum as a parameter to GSO segmentation
Date: Sat, 5 May 2018 10:39:21 -0700	[thread overview]
Message-ID: <CAKgT0UdEE7=eQDmOM+aWjNWc1QdYOWCPz+SAfBNZQT6AS5q-hA@mail.gmail.com> (raw)
In-Reply-To: <CAF=yD-LV7JkTkX-c7wyvjYNGW872H5GPbwRfL6M+SfRzL4cb_w@mail.gmail.com>

On Sat, May 5, 2018 at 3:01 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, May 4, 2018 at 8:30 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This patch is meant to allow us to avoid having to recompute the checksum
>> from scratch and have it passed as a parameter.
>>
>> Instead of taking that approach we can take advantage of the fact that the
>> length that was used to compute the existing checksum is included in the
>> UDP header. If we cancel that out by adding the value XOR with 0xFFFF we
>> can then just add the new length in and fold that into the new result.
>>
>> I think this may be fixing a checksum bug in the original code as well
>> since the checksum that was passed included the UDP header in the checksum
>> computation, but then excluded it for the adjustment on the last frame. I
>> believe this may have an effect on things in the cases where the two differ
>> by bits that would result in things crossing the byte boundaries.
>
> The replacement code, below, subtracts original payload size then adds
> the new payload size. mss here excludes the udp header size.
>
>>                 /* last packet can be partial gso_size */
>> -               if (!seg->next)
>> -                       csum_replace2(&uh->check, htons(mss),
>> -                                     htons(seg->len - hdrlen - sizeof(*uh)));

That is my point. When you calculated your checksum you included the
UDP header in the calculation.

-       return __udp_gso_segment(gso_skb, features,
-                                udp_v4_check(sizeof(struct udphdr) + mss,
-                                             iph->saddr, iph->daddr, 0));

Basically the problem is in one spot you are adding the sizeof(struct
udphdr) + mss and then in another you are cancelling it out as mss and
trying to account for it by also dropping the UDP header from the
payload length of the value you are adding. That works in the cases
where the effect doesn't cause any issues with the byte ordering,
however I think when mss + 8 crosses a byte boundary it can lead to
issues since the calculation is done on a byte swapped value.

  reply	other threads:[~2018-05-05 17:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 18:28 [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups Alexander Duyck
2018-05-04 18:28 ` [net-next PATCH v2 1/8] udp: Record gso_segs when supporting UDP segmentation offload Alexander Duyck
2018-05-05  8:23   ` Willem de Bruijn
2018-05-04 18:29 ` [net-next PATCH v2 2/8] udp: Verify that pulling UDP header in GSO segmentation doesn't fail Alexander Duyck
2018-05-04 20:07   ` Eric Dumazet
2018-05-05  8:12   ` Willem de Bruijn
2018-05-05 17:10     ` Alexander Duyck
2018-05-04 18:29 ` [net-next PATCH v2 3/8] udp: Do not pass MSS as parameter to GSO segmentation Alexander Duyck
2018-05-04 20:08   ` Eric Dumazet
2018-05-05  8:13     ` Willem de Bruijn
2018-05-04 18:30 ` [net-next PATCH v2 4/8] udp: Do not pass checksum as a " Alexander Duyck
2018-05-04 20:19   ` Eric Dumazet
2018-05-04 22:28     ` Alexander Duyck
2018-05-05 10:01   ` Willem de Bruijn
2018-05-05 17:39     ` Alexander Duyck [this message]
2018-05-06 17:17       ` Willem de Bruijn
2018-05-06 22:29         ` Alexander Duyck
2018-05-04 18:30 ` [net-next PATCH v2 5/8] udp: Partially unroll handling of first segment and last segment Alexander Duyck
2018-05-05  8:37   ` Willem de Bruijn
2018-05-05 17:13     ` Alexander Duyck
2018-05-04 18:31 ` [net-next PATCH v2 6/8] udp: Add support for software checksum and GSO_PARTIAL with GSO offload Alexander Duyck
2018-05-06 21:50   ` Willem de Bruijn
2018-05-06 22:13     ` Alexander Duyck
2018-05-04 18:31 ` [net-next PATCH v2 7/8] udp: Do not copy destructor if one is not present Alexander Duyck
2018-05-05  8:45   ` Willem de Bruijn
2018-05-04 18:31 ` [net-next PATCH v2 8/8] net: Add NETIF_F_GSO_UDP_L4 to list of GSO offloads with fallback Alexander Duyck
2018-05-05 10:06 ` [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups Willem de Bruijn
2018-05-07 18:02   ` Alexander Duyck
2018-05-09 15:39     ` Willem de Bruijn
2018-05-09 15:58       ` Alexander Duyck

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='CAKgT0UdEE7=eQDmOM+aWjNWc1QdYOWCPz+SAfBNZQT6AS5q-hA@mail.gmail.com' \
    --to=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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.