On 3/3/25 8:13 AM, Marcus Wichelmann wrote:
Am 28.02.25 um 20:49 schrieb Martin KaFai Lau:
quoted
On 2/27/25 6:23 AM, Marcus Wichelmann wrote:
quoted
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").quoted
Signed-off-by: Marcus Wichelmann <redacted>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <redacted>
---
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.