[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180917090323.GF23674@gauss3.secunet.de>
Date: Mon, 17 Sep 2018 11:03:24 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC: <netdev@...r.kernel.org>, <pabeni@...hat.com>,
<davem@...emloft.net>, Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next RFC 7/8] udp: gro behind static key
On Fri, Sep 14, 2018 at 01:59:40PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@...gle.com>
>
> Avoid the socket lookup cost in udp_gro_receive if no socket has a
> gro callback configured.
>
> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
...
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 4f6aa95a9b12..f44fe328aa0f 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct list_head *head,
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
>
> - if (unlikely(!uh))
> + if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> goto flush;
If you use udp_encap_needed_key to enalbe UDP GRO, then a UDP
encapsulation socket will enable it too. Not sure if this is
intentional.
That said, enabling UDP GRO on a UDP encapsulation socket
(ESP in UPD etc.) will fail badly as then encrypted ESP
packets might be merged together. So we somehow should
make sure that this does not happen.
Anyway, this reminds me that we can support GRO for
UDP encapsulation. It just requires separate GRO
callbacks for the different encapsulation types.
Powered by blists - more mailing lists