All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Alexander Duyck <alexander.duyck@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 5/8] udp: Partially unroll handling of first segment and last segment
Date: Sat, 5 May 2018 10:37:32 +0200	[thread overview]
Message-ID: <CAF=yD-J9iK6oWgV5L9gBty8L3AZTb8Rf0HjPz4_-5uz0k00rrA@mail.gmail.com> (raw)
In-Reply-To: <20180504183019.5194.47789.stgit@localhost.localdomain>

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 allows us to take care of unrolling the first segment and the
> last segment

Only the last segment needs to be unrolled, right?

> of the loop for processing the segmented skb. Part of the
> motivation for this is that it makes it easier to process the fact that the
> first fame and all of the frames in between should be mostly identical
> in terms of header data, and the last frame has differences in the length
> and partial checksum.
>
> In addition I am dropping the header length calculation since we don't
> really need it for anything but the last frame and it can be easily
> obtained by just pulling the data_len and offset of tail from the transport
> header.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
> v2: New break-out patch based on one patch from earlier series
>
>  net/ipv4/udp_offload.c |   35 ++++++++++++++++++++---------------
>  1 file changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 5c4bb8b9e83e..946d06d2aa0c 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -193,7 +193,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>         struct sk_buff *seg, *segs = ERR_PTR(-EINVAL);
>         struct sock *sk = gso_skb->sk;
>         unsigned int sum_truesize = 0;
> -       unsigned int hdrlen;
>         struct udphdr *uh;
>         unsigned int mss;
>         __sum16 check;
> @@ -206,7 +205,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>         if (!pskb_may_pull(gso_skb, sizeof(*uh)))
>                 goto out;
>
> -       hdrlen = gso_skb->data - skb_mac_header(gso_skb);
>         skb_pull(gso_skb, sizeof(*uh));
>
>         /* clear destructor to avoid skb_segment assigning it to tail */
> @@ -219,7 +217,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>                 return segs;
>         }
>
> -       uh = udp_hdr(segs);
> +       seg = segs;
> +       uh = udp_hdr(seg);
>
>         /* compute checksum adjustment based on old length versus new */
>         newlen = htons(sizeof(*uh) + mss);
> @@ -227,25 +226,31 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
>                                             ((__force u32)uh->len ^ 0xFFFF) +
>                                             (__force u32)newlen));
>
> -       for (seg = segs; seg; seg = seg->next) {
> -               uh = udp_hdr(seg);
> +       for (;;) {
> +               seg->destructor = sock_wfree;
> +               seg->sk = sk;
> +               sum_truesize += seg->truesize;
>
> -               /* last packet can be partial gso_size */
> -               if (!seg->next) {
> -                       newlen = htons(seg->len - hdrlen);
> -                       check = ~csum_fold((__force __wsum)((__force u32)uh->check +
> -                                                           ((__force u32)uh->len ^ 0xFFFF) +
> -                                                           (__force u32)newlen));
> -               }
> +               if (!seg->next)
> +                       break;

Not critical, but I find replacing

  for (seg = segs; seg; seg = seg->next) {
    uh = udp_hdr(seg);
    ...
  }

with

  uh = udp_hdr(seg);
  for (;;) {
    ...
    if (!seg->next)
      break;

    uh = udp_hdr(seg);
  }

much less easy to parse and it inflates patch size. How about just

  - for (seg = segs; seg; seg = seg->next)
  + for( seg = segs; seg->next; seg = seg->next)


>
>                 uh->len = newlen;
>                 uh->check = check;
>
> -               seg->destructor = sock_wfree;
> -               seg->sk = sk;
> -               sum_truesize += seg->truesize;
> +               seg = seg->next;
> +               uh = udp_hdr(seg);
>         }
>
> +       /* last packet can be partial gso_size, account for that in checksum */
> +       newlen = htons(skb_tail_pointer(seg) - skb_transport_header(seg) +
> +                      seg->data_len);
> +       check = ~csum_fold((__force __wsum)((__force u32)uh->check +
> +                                           ((__force u32)uh->len ^ 0xFFFF)  +
> +                                           (__force u32)newlen));
> +       uh->len = newlen;
> +       uh->check = check;
> +
> +       /* update refcount for the packet */
>         refcount_add(sum_truesize - gso_skb->truesize, &sk->sk_wmem_alloc);
>  out:
>         return segs;
>

  reply	other threads:[~2018-05-05  8:38 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
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 [this message]
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='CAF=yD-J9iK6oWgV5L9gBty8L3AZTb8Rf0HjPz4_-5uz0k00rrA@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.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.