From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) by mail.toke.dk (Postfix) with ESMTPS id D7291A18F85 for ; Wed, 12 Jul 2023 07:36:21 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=xY+6hGjC Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-1b449890ef5so5135843fac.1 for ; Tue, 11 Jul 2023 22:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689140180; x=1691732180; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vnidGm4u+nJnZIlJckPEwTKF95jsTNlFO/U0vG4SnH4=; b=xY+6hGjCcCcyOfBX5GtuaDdGYczloCXcdZ/qw6ngGMl4SlD1U1KljeaA6WSxFe/tkw e79CyoBBrHq0Dk1imnjFjqQjdKj9pXHHRfg3laa1+9kAHuXsF15Cd6PQcVGoz4hxAXgf Wt0AIel3aOb1Y5HFFR6SvLo+CCkPlaByGlTvc+liAipflw4tsKP6s1z+fVeXjVhgiI2w dXKPQWIl1KSYhbf49b1PTvewHs/trbIwiDbI7Rskrho8Wi+WP0jMXxxWBOK6KEwWiZ6P Xlga2btiZW5Z7Y7KvwbJsRD32aMVQ6a2fkIDGjQU6Bepc1BGg/LR1ED6GiqWZDir5scx 3vbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689140180; x=1691732180; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vnidGm4u+nJnZIlJckPEwTKF95jsTNlFO/U0vG4SnH4=; b=PldGOmVCJyYvoJSLqcee34tTmQzLjyhert6r/2eFgsg4bsd0aFy3/8iLauVeHvcuuY MrHOdxf5+PKFBMy/UxWwDrQKikw7KB+O8Op7SbvwGSJfN6JQH1PDtbuq/giuQbZe9IVC 6ExfawoZH1jzHBSkng6p2v8I9nqZQff2ltlu25Vx3x9Xg/ZjQD0s1HdJhPHNOeIcGNGC 6i1q00LGLBfQVG9JJWzhIfB+DhUFjXr2xEtnZkeF7k+Lxv+WdU1u0yz3IeSQqREq9nNh XCFjA6NJKWvKoum0Nds0q7VnPCsRbzpEJ8jwrWo3Bzh7q+WATNFVGHpAnqK3fJqEnRty Hl1w== X-Gm-Message-State: ABy/qLafr22uSK3BeLBP1Dr1wiBYPZcuwunckaXEkujmRf0hhu8osbkD Tv3jitacFbPri3V2CtKhsoAyJr3TGBWN2c5f6x+LUQ== X-Google-Smtp-Source: APBJJlGAGBzXt27mT9kxQcqGuRRrF5r9n/oPwjmju5K2TDj52bB2UdXsZbXYwWDeCZUKXtCgJ5ykqMtqnT2pEHUkzIw= X-Received: by 2002:a05:6870:638d:b0:1b0:291c:9272 with SMTP id t13-20020a056870638d00b001b0291c9272mr22177928oap.28.1689140179849; Tue, 11 Jul 2023 22:36:19 -0700 (PDT) MIME-Version: 1.0 References: <20230707193006.1309662-1-sdf@google.com> <20230707193006.1309662-10-sdf@google.com> <20230711225657.kuvkil776fajonl5@MacBook-Pro-8.local> In-Reply-To: From: Stanislav Fomichev Date: Tue, 11 Jul 2023 22:36:08 -0700 Message-ID: To: Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 3FIVGRD253WQQ7D632JA3S6HQIWINVDX X-Message-ID-Hash: 3FIVGRD253WQQ7D632JA3S6HQIWINVDX X-MailFrom: sdf@google.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , Jakub Kicinski , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Willem de Bruijn , David Ahern , "Karlsson, Magnus" , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Fijalkowski, Maciej" , Jesper Dangaard Brouer , Network Development , xdp-hints@xdp-project.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v3 09/14] net/mlx5e: Implement devtx kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Jul 11, 2023 at 9:59=E2=80=AFPM Alexei Starovoitov wrote: > > On Tue, Jul 11, 2023 at 8:29=E2=80=AFPM Stanislav Fomichev wrote: > > > > > > This will slow things down, but not to the point where it's on par > > with doing sw checksum. At least in theory. > > We can't stay at skb when using AF_XDP. AF_XDP would benefit from havin= g > > the offloads. > > To clarify: yes, AF_XDP needs generalized HW offloads. Great! To reiterate, I'm mostly interested in af_xdp wrt tx timestamps. So if the consensus is not to mix xdp-tx and af_xdp-tx, I'm fine with switching to adding some fixed af_xdp descriptor format to enable offloads on tx. > I just don't see how xdp tx offloads are moving a needle in that directio= n. Let me try to explain how both might be similar, maybe I wasn't clear enough on that. For af_xdp tx packet, the userspace puts something in the af_xdp frame metadata area (headrom) which then gets executed/interpreted by the bpf program at devtx (which calls kfuncs to enable particular offloads). IOW, instead of defining some fixed layout for the tx offloads, the userspace and bpf program have some agreement on the layout (and bpf program "applies" the offloads by calling the kfuncs). Also (in theory) the same hooks can be used for xdp-tx. Does it make sense? But, again, happy to scratch that whole idea if we're fine with a fixed layout for af_xdp.