public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dongseok Yi" <dseok.yi@samsung.com>
To: "'Alexander Duyck'" <alexander.duyck@gmail.com>,
	"'Alexander Lobakin'" <alobakin@pm.me>,
	"'David S. Miller'" <davem@davemloft.net>,
	"'Jakub Kicinski'" <kuba@kernel.org>
Cc: "'Eric Dumazet'" <edumazet@google.com>,
	"'Edward Cree'" <ecree@solarflare.com>,
	"'Willem de Bruijn'" <willemb@google.com>,
	"'Steffen Klassert'" <steffen.klassert@secunet.com>,
	"'Alexey Kuznetsov'" <kuznet@ms2.inr.ac.ru>,
	"'Hideaki YOSHIFUJI'" <yoshfuji@linux-ipv6.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next] udp: allow forwarding of plain (non-fraglisted) UDP GRO packets
Date: Wed, 13 Jan 2021 12:59:45 +0900	[thread overview]
Message-ID: <001401d6e960$87cab7b0$97602710$@samsung.com> (raw)
In-Reply-To: <6fb72534-d4d4-94d8-28d1-aabf16e11488@gmail.com>

On 2021-01-13 12:10, Alexander Duyck wrote:
> On 1/12/21 1:16 PM, Alexander Lobakin wrote:
> > Commit 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") actually
> > not only added a support for fraglisted UDP GRO, but also tweaked
> > some logics the way that non-fraglisted UDP GRO started to work for
> > forwarding too.
> > Tests showed that currently forwarding and NATing of plain UDP GRO
> > packets are performed fully correctly, regardless if the target
> > netdevice has a support for hardware/driver GSO UDP L4 or not.
> > Add the last element and allow to form plain UDP GRO packets if
> > there is no socket -> we are on forwarding path.
> >

Your patch is very similar with the RFC what I submitted but has
different approach. My concern was NAT forwarding.
https://lore.kernel.org/patchwork/patch/1362257/

Nevertheless, I agreed with your idea that allow fraglisted UDP GRO
if there is socket.

> > Plain UDP GRO forwarding even shows better performance than fraglisted
> > UDP GRO in some cases due to not wasting one skbuff_head per every
> > segment.
> >
> > Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> > ---
> >   net/ipv4/udp_offload.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > index ff39e94781bf..9d71df3d52ce 100644
> > --- a/net/ipv4/udp_offload.c
> > +++ b/net/ipv4/udp_offload.c
> > @@ -460,12 +460,13 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb,
> >   	if (skb->dev->features & NETIF_F_GRO_FRAGLIST)
> >   		NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1;

is_flist can be true even if !sk.

> >
> > -	if ((sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist) {
> > +	if (!sk || (sk && udp_sk(sk)->gro_enabled) ||

Actually sk would be NULL by udp_encap_needed_key in udp4_gro_receive
or udp6_gro_receive.

> > +	    NAPI_GRO_CB(skb)->is_flist) {
> >   		pp = call_gro_receive(udp_gro_receive_segment, head, skb);

udp_gro_receive_segment will check is_flist first and try to do
fraglisted UDP GRO. Can you check what I'm missing?

> >   		return pp;
> >   	}
> >
> 
> The second check for sk in "(sk && udp_sk(sk)->gro_enabled)" is
> redundant and can be dropped. You already verified it is present when
> you checked for !sk before the logical OR.
> 

Sorry, Alexander Duyck. I believe Alexander Lobakin will answer this.

> > -	if (!sk || NAPI_GRO_CB(skb)->encap_mark ||
> > +	if (NAPI_GRO_CB(skb)->encap_mark ||
> >   	    (skb->ip_summed != CHECKSUM_PARTIAL &&
> >   	     NAPI_GRO_CB(skb)->csum_cnt == 0 &&
> >   	     !NAPI_GRO_CB(skb)->csum_valid) ||
> >



  reply	other threads:[~2021-01-13  4:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 21:16 [PATCH net-next] udp: allow forwarding of plain (non-fraglisted) UDP GRO packets Alexander Lobakin
2021-01-13  3:10 ` Alexander Duyck
2021-01-13  3:59   ` Dongseok Yi [this message]
2021-01-13 10:05     ` Alexander Lobakin

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='001401d6e960$87cab7b0$97602710$@samsung.com' \
    --to=dseok.yi@samsung.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alobakin@pm.me \
    --cc=davem@davemloft.net \
    --cc=ecree@solarflare.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=willemb@google.com \
    --cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox