From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by mail.toke.dk (Postfix) with ESMTPS id 77D3CA1929B for ; Wed, 12 Jul 2023 22:53:12 +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=5wm0H1/T Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-57704a25be9so18833177b3.1 for ; Wed, 12 Jul 2023 13:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689195190; x=1691787190; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=p9QPsCD/Sct5C3jY+g/VQEaVoM3H/JWnzXtkru8S9wA=; b=5wm0H1/TT8NM8HFmoANfbtFmPlmgiCOZMW7Zcj/bIpqeAKM0V4u9Vv2Xl91RzQY+Xp ZM0+SzECWdFuGZOXUQrzSbGYvtM5yJ60Nq5aXPZG5//K6b2EN+AF/H5iLcrbVmvYlmqn LXw7orLcivUBCmqH2ELAx5WLTw5Y1OIXcUZdaQ0g2n6iI4cXT7GH7Dwt3hWN0BZ0mZ+R G+8NySZPvuCK+2vwUQUJItaJIDPlbBQd7a1yypv0F2J5qnQOeG4z4YBsEdmuFi9NspCO RG2d9oA9zi8/Jjon/mPBrgHRdycPmMwqyTmgiM2sFSoRWgJx1yOmcLzqgEdq9PSRiyEU QRew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689195190; x=1691787190; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=p9QPsCD/Sct5C3jY+g/VQEaVoM3H/JWnzXtkru8S9wA=; b=lqxk12lvolQR5zsZmERT2NZLqBByQt/LGwsH7VXQ7AShpy3XD7nRGdTEr8AgBiUx85 RdcrdFI20coFaEMV3EBSrzJNB2+S2zO2uDNbZM7Gli1+y9Dr/4937K8E4iZDoqjiHMD2 vXgGiJc8D4lNnJDtwdL84jM2elsK4160r0EOeD4ZSYpg9DE9Y6fQuZO9opMynTmwimAi dgZGkhtyw1mHEpKCGDMF67xsbl/Moco+1enRfpLWeT/DuZOo1RbXgxf3eRiLBpZU3Vzv MFz1oUSEWCZe0o6RFZALAw39qHhHLXJXzMXoRmsjEvLS3beyLxD1WR4L8jDnCZMnrGeh izuQ== X-Gm-Message-State: ABy/qLbKnAaKfFsddhVkqSkTqmU7rtL5gDMoMKKfgSgsyHoR0t/M1bQr pl/MSrrRwGX2SP7HkqKyBso7sZA= X-Google-Smtp-Source: APBJJlGQhaseuP/DPTMeml4TZQGe8eKZparx5CG699nxDyYD1BJ5584Q8bIHIoYCOo7NUjbN7mlFNBM= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a81:af18:0:b0:576:e268:903d with SMTP id n24-20020a81af18000000b00576e268903dmr39126ywh.2.1689195190559; Wed, 12 Jul 2023 13:53:10 -0700 (PDT) Date: Wed, 12 Jul 2023 13:53:09 -0700 In-Reply-To: <20230712130954.7c8dc5ef@kernel.org> Mime-Version: 1.0 References: <20230712190342.dlgwh6uka5bcjfkl@macbook-pro-8.dhcp.thefacebook.com> <20230712130954.7c8dc5ef@kernel.org> Message-ID: From: Stanislav Fomichev To: Jakub Kicinski Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: SEQAAJ7YZQSHJZS2P7TGTPVGZWJUBABA X-Message-ID-Hash: SEQAAJ7YZQSHJZS2P7TGTPVGZWJUBABA X-MailFrom: 3thKvZAMKCcM1mopxxpun.lxv6my-qrw216my-y0xsnl2.wn2@flex--sdf.bounces.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: Alexei Starovoitov , Willem de Bruijn , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , Willem de Bruijn , David Ahern , magnus.karlsson@intel.com, =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , maciej.fijalkowski@intel.com, 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 07/12, Jakub Kicinski wrote: > On Wed, 12 Jul 2023 12:42:35 -0700 Alexei Starovoitov wrote: > > > Basically, add to AF_XDP what we already have for its predecessor > > > AF_PACKET: setsockopt PACKET_VNET_HDR? > > > > > > Possibly with a separate new struct, rather than virtio_net_hdr. As > > > that has dependencies on other drivers, notably virtio and its > > > specification process. =20 > >=20 > > yeah. Forgot about this one. > > That's a perfect fit. I would reuse virtio_net_hdr as-is. > > Why reinvent the wheel? > > It would force uapi, but some might argue it's a good thing. >=20 > I was gonna reply on the other leg of the thread but it sounds like > we're in agreement now? =F0=9F=91=8F=EF=B8=8F virtio_net_hdr is the kind= of generic > descriptor I had in mind. >=20 > I'd suggest breaking hdr_len into L2len, L3len and L4len, tho. How does > virtio do IP length updates during TSO if it doesn't know where L3 > starts? HW will want to know, and it's easy to add them together in > cases where it doesn't. Which is why I kept saying "packet geometry" > rather than pointing at virtio_net_hdr. Perfect, I'll drop the kfuncs and will switch to a more static way of passing this info. We can discuss the particular layout once I have something concrete to show :-) Thanks, again, everyone for the comments!