Daniel Borkmann [off-list ref] writes:

On 7/28/21 6:55 PM, Kumar Kartikeya Dwivedi wrote:

quoted

This file implements some common helpers to consolidate differences in
features and functionality between the various XDP samples and give them
a consistent look, feel, and reporting capabilities.

Some of the key features are:
  * A concise output format accompanied by helpful text explaining its
    fields.
  * An elaborate output format building upon the concise one, and folding
    out details in case of errors and staying out of view otherwise.
  * Extended reporting of redirect errors by capturing hits for each
    errno and displaying them inline (ENETDOWN, EINVAL, ENOSPC, etc.)
    to aid debugging.
  * Reporting of each xdp_exception action for all samples that use these
    helpers (XDP_ABORTED, etc.) to aid debugging.
  * Capturing per ifindex pair devmap_xmit counts for decomposing the
    total TX count per devmap redirection.
  * Ability to jump to source locations invoking tracepoints.
  * Faster retrieval of stats per polling interval using mmap'd eBPF
    array map (through .bss).
  * Printing driver names for devices redirecting packets.
  * Printing summarized total statistics for the entire session.
  * Ability to dynamically switch between concise and verbose mode, using
    SIGQUIT (Ctrl + \).

The goal is sharing these helpers that most of the XDP samples implement
in some form but differently for each, lacking in some respect compared
to one another.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

Overall I think it's okay to try to streamline the individual XDP tools, but I
also tend to wonder whether we keep going beyond the original purpose of kernel
samples where the main goal is to provide small, easy to hack & stand-alone code
snippets (like in samples/seccomp ... no doubt we have it more complex in BPF
land, but still); things people can take away and extend for their purpose. A big
portion of the samples are still better off in selftests so they can be run in CI,
and those that are not should generally be simplified for developers to rip out,
modify, experiment, and build actual applications on top.

FWIW the idea of improving the samples came from Jesper and myself;
we've come to rely on them quite a bit for benchmarking, and our QE
folks run them for testing as well. And I've lost count of the number of
times I had to redo tests because something wasn't working correctly and
I didn't notice that the numbers were off. Kumar took the "improve the
XDP samples" idea and ran with it, and I think the result is much
improved; having it be immediately obvious when something is off is a
huge benefit!

So while I do share your concern about expanding the samples code too
much, in this instance I think it's an improvement. I've toyed with the
idea of also distributing some of the XDP samples with xdp-tools so they
are easier to install as standalone utilities, but I think that is a
secondary concern for later.

-Toke