From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 2A016A06F7F for ; Mon, 15 May 2023 17:36:19 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bJfqr3wK DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684164977; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x7CbMDqqB7Ef24aQqJke8PthcM5mzwIBmyE952+ZY6Q=; b=bJfqr3wKdIAjXE0cjyuiarPGOHWOSw/Qmz7xvxm52KoPar4IPlVUtlH0P8SLoAYuoE0/xz fC7QLvOQUv+X8edOWmg2zpGtM9V4ysfcGD/Y0Tni2MpbQT+I4w04PJSwPM0EF3SrmzauaJ 7KBkTlmeIeM2sMcO+kQ/iJttvWpggyo= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-507-Ap5GPAKgOMemJpOOS1N5NQ-1; Mon, 15 May 2023 11:36:16 -0400 X-MC-Unique: Ap5GPAKgOMemJpOOS1N5NQ-1 Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-50daa85e940so10185477a12.0 for ; Mon, 15 May 2023 08:36:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684164975; x=1686756975; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x7CbMDqqB7Ef24aQqJke8PthcM5mzwIBmyE952+ZY6Q=; b=E+V1n5O+1Im02mIqFdHk7gNCKkPQc7c6XaIEp4jQ3oyQCnd3C1PrHgBUmqlWR+sTju pptO7LCDOPg+6gOaQ3A8qnirh39uyAT84xit9e0SchKGKKR+OLs7bx2nkY9y6w4IVCPm 5eertSXTuKDljtyrHyCXTVJ2rJt+8g8PS8YQayalNJ8hagf8yWJh1wJ/SfXo9qiD/bSx hojckvzNCsRamlwkGE/h8CFrVwb+W56ZvsCaBii9B4S9uTKa5vcdqSWCwRfYLpfF1xe/ nvj3psUTaV7voAOAHAz76vUMHDb3+qZliiM1ft3p0CvdlJi6fGM24Xrvc+XzYoG4+GwN vj7g== X-Gm-Message-State: AC+VfDy1PGhPvPZaXnBDYyFgop08/0Z8MuTLzhW7+NA6MYkDpdcW/ZBO GOtKsg6VTYndBpVfDnbVMwzbCDGJADg2oBFkZjN5YNZmLR6WgOMtVsDhvtaI2y47F404U5Y2LTI fN/9cUG+S3+j+QDR7gu6E X-Received: by 2002:a17:907:804:b0:94f:adb2:171f with SMTP id wv4-20020a170907080400b0094fadb2171fmr27955068ejb.28.1684164975537; Mon, 15 May 2023 08:36:15 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ46GxPVBqoq2psgT5XG+XapuVBE6/4vYM0++VGwPutqBc+4LJ5jMPnxCh49EGXYSOjGcFb1gg== X-Received: by 2002:a17:907:804:b0:94f:adb2:171f with SMTP id wv4-20020a170907080400b0094fadb2171fmr27955042ejb.28.1684164975130; Mon, 15 May 2023 08:36:15 -0700 (PDT) Received: from [192.168.41.200] (83-90-141-187-cable.dk.customer.tdc.net. [83.90.141.187]) by smtp.gmail.com with ESMTPSA id k18-20020a17090632d200b009661f07db93sm9660631ejk.223.2023.05.15.08.36.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 08:36:14 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: Date: Mon, 15 May 2023 17:36:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Larysa Zaremba , bpf@vger.kernel.org References: <20230512152607.992209-1-larysa.zaremba@intel.com> <20230512152607.992209-10-larysa.zaremba@intel.com> In-Reply-To: <20230512152607.992209-10-larysa.zaremba@intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: GW6CNKXV6YUYQ5YEK3QUNZVGOY5DT4PN X-Message-ID-Hash: GW6CNKXV6YUYQ5YEK3QUNZVGOY5DT4PN X-MailFrom: jbrouer@redhat.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: brouer@redhat.com, Stanislav Fomichev , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Jakub Kicinski , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Jiri Olsa , Jesse Brandeburg , Tony Nguyen , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH RESEND bpf-next 09/15] xdp: Add VLAN tag hint List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 12/05/2023 17.26, Larysa Zaremba wrote: > Implement functionality that enables drivers to expose VLAN tag > to XDP code. > > Signed-off-by: Larysa Zaremba > --- [...] > diff --git a/net/core/xdp.c b/net/core/xdp.c > index 41e5ca8643ec..eff21501609f 100644 > --- a/net/core/xdp.c > +++ b/net/core/xdp.c > @@ -738,6 +738,30 @@ __bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32 *hash, > return -EOPNOTSUPP; > } > Remember below becomes part of main documentation on HW metadata hints: - https://kernel.org/doc/html/latest/networking/xdp-rx-metadata.html Hint compiling locally I use: make SPHINXDIRS="networking" htmldocs > +/** > + * bpf_xdp_metadata_rx_ctag - Read XDP packet inner vlan tag. Is bpf_xdp_metadata_rx_ctag a good function name for the inner vlan tag? Like wise below "stag". I cannot remember if the C-tag or S-tag is the inner or outer vlan tag. When reading BPF code that use these function names, then I would have to ask Google for help, or find-and-read this doc. Can we come-up with a more intuitive name, that e.g. helps when reading the BPF-prog code? > + * @ctx: XDP context pointer. > + * @vlan_tag: Return value pointer. > + * IMHO right here, there should be a description. E.g. for what a VLAN "tag" means. I assume a "tag" isn't the VLAN id, but the raw VLAN tag that also contains the prio numbers etc. It this VLAN tag expected to be in network-byte-order ? IMHO this doc should define what is expected (and driver devel must follow this). > + * Returns 0 on success or ``-errno`` on error. > + */ > +__bpf_kfunc int bpf_xdp_metadata_rx_ctag(const struct xdp_md *ctx, u16 *vlan_tag) > +{ > + return -EOPNOTSUPP; > +} > + > +/** > + * bpf_xdp_metadata_rx_stag - Read XDP packet outer vlan tag. > + * @ctx: XDP context pointer. > + * @vlan_tag: Return value pointer. > + * > + * Returns 0 on success or ``-errno`` on error. IMHO we should provide more guidance to expected return codes, and what they mean. IMHO driver developers must only return codes that are described here, and if they invent a new, add it as part of their patch. See, formatting in bpf_xdp_metadata_rx_hash and check how this gets compiled into HTML. > + */ > +__bpf_kfunc int bpf_xdp_metadata_rx_stag(const struct xdp_md *ctx, u16 *vlan_tag) > +{ > + return -EOPNOTSUPP; > +} > +