Re: [RFC bpf-next 5/5] samples/bpf/xdpsock_user.c: Launchtime/TXTIME API usage

[Jesper Dangaard Brouer <jbrouer@redhat.com>]

On 03/08/2021 19.10, Kishen Maloor wrote:
> 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
[...]
> @@ -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