[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZVvMfcOnqsyocJ6A@google.com>
Date: Mon, 20 Nov 2023 13:15:41 -0800
From: Stanislav Fomichev <sdf@...gle.com>
To: Larysa Zaremba <larysa.zaremba@...el.com>
Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org, yhs@...com,
john.fastabend@...il.com, kpsingh@...nel.org, haoluo@...gle.com,
jolsa@...nel.org, David Ahern <dsahern@...il.com>, Jakub Kicinski <kuba@...nel.org>,
Willem de Bruijn <willemb@...gle.com>, Jesper Dangaard Brouer <hawk@...nel.org>,
Anatoly Burakov <anatoly.burakov@...el.com>, Alexander Lobakin <alexandr.lobakin@...el.com>,
Magnus Karlsson <magnus.karlsson@...il.com>, Maryam Tahhan <mtahhan@...hat.com>,
xdp-hints@...-project.net, netdev@...r.kernel.org,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>, Tariq Toukan <tariqt@...lanox.com>,
Saeed Mahameed <saeedm@...lanox.com>, Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Subject: Re: [PATCH bpf-next v7 17/18] selftests/bpf: Use AF_INET for TX in xdp_metadata
On 11/15, Larysa Zaremba wrote:
> The easiest way to simulate stripped VLAN tag in veth is to send a packet
> from VLAN interface, attached to veth. Unfortunately, this approach is
> incompatible with AF_XDP on TX side, because VLAN interfaces do not have
> such feature.
>
> Replace AF_XDP packet generation with sending the same datagram via
> AF_INET socket.
>
> This does not change the packet contents or hints values with one notable
> exception: rx_hash_type, which previously was expected to be 0, now is
> expected be at least XDP_RSS_TYPE_L4.
Btw, I've been thinking a bit about how we can make this test work for both
your VLANs and my upcoming af_xdp tx side. And seems like the best
way, probably, is to have two tx paths exercised: veth and af_xdp.
For veth, we'll verify everything+vlans, for af_xdp we'll verify
everything except the vlans.
Originally I was assuming that I'll switch this part back to af_xdp, but
I don't think having tx vlan offload makes sense (because af_xdp
userspace can just prepare the correct header from the start).
So if you're doing a respin, maybe see if we can keep af_xdp tx part
but make it skip the vlans verification?
generate_packet_af_xdp();
verify_xsk_metadata(/*verify_vlans=*/false);
geenrate_packet_veth();
verify_xsk_metadata(/*verify_vlans=*/true);
?
Powered by blists - more mailing lists