Guy Harris [off-list ref] writes:

On Dec 22, 2020, at 3:31 PM, Linus Lüssing [off-list ref] wrote:

quoted

Basically we want to do live measurements of the overhead of the mesh
routing protocol and measure and dissect the layer 2 broadcast traffic.
To measure how much ARP, DHCP, ICMPv6 NS/NA/RS/RA, MDNS, LLDP overhead
etc. we have.

OK, so I'm not a member of the bpf mailing list, so this message won't
get to that list, but:

Yes it did :)

Given how general (e)BPF is in Linux, and given the number of places
where you can add an eBPF program, and given the extensions added by
the "(e)" part, it might be possible to:

	construct a single eBPF program that matches all of those packet types;

	provides, in some fashion, an indication of *which* of the packet types matched;

	provides the packet length as well.

If you *only* care about the packet counts and packet byte counts,
that might be sufficient if the eBPF program can be put into the right
place in the networking stack - it would also mean that the Linux
kernel wouldn't have to copy the packets (as it does for each
PF_PACKET socket being used for capturing, and there's one of those
for every pcap_t), and your program wouldn't have to read those
packets.

libpcap won't help you there, as it doesn't even know about eBPF, much
less about it's added capabilities, but it sounds as if this is a
Linux-specific program, so that doesn't matter. There may be a
compiler allowing you to write a program to do what's described above
and get it compiled into eBPF.

You could certainly do this in eBPF: Write an eBPF program that matches
each packet type, and updates a BPF map with the count and total size.
Then you just need to read this map from userspace to get the values you
want, and there will be no copying involved anywhere.

We have some examples of packet parsing in the XDP tutorial (also partly
applicable to other eBPF hooks with direct packet access):
https://github.com/xdp-project/xdp-tutorial/blob/master/packet-solutions/xdp_prog_kern_02.c

I don't know whether there's a place in the networking stack to which
you can attach an eBPF probe to do this, but I wouldn't be surprised
to find out that there is one.

On egress you could attach to the TC hook; on ingress if your driver has
native XDP support you can attach there with very little overhead. If it
doesn't (which would be the case for WiFi drivers), you may as well use
the TC hook on ingress as well (via a tc 'ingress' filter). There's also
a 'generic XDP', but it doesn't really have any performance benefit over
TC, so you may as well just use the TC hook...

Here's an example of how to share code between the XDP and TC hooks:

https://github.com/xdp-project/bpf-examples/tree/master/encap-forward

The bpf-examples repository is also meant as a way to showcase
real-world examples of how to do useful things with BPF, and contains
some Makefile infrastructure to get the build setup. If you want to
contribute your packet monitor as an example here, feel free to open a
pull request! :)

-Toke