From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mail.toke.dk (Postfix) with ESMTPS id A84F385A02F for ; Tue, 22 Jun 2021 13:37:28 +0200 (CEST) IronPort-SDR: Me8mlBl2FQlmhyGJ/HFX/NBZq9JbaPFdgdYo/0DP3OWY86vE0qFCV5Uwth0oRKZfuCHmvEQa2A dF2TSEM70OIw== X-IronPort-AV: E=McAfee;i="6200,9189,10022"; a="204027252" X-IronPort-AV: E=Sophos;i="5.83,291,1616482800"; d="scan'208";a="204027252" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2021 04:37:19 -0700 IronPort-SDR: WUwTv2aLeG/2pNEUPV7sZsP+vVv/S2Ypr4smWyUa+lRq7RLn0Oc2jVDc/ene0gpEJ1HuropDer Uqiwhe0UU4+A== X-IronPort-AV: E=Sophos;i="5.83,291,1616482800"; d="scan'208";a="486877573" Received: from unknown (HELO localhost.localdomain) ([10.102.102.63]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2021 04:37:14 -0700 Date: Tue, 22 Jun 2021 03:44:32 -0400 From: Michal Swiatkowski To: Jakub Kicinski Subject: Re: XDP-hints: Howto support multiple BTF types per packet basis? Message-ID: References: <60aeeb5252147_19a622085a@john-XPS-13-9370.notmuch> <60b08442b18d5_1cf8208a0@john-XPS-13-9370.notmuch> <87fsy7gqv7.fsf@toke.dk> <60b0ffb63a21a_1cf82089e@john-XPS-13-9370.notmuch> <20210528180214.3b427837@carbon> <60b12897d2e3f_1cf820896@john-XPS-13-9370.notmuch> <8735u3dv2l.fsf@toke.dk> <60b6cf5b6505e_38d6d208d8@john-XPS-13-9370.notmuch> <20210602091837.65ec197a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210602091837.65ec197a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> Message-ID-Hash: ADW7NUKT6OYVDXRDREONO73PCSVQJ2IO X-Message-ID-Hash: ADW7NUKT6OYVDXRDREONO73PCSVQJ2IO X-MailFrom: michal.swiatkowski@linux.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: John Fastabend , Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , Jesper Dangaard Brouer , Andrii Nakryiko , BPF-dev-list , Magnus Karlsson , William Tu , xdp-hints@xdp-project.net X-Mailman-Version: 3.3.4 Precedence: list List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Jun 02, 2021 at 09:18:37AM -0700, Jakub Kicinski wrote: > On Tue, 01 Jun 2021 17:22:51 -0700 John Fastabend wrote: > > > If we do this, the BPF program obviously needs to know which fields are > > > valid and which are not. AFAICT you're proposing that this should be > > > done out-of-band (i.e., by the system administrator manually ensuring > > > BPF program config fits system config)? I think there are a couple of > > > problems with this: > > > > > > - It requires the system admin to coordinate device config with all of > > > their installed XDP applications. This is error-prone, especially as > > > the number of applications grows (say if different containers have > > > different XDP programs installed on their virtual devices). > > > > A complete "system" will need to be choerent. If I forward into a veth > > device the orchestration component needs to ensure program sending > > bits there is using the same format the program installed there expects. > > > > If I tailcall/fentry into another program that program the callee and > > caller need to agree on the metadata protocol. > > > > I don't see any way around this. Someone has to manage the network. > > FWIW I'd like to +1 Toke's concerns. > > In large deployments there won't be a single arbiter. Saying there > is seems to contradict BPF maintainers' previous stand which lead > to addition of bpf_links for XDP. > > In practical terms person rolling out an NTP config change may not > be aware that in some part of the network some BPF program expects > descriptor not to contain time stamps. Besides features may depend > or conflict so the effects of feature changes may not be obvious > across multiple drivers in a heterogeneous environment. > > IMO guarding from obvious mis-configuration provides obvious value. Hi, Thanks for a lot of usefull information about CO-RE. I have read recommended articles, but still don't understand everything, so sorry if my questions are silly. As introduction, I wrote small XDP example using CO-RE (autogenerated vmlinux.h and getting rid of skeleton etc.) based on runqslower implementation. Offset reallocation of hints works great, I built CO-RE application, added new field to hints struct, changed struct layout and without rebuilding application everything still works fine. Is it worth to add XDP sample using CO-RE in kernel or this isn't good place for this kind of sample? First question not stricte related to hints. How to get rid of #define and macro when I am using generated vmlinux.h? For example I wanted to use htons macro and ethtype definition. They are located in headers that also contains few struct definition. Because of that I have redefinition error when I am trying to include them (redefinition in vmlinux.h and this included file). What can I do with this besides coping definitions to bpf code? I defined hints struct in driver code, is it right place for that? All vendors will define their own hints struct or the idea is to have one big hints struct with flags informing about availability of each fields? For me defining it in driver code was easier because I can have used module btf to generate vmlinux.h with hints struct inside. However this break portability if other vendors will have different struct name etc, am I right?