On 3/3/25 8:13 AM, Marcus Wichelmann wrote:
Am 28.02.25 um 20:49 schrieb Martin KaFai Lau:
On 2/27/25 6:23 AM, Marcus Wichelmann wrote:
When the XDP metadata area was used, it is expected that the same metadata can also be accessed from TC, as can be read in the description of the bpf_xdp_adjust_meta helper function. In the tun driver, this was not yet implemented.
To make this work, the skb that is being built on XDP_PASS should know of the current size of the metadata area. This is ensured by adding calls to skb_metadata_set. For the tun_xdp_one code path, an additional check is necessary to handle the case where the externally initialized xdp_buff has no metadata support (xdp->data_meta == xdp->data + 1).
More information about this feature can be found in the commit message of commit de8f3a83b0a0 ("bpf: add meta pointer for direct access").
Signed-off-by: Marcus Wichelmann marcus.wichelmann@hetzner-cloud.de
Reviewed-by: Willem de Bruijn willemb@google.com Acked-by: Jason Wang jasowang@redhat.com
drivers/net/tun.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 4ec8fbd93c8d..70208b3a2e93 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c
The changes have conflicts with the commit 2506251e81d1 ("tun: Decouple vnet handling").
It is better to rebase the works onto the bpf-next/net, i.e. the "net" branch instead of the "master" branch.
Alright, will do that. Should I send it as a v5 and still with "PATCH bpf-next" in the header or something else?
That should do. The bpf CI should pick up the bpf-next/net if it fails to apply to the bpf-next/master because of the conflict mentioned above.
For patch 3, it should help to avoid the future merge conflict if the open_tuntap() is added a few lines above in the network_helpers.h. For patch 6, the "test_ns_" naming is not in bpf-next/net yet. Other tests in the same file is doing netns_new. May be just do the same and cleanup all at once of this file later.