Re: [RFC bpf-next 5/5] samples/bpf/xdpsock_user.c: Launchtime/TXTIME API usage
From: Jesper Dangaard Brouer <hidden>
Date: 2021-08-18 08:55:02
Also in:
bpf
On 03/08/2021 19.10, Kishen Maloor wrote:
quoted hunk ↗ jump to hunk
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c index 3fd2f6a0d1eb..a0fd3d5414ba 100644 --- a/samples/bpf/xdpsock_user.c +++ b/samples/bpf/xdpsock_user.c
[...]
quoted hunk ↗ jump to hunk
@@ -741,6 +745,8 @@ static inline u16 udp_csum(u32 saddr, u32 daddr, u32 len, #define ETH_FCS_SIZE 4 +#define MD_SIZE (sizeof(struct xdp_user_tx_metadata)) + #define PKT_HDR_SIZE (sizeof(struct ethhdr) + sizeof(struct iphdr) + \ sizeof(struct udphdr))@@ -798,8 +804,10 @@ static void gen_eth_hdr_data(void) static void gen_eth_frame(struct xsk_umem_info *umem, u64 addr) { - memcpy(xsk_umem__get_data(umem->buffer, addr), pkt_data, - PKT_SIZE); + if (opt_launch_time) + memcpy(xsk_umem__get_data(umem->buffer, addr) + MD_SIZE, pkt_data, PKT_SIZE); + else + memcpy(xsk_umem__get_data(umem->buffer, addr), pkt_data, PKT_SIZE); }
I imagined that AF_XDP 'addr' would still point to the start of the packet data, and that metadata area was access via a negative offset from 'addr'. Maybe I misunderstood the code, but it looks like 'addr' (xsk_umem__get_data(umem->buffer, addr)) points to metadata area, is this correct? (and to skip this the code does + MD_SIZE, before memcpy) One problem/challenge with AF_XDP is that we don't have room in struct xdp_desc to store info on the size of the metadata area. Bjørn came up with the idea of having btf_id as last member (access able via minus 4 bytes), as this tells the kernel the size of metadata area. Maybe you have come up with a better solution? (of making the metadata area size dynamic) --Jesper