xdp_program__clone not exposed via libxdp.h

[gizahNL]

Not sure if this is intentional, however xdp_program__clone is useful and it's non static implementation suggests it might've been intended for public use.

[tohojo]

No, that's intentional (it's marked as LIBXDP_HIDE_SYMBOL in libxdp_internal.h). We could expose it, though, I suppose; what do you need it for? :)

[gizahNL]

I'm working on a ST-2110 (uncompressed video, lots of packets ;) ) receiving application. I need to load my own xdp programs & will have multiple processes running with the same base program.

Being lazy (and never absolutely bug free) I'd rather use code that's maintained upstream for cloning my xdp program into the multiple instances of my application ;)

[tohojo]

Right, okay, but I'm not sure that function will do what you need: it'll just create a duplicated reference to a program already loaded into the kernel, you won't actually have two instances of the program loaded.

Loading multiple copies of the same program is not good for performance anyway, BTW; you'd see better results if you have your userspace programs share the same XDP program. I assume this is using AF_XDP, right? You can have a single program redirect to multiple XSK sockets conditionally...

[gizahNL]

Sorry, I guess I wasn't clear: that's exactly what I need ;)

The application instances each use the same XDP program with some instance specific data inserted in a map (IP & port). Unfortunately the default XDP program isn't enough for us because we need to filter based in IP & port as we've seen XDP sockets eating packets not intended for it, and from testing the normal flow control commands via ethtool have not seen sufficient to prevent it.

[tohojo]

OK, so how would you use xdp_program__clone() for this, specifically? Just trying to make sure this is a usage that makes sense and that we can keep supporting it going forward :)

[gizahNL]

I've basically replicated the control flow of __xsk_setup_xdp_prog(struct xsk_socket xsk, int xsks_map_fd)

So my flow is basically: -lookup if program is already loaded. -if so, clone it -if not, load it

-get map fd's -populate map fd's

If doing this via libxdp isn't the best way/doesn't make the most sense I'd be happy to learn ;) Though it seems like libxdp should be the best place for managing my sock AF_XDP program(s)

Perhaps a more useful API endpoint would fully take care of doing the lookup & cloning, taking a program name, program filepath/embedded object and optional verifier function (personally for me verifier isn't needed, since every upgrade to our software would entail a full reboot anyways)

[tohojo]

Ah, I see. So you want to clone it to get it detached from the multiprog instance (why? do you keep it around after closing the multiprog?).

You could simplify your logic if you just pin the map when you install the program, though? Then the logic just becomes:

• Get map from pin location
• If this fails, load the program and pin the map

(Side note, looks like xsk_lookup_program() leaks the multiprog instance, guess we should fix that).

[gizahNL]

Ah, I see. So you want to clone it to get it detached from the multiprog instance (why? do you keep it around after closing the multiprog?).

You could simplify your logic if you just pin the map when you install the program, though? Then the logic just becomes:

* Get map from pin location

* If this fails, load the program and pin the map

(Side note, looks like xsk_lookup_program() leaks the multiprog instance, guess we should fix that). Yes, the processes can get restarted individually, but would use the same XDP prog instance on that interface.

The program is basically just the standard XDP redirect program patched to XDP_PASS when the target IP & port are not in the map.