From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by mail.toke.dk (Postfix) with ESMTPS id 8714EA18E9E for ; Wed, 12 Jul 2023 05:07:43 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=alvo3LKZ Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6A3B1616AE; Wed, 12 Jul 2023 03:07:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E4C6C433C8; Wed, 12 Jul 2023 03:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689131261; bh=uOoIoKaMaiPjbxEKLwffsfSd7isUyv91luMjnMlx8iI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=alvo3LKZuPmcu5955E9J9ZB+IPN6beiUyQ2ECUv0JGwmn+MPM8kRwx5Sg5P1tOENb UZCnueAWtbS0qnwmUqP+cnCS9UYuVK4KYRs2maGz47TdpKQr1/l92g86hGUbeNXfdW BvhNrSgaCvYzSmNEIggaJoa5KLbzDLEAYdffC9VA7HH9S3fnHDPkYB5NoZW1WPjPKy Yg7Mj+NQg/zv61cHjaBVUk7EuReKdP1DmN7BHBOMoedN7vLXeJ9ri5+bX2yOEoAi9O vVqVkc7Cqinsgf52YGE+5J8NPuodahImjXBfaZhQhXbFi3JLbG1MMKu6ZhwleZt7IS CA+ieJG9u3Iig== Date: Tue, 11 Jul 2023 20:07:40 -0700 From: Jakub Kicinski To: Alexei Starovoitov Message-ID: <20230711200740.236b0142@kernel.org> In-Reply-To: References: <20230707193006.1309662-1-sdf@google.com> <20230707193006.1309662-10-sdf@google.com> <20230711225657.kuvkil776fajonl5@MacBook-Pro-8.local> <20230711173226.7e9cca4a@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: Q3T3EVODP4X23OGSCXVVCVNVEP4SQWYA X-Message-ID-Hash: Q3T3EVODP4X23OGSCXVVCVNVEP4SQWYA X-MailFrom: kuba@kernel.org 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: Stanislav Fomichev , 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?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , 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, 11 Jul 2023 19:37:23 -0700 Alexei Starovoitov wrote: > > I hope I'm not misremembering but I think I suggested at the beginning > > to create a structure describing packet geometry and requested offloads, > > and for the prog fill that in. > > hmm. but that's what skb is for. skb == packet geometry == > layout of headers, payload, inner vs outer, csum partial, gso params. > > bpf at tc layer supposed to interact with that correctly. > If the packet is modified skb geometry should be adjusted accordingly. > Like BPF_F_RECOMPUTE_CSUM flag in bpf_skb_store_bytes(). > > > All operating systems I know end up doing that, we'll end up doing > > that as well. The question is whether we're willing to learn from > > experience or prefer to go on a wild ride first... > > I don't follow. This thread was aimed to add xdp layer knobs. > To me XDP is a driver level. Driver is not a layer of the networking stack, I don't think it's a useful or meaningful anchor point for the mental model. We're talking about a set of functionality, we can look at how that functionality was exposed in existing code. > 'struct xdp_md' along with > BPF_F_XDP_HAS_FRAGS is the best abstraction we could do generalizing > dma-buffers (page and multi-page) that drivers operate on. I think you're working against your own claim. xdp frags explicitly reuse struct skb_shared_info. > Everything else at driver level is too unique to generalize. > skb layer is already doing its job. How can you say that drivers are impossible to generalize and than that the skb layer "is doing its job" ie. generalizes them? > In that sense "generic XDP" is a feature for testing only. > Trying to make "generic XDP" fast is missing the point of XDP. That's a topic on its own. > AF_XDP is a different concept. Exposing timestamp, > csum, TSO to AF_XDP users is a different design challenge. > I'm all for doing that, but trying to combine "timestamp in xdp tx" > and "timestamp in AF_XDP" will lead to bad trade-off-s for both. > Which I think this patchset demonstrates. Too vague to agree or disagree with.