Re: [PATCH v3 bpf-next] cpumap: bulk skb using netif_receive_skb_list
From: Lorenzo Bianconi <hidden>
Date: 2021-04-22 10:59:23
Also in:
bpf
[...]quoted
quoted
+ TP_ARGS(map_id, processed, sched, xdp_stats), TP_STRUCT__entry( __field(int, map_id) __field(u32, act) __field(int, cpu) - __field(unsigned int, drops) __field(unsigned int, processed)So, struct member @processed will takeover the room for @drops. Can you please test how an old xdp_monitor program will react to this? Will it fail, or extract and show wrong values?Ack, right. I think we should keep the struct layout in order to maintain back-compatibility. I will fix it in v4.quoted
The xdp_mointor tool is in several external git repos: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_kern.c https://github.com/xdp-project/xdp-tutorial/tree/master/tracing02-xdp-monitor
Running an old version of xdp_monitor with a patched kernel, I verified the xdp sample does not crash but it reports wrong values (e.g. pps are reported as drops for tracepoint disagliment). I think we have two possibilities here: - assuming tracepoints are not a stable ABI, we can just fix xdp samples available in the kernel tree and provide a patch for xdp-project - keep current tracepoint layout and just rename current drop variable in bpf/cpumap.c in something like skb_alloc_drop. I am not against both of them. What do you think? Regards, Lorenzo
quoted
Do you have any plans for fixing those tools?I update xdp_monitor_{kern,user}.c and xdp_redirect_cpu_{kern,user}.c in the patch. Do you mean to post a dedicated patch for xdp-project tutorial? Regards, Lorenzoquoted
-- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer