From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mail.toke.dk (Postfix) with ESMTPS id 8BEDB985E1B for ; Wed, 6 Jul 2022 15:51:12 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=c2sBfKxq DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657115473; x=1688651473; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2mYCckx+Sv5EPZOxpPFYyrg57MRKQ3Jw5hfg89nuyck=; b=c2sBfKxqRIcLx9JQ21UwovYca69wpSnBobauNuU6b2js3d8X/cyAn6cn 5XedcZ451Bme0g0f/LhULlzYaXQcBoZ1IGgo0HZBLqDeDtfte5VpUQYU4 dFHwfZRKz/maCfHKueA/Kt1FnC7BFbKVUc1k5VoTE7GbD3lXQxx6q7LwH o3ANncL3zDp1BP98+/clPQo+2AQGsqgj8/MErNhX+189g4SMi9V90pFuB HIcbtnEt4nHS2Sn0fZTyjaIPB3rCCWfShy2dOZuA0fFVMoY3tbds6hCdT E+sfq/iYQlBE1Y+y1+pWnsP84p4JfwG907JkI8GMpCtJ8A+uips/2+6nH w==; X-IronPort-AV: E=McAfee;i="6400,9594,10399"; a="370067907" X-IronPort-AV: E=Sophos;i="5.92,250,1650956400"; d="scan'208";a="370067907" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2022 06:50:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,250,1650956400"; d="scan'208";a="735572237" Received: from irvmail001.ir.intel.com ([10.43.11.63]) by fmsmga001.fm.intel.com with ESMTP; 06 Jul 2022 06:50:41 -0700 Received: from newjersey.igk.intel.com (newjersey.igk.intel.com [10.102.20.203]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 266DodPT015358; Wed, 6 Jul 2022 14:50:39 +0100 From: Alexander Lobakin To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Date: Wed, 6 Jul 2022 15:50:23 +0200 Message-Id: <20220706135023.1464979-1-alexandr.lobakin@intel.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <87pmij75r1.fsf@toke.dk> References: <20220628194812.1453059-1-alexandr.lobakin@intel.com> <62bbedf07f44a_2181420830@john.notmuch> <87iloja8ly.fsf@toke.dk> <20220704154440.7567-1-alexandr.lobakin@intel.com> <87a69o94wz.fsf@toke.dk> <20220705154120.22497-1-alexandr.lobakin@intel.com> <87pmij75r1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-ID-Hash: ONGGZAUQ4M376P2KN7XNXOU2DIO2G4JE X-Message-ID-Hash: ONGGZAUQ4M376P2KN7XNXOU2DIO2G4JE X-MailFrom: alexandr.lobakin@intel.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: Alexander Lobakin , John Fastabend , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Larysa Zaremba , Michal Swiatkowski , Jesper Dangaard Brouer , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , Lorenzo Bianconi , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jesse Brandeburg , Yajun Deng , Willem de Bruijn , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFC bpf-next 00/52] bpf, xdp: introduce and use Generic Hints/metadata List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Toke H��iland-J��rgensen Date: Tue, 05 Jul 2022 20:51:14 +0200 > Alexander Lobakin writes: > > [... snipping a bit of context here ...] > > >> >> Yeah, I'd agree this kind of configuration is something that can be > >> >> added later, and also it's sort of orthogonal to the consumption of the > >> >> metadata itself. > >> >> > >> >> Also, tying this configuration into the loading of an XDP program is a > >> >> terrible interface: these are hardware configuration options, let's just > >> >> put them into ethtool or 'ip link' like any other piece of device > >> >> configuration. > >> > > >> > I don't believe it fits there, especially Ethtool. Ethtool is for > >> > hardware configuration, XDP/AF_XDP is 95% software stuff (apart from > >> > offload bits which is purely NFP's for now). > >> > >> But XDP-hints is about consuming hardware features. When you're > >> configuring which metadata items you want, you're saying "please provide > >> me with these (hardware) features". So ethtool is an excellent place to > >> do that :) > > > > With Ethtool you configure the hardware, e.g. it won't strip VLAN > > tags if you disable rx-cvlan-stripping. With configuring metadata > > you only tell what you want to see there, don't you? > > Ah, I think we may be getting closer to identifying the disconnect > between our way of thinking about this! > > In my mind, there's no separate "configuration of the metadata" step. > You simply tell the hardware what features you want (say, "enable > timestamps and VLAN offload"), and the driver will then provide the > information related to these features in the metadata area > unconditionally. All XDP hints is about, then, is a way for the driver > to inform the rest of the system how that information is actually laid > out in the metadata area. > > Having a separate configuration knob to tell the driver "please lay out > these particular bits of metadata this way" seems like a totally > unnecessary (and quite complicated) feature to have when we can just let > the driver decide and use CO-RE to consume it? Magnus (he's currently on vacation) told me it would be useful for AF_XDP to enable/disable particular metadata, at least from perf perspective. Let's say, just fetching of one "checksum ok" bit in the driver is faster than walking through all the descriptor words and driver logics (i.e. there's several hundred locs in ice which just parse descriptor data and build an skb or metadata from it). But if we would just enable/disable corresponding features through Ethtool, that would hurt XDP_PASS. Maybe it's a bad example, but what if I want to have only RSS hash in the metadata (and don't want to spend cycles on parsing the rest), but at the same time still want skb path to have checksum status to not die at CPU checksum calculation? > > >> > I follow that way: > >> > > >> > 1) you pick a program you want to attach; > >> > 2) usually they are written for special needs and usecases; > >> > 3) so most likely that program will be tied with metadata/driver/etc > >> > in some way; > >> > 4) so you want to enable Hints of a particular format primarily for > >> > this program and usecase, same with threshold and everything > >> > else. > >> > > >> > Pls explain how you see it, I might be wrong for sure. > >> > >> As above: XDP hints is about giving XDP programs (and AF_XDP consumers) > >> access to metadata that is not currently available. Tying the lifetime > >> of that hardware configuration (i.e., which information to provide) to > >> the lifetime of an XDP program is not a good interface: for one thing, > >> how will it handle multiple programs? What about when XDP is not used at > > > > Multiple progs is stuff I didn't cover, but will do later (as you > > all say to me, "let's start with something simple" :)). Aaaand > > multiple XDP progs (I'm not talking about attaching progs in > > differeng modes) is not a kernel feature, rather a libpf feature, > > so I believe it should be handled there later... > > Right, but even if we don't *implement* it straight away we still need > to take it into consideration in the design. And expecting libxdp to > arbitrate between different XDP programs' metadata formats sounds like a > royal PITA :) > > >> all but you still want to configure the same features? > > > > What's the point of configuring metadata when there are no progs > > attached? To configure it once and not on every prog attach? I'm > > not saying I don't like it, just want to clarify. > > See above: you turn on the features because you want the stack to > consume them. > > > Maybe I need opinions from some more people, just to have an > > overview of how most of folks see it and would like to configure > > it. 'Cause I heard from at least one of the consumers that > > libpf API is a perfect place for Hints to him :) > > Well, as a program author who wants to consume hints, you'd use > lib{bpf,xdp} APIs to do so (probably in the form of suitable CO-RE > macros)... > > >> In addition, in every other case where we do dynamic data access (with > >> CO-RE) the BPF program is a consumer that modifies itself to access the > >> data provided by the kernel. I get that this is harder to achieve for > >> AF_XDP, but then let's solve that instead of making a totally > >> inconsistent interface for XDP. > > > > I also see CO-RE more fitting and convenient way to use them, but > > didn't manage to solve two things: > > > > 1) AF_XDP programs, so what to do with them? Prepare patches for > > LLVM to make it able to do CO-RE on AF_XDP program load? Or > > just hardcode them for particular usecases and NICs? What about > > "general-purpose" programs? > > You provide a library to read the fields. Jesper actually already > implemented this, did you look at his code? > > https://github.com/xdp-project/bpf-examples/tree/master/AF_XDP-interaction > > It basically builds a lookup table at load-time using BTF information > from the kernel, keyed on BTF ID and field name, resolving them into > offsets. It's not quite the zero-overhead of CO-RE, but it's fairly > close and can be improved upon (CO-RE for userspace being one way of > doing that). Aaaah, sorry, I completely missed that. I thought of something similar as well, but then thought "variable field offsets, that would annihilate optimization and performance", and our Xsk team is super concerned about performance hits when using Hints. > > > And if hardcode, what's the point then to do Generic Hints at > > all? Then all it needs is making driver building some meta in > > front of frames via on-off button and that's it? Why BTF ID in > > the meta then if consumers will access meta hardcoded (via CO-RE > > or literally hardcoded, doesn't matter)? > > You're quite right, we could probably implement all the access to > existing (fixed) metadata without using any BTF at all - just define a > common struct and some flags to designate which fields are set. In my > mind, there are a couple of reasons for going the BTF route instead: > > - We can leverage CO-RE to get close to optimal efficiency in field > access. > > and, more importantly: > > - It's infinitely extensible. With the infrastructure in place to make > it really easy to consume metadata described by BTF, we lower the bar > for future innovation in hardware offloads. Both for just adding new > fixed-function stuff to hardware, but especially for fully > programmable hardware. Agree :) That libxdp lookup translator fixed lots of stuff in my mind. > > > 2) In-kernel metadata consumers? Also do CO-RE? Otherwise, with no > > generic metadata structure they won't be able to benefit from > > Hints. But I guess we still need to provide kernel with meta? > > Or no? > > In the short term, I think the "generic structure" approach is fine for > leveraging this in the stack. Both your and Jesper's series include > this, and I think that's totally fine. Longer term, if it turns out to > be useful to have something more dynamic for the stack consumption as > well, we could extend it to be CO-RE based as well (most likely by > having the stack load a "translator" BPF program or something along > those lines). Oh, that translator prog sounds nice BTW! > > >> I'm as excited as you about the prospect of having totally programmable > > > > But I mostly care about current generation with no programmable > > Hints... > > Well, see above; we should be able to support both :) > > -Toke Thanks, Olek