Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3835388ybf; Tue, 3 Mar 2020 13:51:28 -0800 (PST) X-Google-Smtp-Source: ADFU+vsFIAW5f6ieL1nTFNWIWLobck5gbzL1nQ7Gu0A04SRYja1uM8Lg1Tj5UlxFUpz7IX4wjGY+ X-Received: by 2002:aca:1a17:: with SMTP id a23mr440928oia.84.1583272288748; Tue, 03 Mar 2020 13:51:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583272288; cv=none; d=google.com; s=arc-20160816; b=0entXmEs0sGF0+HjcHUl9ngp7snXOq59rJWs3zBqPUOnZlXvkJjaIHEx1RJ6BOuYoZ NmWuFMfu5twtZPOMFROjcQ9le5E2BbovrNZ1RpP0EhMPxUywHngXV9vIfMM5yw7isez8 gkiy4UNZdWG9XIcj5zZVDqK+F9TZB2wVtJ6zQAD3nLa93+utr0hn2H+ruLjmfg4cmout YSdYsGCTOSM+vfMhKH3OLtniZZqMvrTZMJP2iSe25Q4MNfktzP0munGxpALwzT5RGmmM 8y38l8M2S2Kgu8IXdA42GPy43y94EnSBkieg6al+pPYnO3VP1RULL9SbWbLX+Ocqppp0 k5bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Jhw2/hBTqqb08+XbLqFc1lQG7+XacrKgacG+f+lhHlw=; b=akYV/DaPITsqyYO8F6dCMGtj22IQVAK0SAm5lWHx62kcG0v7947buQHVt4a5Nq6FaK 16Ay4Sg9llCMnNYBsipWLM2g1N1e6keHTS2f6K8LwJQ0FM4tu3HA3UhCx+MKe093sd2Q QLJVoaI27ZbCjyMO45/299uK/Aq9Pnww4NFvhOAetSSVO4USBSRBNf9oLF82MkII6sP1 +xeIgHFeVStR3wjtP9la+BQxR65Pe6oOLl8T+49+PJbQz76QlX4Mxrx0dgKIeRoCH5GX yh7tAvT9VfTC7nPAoykZzQOpQ4NVaKOvX924PlR/+CafQO7/lLOaE9pP+b53vYRFfAjI Ng+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Uuswdbwt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g23si4579240otr.31.2020.03.03.13.51.17; Tue, 03 Mar 2020 13:51:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Uuswdbwt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732347AbgCCVK4 (ORCPT + 99 others); Tue, 3 Mar 2020 16:10:56 -0500 Received: from mail-yw1-f67.google.com ([209.85.161.67]:43038 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730925AbgCCVK4 (ORCPT ); Tue, 3 Mar 2020 16:10:56 -0500 Received: by mail-yw1-f67.google.com with SMTP id p69so77327ywh.10 for ; Tue, 03 Mar 2020 13:10:54 -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=Jhw2/hBTqqb08+XbLqFc1lQG7+XacrKgacG+f+lhHlw=; b=UuswdbwtGUq/KOpTGPSUcHmuRFxUeMPpUUcP4c3+mgsuAAZ1wqfnSivQRMp7zhqP2i yvBWIw6bqMhNA/DPbB71aQ0wCjAsjDNSGE4vvK+62X9DlD438J/f+Nj2df/aPLkpKMfF 5ocn7OG+YEKPkfrWpPgr+GcwXyvyAQ/mWC5rmoLddKOt9BLvUI7SMHMb7Fw9CVC1Brwp 7oBlwlgyME+tIP2gNltFHprtxkzqmd46EM7RAj60QXtKXqz8qLiEzu7thzKr+f14dQCa wqB5jjXoBB8PCTZRigPCyuFoqbQRvn1jgnb6lYeX9vn9ADIMgGrH9qfcDDR7AZ4WBOg6 zscQ== 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=Jhw2/hBTqqb08+XbLqFc1lQG7+XacrKgacG+f+lhHlw=; b=hfPX5AZNfS+0EgdxriTPFvbnQ3F0kvaVAFafjh80cUSn2cLWNWHT05C3/EQxINaZG4 C4+gFbBhnr5cKmtm6etBmgrMhzGb/JRXMpgNpmjAueX5ZXp4wnQvYqQbA1aY7PT3Xx4I 9obaVEcPHEw13ZB3zx/z+IFVNaZ9p1xnM8K+F/FFSyP4tisAE2fwhNA3EcDWtP2oOC/y kVTEMaiAFB+Ztbe4WQB+4cDkxvjIjduG3jWS47FNdrQ3hLjlomry5tSzr9RGKTMb5Rfm eQIe3ObEBrZmfLcHVDp2BKrDwmka7e/e7IHFC/vMPQEG9mM+8y7u5Nq9ZyklFiU5Y3PY 6nNQ== X-Gm-Message-State: ANhLgQ1h36YkrIU1yWl8CyeGJTToiTUj2mmhbF0ovoJCzb1OGFeTZj75 c+D/8jm3U/tD3mg8elYeD435zuB/ X-Received: by 2002:a81:b627:: with SMTP id u39mr6618523ywh.180.1583269853034; Tue, 03 Mar 2020 13:10:53 -0800 (PST) Received: from mail-yw1-f53.google.com (mail-yw1-f53.google.com. [209.85.161.53]) by smtp.gmail.com with ESMTPSA id d6sm4834539ywc.8.2020.03.03.13.10.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2020 13:10:52 -0800 (PST) Received: by mail-yw1-f53.google.com with SMTP id 10so112412ywv.5 for ; Tue, 03 Mar 2020 13:10:51 -0800 (PST) X-Received: by 2002:a0d:d68d:: with SMTP id y135mr2472118ywd.117.1583269851243; Tue, 03 Mar 2020 13:10:51 -0800 (PST) MIME-Version: 1.0 References: <20200228105435.75298-1-lrizzo@google.com> <20200228110043.2771fddb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <3c27d9c0-eb17-b20f-2d10-01f3bdf8c0d6@iogearbox.net> <20200303125020.2baef01b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20200303125020.2baef01b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> From: Willem de Bruijn Date: Tue, 3 Mar 2020 16:10:14 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4] netdev attribute to control xdpgeneric skb linearization To: Jakub Kicinski Cc: Daniel Borkmann , Luigi Rizzo , Network Development , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , David Miller , hawk@kernel.org, "Jubran, Samih" , linux-kernel , Alexei Starovoitov , bpf Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 3, 2020 at 3:50 PM Jakub Kicinski wrote: > > On Tue, 3 Mar 2020 20:46:55 +0100 Daniel Borkmann wrote: > > Thus, when the data/data_end test fails in generic XDP, the user can > > call e.g. bpf_xdp_pull_data(xdp, 64) to make sure we pull in as much as > > is needed w/o full linearization and once done the data/data_end can be > > repeated to proceed. Native XDP will leave xdp->rxq->skb as NULL, but > > later we could perhaps reuse the same bpf_xdp_pull_data() helper for > > native with skb-less backing. Thoughts? Something akin to pskb_may_pull sounds like a great solution to me. Another approach would be a new xdp_action XDP_NEED_LINEARIZED that causes the program to be restarted after linearization. But that is both more expensive and less elegant. Instead of a sysctl or device option, is this an optimization that could be taken based on the program? Specifically, would XDP_FLAGS be a path to pass a SUPPORT_SG flag along with the program? I'm not entirely familiar with the XDP setup code, so this may be a totally off. But from a quick read it seems like generic_xdp_install could transfer such a flag to struct net_device. > I'm curious why we consider a xdpgeneric-only addition. Is attaching > a cls_bpf program noticeably slower than xdpgeneric? This just should not be xdp*generic* only, but allow us to use any XDP with large MTU sizes and without having to disable GRO. I'd still like a way to be able to drop or modify packets before GRO, or to signal that a type of packet should skip GRO.