From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AC1CDDCF for ; Wed, 12 Jul 2023 20:53:13 +0000 (UTC) Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C181199D for ; Wed, 12 Jul 2023 13:53:11 -0700 (PDT) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-57704a25be9so18833167b3.1 for ; Wed, 12 Jul 2023 13:53:11 -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=WRgLyqrbA4CYRYFMdd1xfUwwIlxX/61SHvuPLDhoPhzYCP2F2uUHQcl4WC8PamG1kA j7DSjtG6S5gztGL9e47+C0sGC8GyHRtQTQhKLpRotgpY9k+ui0wKMAtafbeAF97j3d4D y0k513QBiUETIYJwrg16+jUB66AJ92FEmxNJxjnXrr5vkj8JPo89r0XbWwhxLUMXjeWl h+3py3UOY7CCd90RVq8q4ZLggis2rubuIkWR1WXEQNOJUhzttvxMLPZV4G85tkEX5dzu q973Dol1cXhcKXZ/SjFgIJIDpfm/Pwkzeuj5Rt3ec30bGIUmVoymViookdhiTBAFVrnK XGkQ== X-Gm-Message-State: ABy/qLZpV7ZXGF3iPRobI4WIz5X4nfeX8chlmemIwZkSDI24IUYBDCB3 6QtDYFcVn9AYgwMKZWZRF3ucLrg= 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> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230712190342.dlgwh6uka5bcjfkl@macbook-pro-8.dhcp.thefacebook.com> <20230712130954.7c8dc5ef@kernel.org> Message-ID: Subject: Re: [RFC bpf-next v3 09/14] net/mlx5e: Implement devtx kfuncs From: Stanislav Fomichev To: Jakub Kicinski 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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!