On 2023-11-28 23:43, Stephen Hemminger wrote:

On Mon, 27 Nov 2023 18:30:55 -0800
Quentin Deslandes [off-list ref] wrote:

quoted

BPF allows programs to store socket-specific data using
BPF_MAP_TYPE_SK_STORAGE maps. The data is attached to the socket itself,
and Martin added INET_DIAG_REQ_SK_BPF_STORAGES, so it can be fetched
using the INET_DIAG mechanism.

Currently, ss doesn't request the socket-local data, this patch aims to
fix this.

The first patch fixes a bug where the "Process" column would always be
printed on ss' output, even if --processes/-p is not used.

Patch #2 requests the socket-local data for the requested map ID
(--bpf-map-id=) or all the maps (--bpf-maps). It then prints the map_id
in a dedicated column.

Patch #3 uses libbpf and BTF to pretty print the map's content, like
`bpftool map dump` would do.

While I think it makes sense for ss to provide the socket-local storage
content for the sockets, it's difficult to conciliate the column-based
output of ss and having readable socket-local data. Hence, the
socket-local data is printed in a readable fashion over multiple lines
under its socket statistics, independently of the column-based approach.

Here is an example of ss' output with --bpf-maps:
[...]
ESTAB                  2960280             0 [...]
    map_id: 259 [
        (struct my_sk_storage) {
            .field_hh = (char)127,
            .<anon> = (union <anon>) {
                .a = (int)0,
                .b = (int)0,
            },
        },
    ]

Quentin Deslandes (3):
  ss: prevent "Process" column from being printed unless requested
  ss: add support for BPF socket-local storage
  ss: pretty-print BPF socket-local storage

 misc/ss.c | 822 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 818 insertions(+), 4 deletions(-)

Useful, but ss is growing into a huge monolithic program and may need some
refactoring. Also, this cries out for a json output format. Which ss doesn't
have yet.

I've submitted a v2 to fix Martin's comments and also improve the printing
behavior. The updated revision reduces the number of lines added by 50%.

Regarding the JSON output, is it specifically for socket-local storage, or
more generally, for the whole tool? I agree with you anyway, but I would argue
that it doesn't fit this series, although I can work on this as a next step.