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 31503A15D16 for ; Tue, 4 Jul 2023 12:23:52 +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=E/S1NCZ3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688466231; 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=efMYYmzKcoxHmtIWpxVuDkCtLQ7YQKGr9WO/LVN59l8=; b=E/S1NCZ3mfBEj6z5GDJ0DoLV5Lz/N/8mSc+5KhYJjzvYOPr3dW/GYNW1qsR+ejTABy8Czv R28Ub+ninkrt8gjNPTw9FjNoRdLHzdtiwN+x3WxPpDUKiiazueL6bsMkXg8S6bDXSUhpZj SkRKfzFfG/s16qw4eyHHPe7wGnTd1pE= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-509-yKAro03fP0yTdiBtwAXv1Q-1; Tue, 04 Jul 2023 06:23:50 -0400 X-MC-Unique: yKAro03fP0yTdiBtwAXv1Q-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-4f956a29f2aso5091759e87.0 for ; Tue, 04 Jul 2023 03:23:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688466228; x=1691058228; 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=efMYYmzKcoxHmtIWpxVuDkCtLQ7YQKGr9WO/LVN59l8=; b=bGGRn9uQtnIYSRkhlDXBJNASwm1vH0FHUfZgCMGD60cib+wNkTp4gTRmQ++YYaNyN1 XD80MLb4BArw88spGfR+wDD6Y50IfIkB3EZ78xgEo7pdn4zQ13hqo2Zsvbl4zCimlkH+ oHIK+ukVN5VCwiGlbb2a/5QzZ95lu0lIrKL+i6rH2qgdPlF7xnWSv17nLxVT875r/HNj x+TJg3b/MtixLKDWZnbYVvWEkzcRH3vUqbW14amQEad1WhpJXstWEkcAIejmH7+aojlk 1dZ+muR+L+z1dQI7HJG5VcJGDJa3LMjU29JuOf8VJSYeoeoA45S1D3fp7nv+tuv4RanW 3JoA== X-Gm-Message-State: ABy/qLaafYpZEF8AVWt4rlvu4gRJopLeNd4MWEzlI5orn2UBIdtVwUDq qRSZ6xecuhrseDp9cVvLCFYIu3d1VMO9gqC2l6WwMxsiBmd/JZBsDtsEm7YMBUkEhL5YAqA6NRa +H78zxKZ5p2+LarHi5vy1 X-Received: by 2002:a19:6d1c:0:b0:4f8:71bf:a25b with SMTP id i28-20020a196d1c000000b004f871bfa25bmr7822369lfc.9.1688466228713; Tue, 04 Jul 2023 03:23:48 -0700 (PDT) X-Google-Smtp-Source: APBJJlEe58T5Jt5/8xyxSsobmohA9Yv/PKPg7Rs8j5M5JhfU7oZKnDuXDiRkvSFgXLDFi43xiXB5BQ== X-Received: by 2002:a19:6d1c:0:b0:4f8:71bf:a25b with SMTP id i28-20020a196d1c000000b004f871bfa25bmr7822350lfc.9.1688466228357; Tue, 04 Jul 2023 03:23:48 -0700 (PDT) Received: from [192.168.42.100] (194-45-78-10.static.kviknet.net. [194.45.78.10]) by smtp.gmail.com with ESMTPSA id 7-20020a05600c230700b003fa968e9c27sm24855898wmo.9.2023.07.04.03.23.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jul 2023 03:23:47 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: Date: Tue, 4 Jul 2023 12:23:45 +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 , John Fastabend References: <20230703181226.19380-1-larysa.zaremba@intel.com> <20230703181226.19380-10-larysa.zaremba@intel.com> <64a32c661648e_628d32085f@john.notmuch> In-Reply-To: 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: MOB2PAMO54U433UBBWTO5OWJZ2ATXQQC X-Message-ID-Hash: MOB2PAMO54U433UBBWTO5OWJZ2ATXQQC 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, bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, Andrew Lunn X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v2 09/20] 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 04/07/2023 10.23, Larysa Zaremba wrote: > On Mon, Jul 03, 2023 at 01:15:34PM -0700, John Fastabend wrote: >> Larysa Zaremba wrote: >>> Implement functionality that enables drivers to expose VLAN tag >>> to XDP code. >>> >>> Signed-off-by: Larysa Zaremba >>> --- >>> Documentation/networking/xdp-rx-metadata.rst | 8 +++++++- >>> include/linux/netdevice.h | 2 ++ >>> include/net/xdp.h | 2 ++ >>> kernel/bpf/offload.c | 2 ++ >>> net/core/xdp.c | 20 ++++++++++++++++++++ >>> 5 files changed, 33 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/networking/xdp-rx-metadata.rst b/Documentation/networking/xdp-rx-metadata.rst >>> index 25ce72af81c2..ea6dd79a21d3 100644 >>> --- a/Documentation/networking/xdp-rx-metadata.rst >>> +++ b/Documentation/networking/xdp-rx-metadata.rst >>> @@ -18,7 +18,13 @@ Currently, the following kfuncs are supported. In the future, as more >>> metadata is supported, this set will grow: >>> >>> .. kernel-doc:: net/core/xdp.c >>> - :identifiers: bpf_xdp_metadata_rx_timestamp bpf_xdp_metadata_rx_hash >>> + :identifiers: bpf_xdp_metadata_rx_timestamp >>> + >>> +.. kernel-doc:: net/core/xdp.c >>> + :identifiers: bpf_xdp_metadata_rx_hash >>> + >>> +.. kernel-doc:: net/core/xdp.c >>> + :identifiers: bpf_xdp_metadata_rx_vlan_tag >>> >>> An XDP program can use these kfuncs to read the metadata into stack >>> variables for its own consumption. Or, to pass the metadata on to other [...] >>> diff --git a/net/core/xdp.c b/net/core/xdp.c >>> index 41e5ca8643ec..f6262c90e45f 100644 >>> --- a/net/core/xdp.c >>> +++ b/net/core/xdp.c >>> @@ -738,6 +738,26 @@ __bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32 *hash, >>> return -EOPNOTSUPP; >>> } >>> >>> +/** >>> + * bpf_xdp_metadata_rx_vlan_tag - Get XDP packet outermost VLAN tag with protocol >>> + * @ctx: XDP context pointer. >>> + * @vlan_tag: Destination pointer for VLAN tag >>> + * @vlan_proto: Destination pointer for VLAN protocol identifier in network byte order. >>> + * >>> + * In case of success, vlan_tag contains VLAN tag, including 12 least significant bytes >>> + * containing VLAN ID, vlan_proto contains protocol identifier. >> >> Above is a bit confusing to me at least. >> >> The vlan tag would be both the 16bit TPID and 16bit TCI. What fields >> are to be included here? The VlanID or the full 16bit TCI meaning the >> PCP+DEI+VID? > > It contains PCP+DEI+VID, in patch 16 ("selftests/bpf: Add flags and new hints to > xdp_hw_metadata") this is more clear, because the tag is parsed. > Do we really care about the "EtherType" proto (in VLAN speak TPID = Tag Protocol IDentifier)? I mean, it can basically only have two values[1], and we just wanted to know if it is a VLAN (that hardware offloaded/removed for us): static __always_inline int proto_is_vlan(__u16 h_proto) { return !!(h_proto == bpf_htons(ETH_P_8021Q) || h_proto == bpf_htons(ETH_P_8021AD)); } [1] https://github.com/xdp-project/bpf-examples/blob/master/include/xdp/parsing_helpers.h#L75-L79 Cc. Andrew Lunn, as I notice DSA have a fake VLAN define ETH_P_DSA_8021Q (in file include/uapi/linux/if_ether.h) Is this actually in use? Maybe some hardware can "VLAN" offload this? > What about rephrasing it this way: > > In case of success, vlan_proto contains VLAN protocol identifier (TPID), > vlan_tag contains the remaining 16 bits of a 802.1Q tag (PCP+DEI+VID). > Hmm, I think we can improve this further. This text becomes part of the documentation for end-users (target audience). Thus, I think it is worth being more verbose and even mention the existing defines that we are expecting end-users to take advantage of. What about: In case of success. The VLAN EtherType is stored in vlan_proto (usually either ETH_P_8021Q or ETH_P_8021AD) also known as TPID (Tag Protocol IDentifier). The VLAN tag is stored in vlan_tag, which is a 16-bit field containing sub-fields (PCP+DEI+VID). The VLAN ID (VID) is 12-bits commonly extracted using mask VLAN_VID_MASK (0x0fff). For the meaning of the sub-fields Priority Code Point (PCP) and Drop Eligible Indicator (DEI) (formerly CFI) please reference other documentation. Remember these 16-bit fields are stored in network-byte. Thus, transformation with byte-order helper functions like bpf_ntohs() are needed. >> I think by "including 12 least significant bytes" you >> mean bits, > > Yes, my bad. > >> but also not clear about those 4 other bits. >> >> I can likely figure it out in next patches from implementation but >> would be nice to clean up docs. >> >>> + * >>> + * Return: >>> + * * Returns 0 on success or ``-errno`` on error. >>> + * * ``-EOPNOTSUPP`` : device driver doesn't implement kfunc >>> + * * ``-ENODATA`` : VLAN tag was not stripped or is not available >>> + */ >>> +__bpf_kfunc int bpf_xdp_metadata_rx_vlan_tag(const struct xdp_md *ctx, u16 *vlan_tag, >>> + __be16 *vlan_proto) >>> +{ >>> + return -EOPNOTSUPP; >>> +} >>> +