From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA1A9C433E0 for ; Fri, 22 Jan 2021 02:49:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8374D23884 for ; Fri, 22 Jan 2021 02:49:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726182AbhAVCtO (ORCPT ); Thu, 21 Jan 2021 21:49:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726160AbhAVCtH (ORCPT ); Thu, 21 Jan 2021 21:49:07 -0500 Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17951C061756 for ; Thu, 21 Jan 2021 18:48:27 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id e15so2289370vsa.0 for ; Thu, 21 Jan 2021 18:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u09ut0byqFUddeY2/rMH8bRUHh6CpXCKKgNy2e/b3Gc=; b=okIBxEfzYdSGyoEZS2A3lVJwCUTH5orhqvj09z5FuPM4BxAEPWjO6Xg28WscFQ8cch eCGdGpLVNc2fIsSLyqWNMGqUn4udZG37VD+C7kdnlQ1BXecm3H8y7icERAh5AytIFJSI Qjl+Fpok7/We4li7Yd3bcjDchOWvqZiL3JHJLZviTT9evbqNpbYvutIUGTozncSwJTJl CCGFzJPWIOng2MsB9P1h3LX0ewebl4vuHxv+MRFdHYYVYyd9Mo2BfA3CUlbEMiB+/n2a GAerCfQ0TuVY0/HPsuP5eGBhgxMLvJIJtpc7kEwVXeDUEsknWsT0yS6+buVD6n+eGHhv cAOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u09ut0byqFUddeY2/rMH8bRUHh6CpXCKKgNy2e/b3Gc=; b=SlZP2V/ROXHDJF5GrtvkV3cB8Hc8gVA0gDvD12G5YEzuGGgrx1WnMzqMIdiz7/SDhx dUMj1M3O2VR5411Z2HvImxzj7Dn2DYDs5raqkXzM3endsXkmmiHPtYQ3PkbY2fUjdfb/ r23RyXVirGg9bhWrV3DkO7hU2uv+6shpz8+szMP9YzMfHLOwdilRE7LfsmyevH3/Vr5X scG9+ByetAcNA74EQ6c9bVTT+WiFl5ztN82hIHyHZ22oXRPfMSeTknL0CbzW8NNFgvwy 0EBlZ6ZkZj26x0PgwAf9+Dw7MB2cAz1AQMQshSXug4GH9VgbzkyY06eNlLG/csiUKHUE 8eAw== X-Gm-Message-State: AOAM533LT3trw/U6FszOZywDShspEY3+FTAxjNSm9Xei4NhCOV1/zhvq SPpJaMUiLXRE99rIwDV0UX+4oFL0azE= X-Google-Smtp-Source: ABdhPJwabF268dLSIrixRemOBcrR9shW38VZHW/slO/p8rumv0sew8obN1TYN81Hc8tiard/N5iRVA== X-Received: by 2002:a67:fd88:: with SMTP id k8mr1666704vsq.52.1611283705671; Thu, 21 Jan 2021 18:48:25 -0800 (PST) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com. [209.85.217.51]) by smtp.gmail.com with ESMTPSA id r79sm1049587vkr.42.2021.01.21.18.48.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 18:48:24 -0800 (PST) Received: by mail-vs1-f51.google.com with SMTP id s2so2285413vsk.2 for ; Thu, 21 Jan 2021 18:48:24 -0800 (PST) X-Received: by 2002:a67:cb1a:: with SMTP id b26mr1999163vsl.22.1611283703865; Thu, 21 Jan 2021 18:48:23 -0800 (PST) MIME-Version: 1.0 References: <20210118193122.87271-1-alobakin@pm.me> <20210118193232.87583-1-alobakin@pm.me> <20210118193232.87583-2-alobakin@pm.me> In-Reply-To: <20210118193232.87583-2-alobakin@pm.me> From: Willem de Bruijn Date: Thu, 21 Jan 2021 21:47:47 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next 2/2] udp: allow forwarding of plain (non-fraglisted) UDP GRO packets To: Alexander Lobakin Cc: "David S. Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , Steffen Klassert , Alexander Duyck , Paolo Abeni , Igor Russkikh , Mauro Carvalho Chehab , Miaohe Lin , Antoine Tenart , Michal Kubecek , Andrew Lunn , Meir Lichtinger , Aya Levin , Florian Fainelli , linux-kernel , Network Development Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 18, 2021 at 2:33 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. > Commit 2e4ef10f5850 ("net: add GSO UDP L4 and GSO fraglists to the > list of software-backed types") added GSO UDP L4 to the list of > software GSO to allow virtual netdevs to forward them as is up to > the real drivers. > > 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. > 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. That is surprising. The choice for fraglist based forwarding was made on the assumption that it is cheaper if software segmentation is needed. Do you have a more specific definition of the relevant cases? There currently is no option to enable GRO for forwarding, without fraglist if to a device with h/w udp segmentation offload. This would add that option too. Though under admin control, which may make it a rarely exercised option. Assuming most hosts to have single or homogeneous NICs, the OS should be able to choose the preferred option in most cases (e.g.,: use fraglist unless all devices support h/w gro). > Add the last element and allow to form plain UDP GRO packets if > there is no socket -> we are on forwarding path, and the new > NETIF_F_GRO_UDP is enabled on a receiving netdevice. > Note that fraglisted UDP GRO now also depends on this feature, as That may cause a regression for applications that currently enable that device feature. > NETIF_F_GRO_FRAGLIST isn't tied to any particular L4 protocol. > > Signed-off-by: Alexander Lobakin > --- > net/ipv4/udp_offload.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c > index ff39e94781bf..781a035de5a9 100644 > --- a/net/ipv4/udp_offload.c > +++ b/net/ipv4/udp_offload.c > @@ -454,13 +454,19 @@ struct sk_buff *udp_gro_receive(struct list_head *head, struct sk_buff *skb, > struct sk_buff *p; > struct udphdr *uh2; > unsigned int off = skb_gro_offset(skb); > - int flush = 1; > + int flist = 0, flush = 1; > + bool gro_by_feat = false; What is this variable shorthand for? By feature? Perhaps gro_forwarding is more descriptive. > > - NAPI_GRO_CB(skb)->is_flist = 0; > - if (skb->dev->features & NETIF_F_GRO_FRAGLIST) > - NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1; > + if (skb->dev->features & NETIF_F_GRO_UDP) { > + if (skb->dev->features & NETIF_F_GRO_FRAGLIST) > + flist = !sk || !udp_sk(sk)->gro_enabled; > > - if ((sk && udp_sk(sk)->gro_enabled) || NAPI_GRO_CB(skb)->is_flist) { I would almost rename NETIF_F_GRO_FRAGLIST to NETIF_F_UDP_GRO_FWD. Then this could be a !NETIF_F_UDP_GRO_FWD_FRAGLIST toggle on top of that. If it wasn't for this fraglist option also enabling UDP GRO to local sockets if set. That is, if the performance difference is significant enough to require supporting both types of forwarding, under admin control. Perhaps the simplest alternative is to add the new feature without making fraglist dependent on it: if ((sk && udp_sk(sk)->gro_enabled) || (skb->dev->features & NETIF_F_GRO_FRAGLIST) || (!sk && skb->dev->features & NETIF_F_GRO_UDP_FWD)) > + gro_by_feat = !sk || flist; > + } > + > + NAPI_GRO_CB(skb)->is_flist = flist; > + > + if (gro_by_feat || (sk && udp_sk(sk)->gro_enabled)) { > pp = call_gro_receive(udp_gro_receive_segment, head, skb); > return pp; > } > -- > 2.30.0 > >