As libbpf is heading towards a first major release, we wanted to
discuss libbpf's object pinning strategy.
bpf object pinning has a couple of use cases (feel free to add, there
are more for sure):
1. Sharing specific bpf objects between different processes (for
example, one process loads a bpf skeleton, another one interacts with
it using various bpf maps (for example, for changing configurations
(i.e. dynamic networking rules etc))
2. Preventing bpf objects from destruction upon owning process exit
(i.e. to prevent bpf progs detach upon userspace program crash)
Regarding the first use case, for most cases manually setting the pin
path (both in the loading process and in other processes) will
probably be the best. In such cases, no redesign is required here.
For the second one, something like the bpf_object__pin will be more
appropriate (to allow a complete reuse of the bpf objects). For that
use case, some sensible requirements we can consider are:
1. Paths should be unique:
a. at the bpf_object level (that is, same pinnable objects that
belong to different bpf_object s should be pinned at different paths).
b. in the same bpf_object, between different pinnable object types
(i.e. a map and a prog) should always be pinned at different paths.
c. different objects, belonging to the same bpf_object and of the
same type should be pinned at different paths.
2. Paths should be predictable, given enough information on the
originating bpf_object (that is, adding random UID to ensure
uniqueness is not an option).
All the above should be applied to auto-pinned maps and the
bpf_object__pin function. I am not sure if the
bpf_object__pin_{maps,programs} should conform to those requirements
too. Of course, all paths should be overridable similarly to the
current implementation.
Regarding implementation, 1.c. will already be satisfied by the
current implementation (after the program name pinning path will be
changed, since both map names and function names are unique inside a
single object).
For 1.a and 1.b, I think that bpf_object__pin should produce the
following directory layout:
<obj_name>
├── maps
│ └── <map_name>
└── programs
└── <program_name>
If we decide that the requirements should apply to the specific
bpf_object__pin_<type>s variants, then each will produce
<obj_name>
└── <type>s (i.e. maps, programs)
└── <name>
It may be better to put all pinned objects under a objects/ directory
too, I am not sure about that.
As a last point, I think that it will be nice to have a way to pin a
bpf_object_skeleton. This will be an improvement over the current
bpf_object__pin since skeletons keep track of attached links.
There are more use cases I am not familiar with for sure, so I would
like to hear other's opinions and comments.
