From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Larysa Zaremba <larysa.zaremba@intel.com>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org,
sdf@google.com, haoluo@google.com, jolsa@kernel.org,
David Ahern <dsahern@gmail.com>,
Willem de Bruijn <willemb@google.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Alexander Lobakin <alexandr.lobakin@intel.com>,
Magnus Karlsson <magnus.karlsson@gmail.com>,
Maryam Tahhan <mtahhan@redhat.com>,
xdp-hints@xdp-project.net, netdev@vger.kernel.org,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Simon Horman <simon.horman@corigine.com>,
Tariq Toukan <tariqt@mellanox.com>,
Saeed Mahameed <saeedm@mellanox.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Subject: [xdp-hints] Re: [RFC bpf-next v2 09/24] xdp: Add VLAN tag hint
Date: Thu, 5 Oct 2023 10:16:04 -0700 [thread overview]
Message-ID: <20231005101604.33b382d8@kernel.org> (raw)
In-Reply-To: <e4bbe997-326f-b6cf-b6d6-f0a24f5aef39@intel.com>
On Thu, 5 Oct 2023 18:58:33 +0200 Alexander Lobakin wrote:
> > No unsharing - you can still strip it in the driver.
>
> Nobody manually strips VLAN tags in the drivers. You either have HW
> stripping or pass VLAN-tagged skb to the stack, so that skb_vlan_untag()
> takes care of it.
Isn't it just a case of circular logic tho?
We don't optimize the stack for SW stripping because HW does it.
Then HW does it because SW is not optimized.
> > Do you really think that for XDP kfunc call will be cheaper?
>
> Wait, you initially asked:
>
> * discussion about the validity of VLAN stripping as an offload?
> * Do people actually care about having it enabled?
>
> I did read this as "do we still need HW VLAN stripping in general?", not
> only for XDP. So I replied for "in general" -- yes.
> Forcefully disabling stripping when XDP is active is obscure IMO, let
> the user decide.
Every time I'm involved in conversations about NIC datapath host
interfaces I cringe at this stupid VLAN offload. Maybe I'm too
daft to understand it's amazing value but we just shift 2B from
the packet to the descriptor and then we have to worry about all
the corner cases that come from vlan stacking :(
next prev parent reply other threads:[~2023-10-05 17:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 7:51 [xdp-hints] [RFC bpf-next v2 00/24] XDP metadata via kfuncs for ice + mlx5 Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 01/24] ice: make RX hash reading code more reusable Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 02/24] ice: make RX HW timestamp " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 03/24] ice: make RX checksum checking " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 04/24] ice: Make ptype internal to descriptor info processing Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 05/24] ice: Introduce ice_xdp_buff Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 06/24] ice: Support HW timestamp hint Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 07/24] ice: Support RX hash XDP hint Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 08/24] ice: Support XDP hints in AF_XDP ZC mode Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 09/24] xdp: Add VLAN tag hint Larysa Zaremba
2023-10-03 12:35 ` [xdp-hints] " Jakub Kicinski
2023-10-03 13:09 ` Alexander Lobakin
2023-10-04 18:08 ` Jakub Kicinski
2023-10-05 16:58 ` Alexander Lobakin
2023-10-05 17:16 ` Jakub Kicinski [this message]
2023-10-05 17:20 ` David Ahern
2023-10-05 18:06 ` Jakub Kicinski
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 10/24] ice: Implement " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 11/24] ice: use VLAN proto from ring packet context in skb path Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 12/24] xdp: Add checksum hint Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 13/24] ice: Implement " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 14/24] ice: put XDP meta sources assignment under a static key condition Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 15/24] selftests/bpf: Allow VLAN packets in xdp_hw_metadata Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 16/24] net, xdp: allow metadata > 32 Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 17/24] selftests/bpf: Add flags and new hints to xdp_hw_metadata Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 18/24] veth: Implement VLAN tag and checksum XDP hint Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 19/24] net: make vlan_get_tag() return -ENODATA instead of -EINVAL Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 20/24] selftests/bpf: Use AF_INET for TX in xdp_metadata Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 21/24] selftests/bpf: Check VLAN tag and proto " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 22/24] selftests/bpf: check checksum state " Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 23/24] mlx5: implement VLAN tag XDP hint Larysa Zaremba
2023-09-27 7:51 ` [xdp-hints] [RFC bpf-next v2 24/24] mlx5: implement RX checksum " Larysa Zaremba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.xdp-project.net/postorius/lists/xdp-hints.xdp-project.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231005101604.33b382d8@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=alexandr.lobakin@intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=anatoly.burakov@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=larysa.zaremba@intel.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@gmail.com \
--cc=martin.lau@linux.dev \
--cc=mtahhan@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=sdf@google.com \
--cc=simon.horman@corigine.com \
--cc=song@kernel.org \
--cc=tariqt@mellanox.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
--cc=xdp-hints@xdp-project.net \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox