From: Mohamed Khalfella <mkhalfella@purestorage.com>
To: Eric Dumazet <edumazet@google.com>
Cc: willemdebruijn.kernel@gmail.com, alexanderduyck@fb.com,
bpf@vger.kernel.org, brouer@redhat.com, davem@davemloft.net,
dhowells@redhat.com, keescook@chromium.org, kuba@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, willemb@google.com, stable@vger.kernel.org
Subject: Re: [PATCH v2] skbuff: skb_segment, Call zero copy functions before using skbuff frags
Date: Thu, 31 Aug 2023 00:29:57 -0700 [thread overview]
Message-ID: <20230831072957.GA3696339@medusa> (raw)
In-Reply-To: <CANn89iJVnS_dGDtU7AVWgVrun-p68DZ0A3Pde47MHNeeQ2nwRA@mail.gmail.com>
On 2023-08-31 08:58:51 +0200, Eric Dumazet wrote:
> On Thu, Aug 31, 2023 at 1:28 AM Mohamed Khalfella
> <mkhalfella@purestorage.com> wrote:
> > do {
> > struct sk_buff *nskb;
> > skb_frag_t *nskb_frag;
> > @@ -4465,6 +4471,10 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> > (skb_headlen(list_skb) == len || sg)) {
> > BUG_ON(skb_headlen(list_skb) > len);
> >
> > + nskb = skb_clone(list_skb, GFP_ATOMIC);
> > + if (unlikely(!nskb))
> > + goto err;
> > +
>
> This patch is quite complex to review, so I am asking if this part was
> really needed ?
Unfortunately the patch is complex because I try to avoid calling
skb_orphan_frags() in the middle of processing these frags. Otherwise
it would be much harder to implement because as reallocated frags do not
map 1:1 with existing frags as Willem mentioned.
> <1> : You moved here <2> and <3>
<2> was moved here because skb_clone() calls skb_orphan_frags(). By
moving this up we do not need to call skb_orphan_frags() for list_skb
and we can start to use nr_frags and frags without worrying their value
is going to change.
<3> was moved here because <2> was moved here. Fail fast if we can not
clone list_skb.
>
> If this is not strictly needed, please keep the code as is to ease
> code review...
>
> > i = 0;
> > nfrags = skb_shinfo(list_skb)->nr_frags;
> > frag = skb_shinfo(list_skb)->frags;
> > @@ -4483,12 +4493,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> > frag++;
> > }
> >
> > - nskb = skb_clone(list_skb, GFP_ATOMIC);
>
> <2>
>
> > list_skb = list_skb->next;
> >
> > - if (unlikely(!nskb))
> > - goto err;
> > -
>
> <3>
>
> > if (unlikely(pskb_trim(nskb, len))) {
> > kfree_skb(nskb);
> > goto err;
> > @@ -4564,12 +4570,16 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
> > skb_shinfo(nskb)->flags |= skb_shinfo(head_skb)->flags &
> > SKBFL_SHARED_FRAG;
> >
> > - if (skb_orphan_frags(frag_skb, GFP_ATOMIC) ||
> > - skb_zerocopy_clone(nskb, frag_skb, GFP_ATOMIC))
> > + if (skb_zerocopy_clone(nskb, list_skb, GFP_ATOMIC))
>
> Why using list_skb here instead of frag_skb ?
> Again, I have to look at the whole thing to understand why you did this.
Oops, this is a mistake. It should be frag_skb. Will fix it run the test
one more time and post v3.
next prev parent reply other threads:[~2023-08-31 7:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 23:32 [PATCH] skbuff: skb_segment, Update nfrags after calling zero copy functions Mohamed Khalfella
2023-08-29 4:18 ` willemjdebruijn
2023-08-29 6:50 ` Mohamed Khalfella
2023-08-29 8:07 ` Eric Dumazet
2023-08-29 9:31 ` Mohamed Khalfella
2023-08-29 10:09 ` Eric Dumazet
2023-08-29 22:24 ` Mohamed Khalfella
2023-08-30 3:44 ` Eric Dumazet
2023-08-30 23:28 ` [PATCH v2] skbuff: skb_segment, Call zero copy functions before using skbuff frags Mohamed Khalfella
2023-08-31 6:58 ` Eric Dumazet
2023-08-31 7:29 ` Mohamed Khalfella [this message]
2023-08-31 7:43 ` Eric Dumazet
2023-08-31 8:17 ` [PATCH v3] " Mohamed Khalfella
2023-08-31 8:47 ` Eric Dumazet
2023-09-01 7:10 ` patchwork-bot+netdevbpf
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=20230831072957.GA3696339@medusa \
--to=mkhalfella@purestorage.com \
--cc=alexanderduyck@fb.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@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.