> Sounds like you are developing/maintaining an XDP project. > > If so, and the kernel carries the patches in > https://lore.kernel.org/all/[email protected]/, > recommend modifying the XDP project using dispatcher like libxdp [1]. > Then, you are able to trace the subprogs which aim to run tail calls; > meanwhile, you are able to filter packets using pcap-filter, and to > output packets using bpf_xdp_output() helper. > > [1] > https://github.com/xdp-project/xdp-tools/blob/main/lib/libxdp/xdp-dispatcher.c.in
Thank you very much for your wonderful comment, Leon. This was the first time I learned that such a mechanism exists. It is a very interesting ecosystem. If I understand correctly, the idea is to invoke a component that dumps pcap data as one of the tail-called components, right? Thank you very much for sharing this idea with me. If I have a chance to write a new XDP program in the future, I would definitely like to try it. On the other hand, I feel that it is somewhat difficult to apply this idea directly to existing codebases, or to cases where the code is written in Go using something like cilium/ebpf. Also, when it comes to code running in production environments, making changes itself can be difficult. For that reason, I prototyped a tool like this. It is something like a middle ground between xdpdump and xdpcap. I built it so that only packets matched by cbpf are sent up through perf, and while testing it, I noticed that it does not work well for targets invoked via tail call. This is what motivated me to send the patch. https://github.com/takehaya/xdp-ninja Once again, thank you for sharing the idea. Takeru
