Add ability to export maps, enables cross-program sharing

[drzaeus77]

Allow a program to export a map for other programs to use. This enables
cross-program map sharing.

parent program syntax:
BPF_TABLE("array", int, int, shared, 10);
BPF_TABLE_EXPORT(shared);

child program syntax:
BPF_TABLE("extern", int, int, shared, 10);

Signed-off-by: Brenden Blanco [email protected]

[4ast]

both programs need to be loaded by the same python/go master script, right?
syntax is a bit verbose... can export and definition be done with one macro?

[drzaeus77]

Same process, different BpfModule instance, correct. I had a different iteration which used bpf_pin_obj to share the maps, but that wasn't necessary for my use case and I didn't want to depend on 4.4 kernel just yet.

Right now the example is this:

BPF_TABLE("array", int, struct metadata, metadata, 8);
BPF_TABLE_EXPORT(metadata);

As a shorter syntax, how about:

BPF_TABLE_PUBLIC("array", int, struct metadata, metadata, 8);

Which is better, or can you think of a 3rd option?

[4ast]

BPF_TABLE_EXPORT("array", int, struct metadata, metadata, 8);
or
BPF_TABLE_PUBLIC("array", int, struct metadata, metadata, 8);
look fine.
Just BPF_TABLE + BPF_TABLE_EXPORT seems too verbose.

[drzaeus77]

@4ast please +1/-1

[4ast]

didn't get an email that pullreq got updated...
looks good. thanks for adding the test.

[zaheersm]

Any thoughts on how a table can be shared by two separate python master scripts?
BTW sorry for intruding. Thanks.

[drzaeus77]

Yes, we would use the BPF_OBJ_PIN and BPF_OBJ_GET features from the kernel to retrieve maps and programs that are persisted using the bpffs support that was added in kernel 4.4. I considered using that feature to implement this PR, but decided against it. Supporting fd pinning does require a bit of thought, since adding the feature will involve a system resource that needs to be properly cared for, otherwise resource leaks may occur.