Add xdp-synproxy to bpf-examples

[vincentmli]

this code is from kernel bpf selftests xdp synproxy, removed the tc part for simplicity, shows an exmaple of using libxdp to attach xdp synproxy program on network interface.

if port is not in allowed ports, the packet will be dropped by xdp synproxy by default, this would break tcp connections to ports that user does not want to do synproxy, change the default to allow connection pass through.

[vincentmli]

Hi @tohojo:

Here is the PR to add xdp-synproxy to bpf-examples repo, please review :)

[vincentmli]

Hi @tohojo do you have time to review this PR? :)

[vincentmli]

@tohojo I like your idea of using skeleton to save the user space program from loading external object file, so I updated the code with initial skeleton changes, the code could still be optimized like the map access through skeleton, maybe we save that for next revision and get this example in first, what do you think?

[vincentmli]

sorry I messed up the "nit" error path :), just saw your comment, I should wait for your comment

[vincentmli]

could not comment on your comment from github, you cleared confusion

" Yes, Every xdp_prog pointer needs to be passed to xdp_program__close() before exiting, regardless of whether it's going through an error path or a success path. Same thing with the skeleton, when created, it needs to be destroyed properly again.

There is no side effect to the xdp_program__close(), the program is only detached by an explicit xdp_program__detach()."

should skeleton also be destroyed after program attachment, regardless if the attachment succeeded or not? I pushed the change, bare with me, we are getting closer

[vincentmli]

so xdp_program and skeleton are sort of preparation resources for program attachment, after program attachment, regardless attachment success or not, the xdp_program and skeleton are no longer needed and can be freed/destroyed, am I understanding it correct ?

[tohojo]

Yup, Those data structures are for keeping the userspace data around, and once the program has been loaded into the kernel we no longer need them (since we're not using the skeleton for accessing the maps).

[vincentmli]

Yup, Those data structures are for keeping the userspace data around, and once the program has been loaded into the kernel we no longer need them (since we're not using the skeleton for accessing the maps).

I see, if we access map through skeleton, we should keep skeleton around unless program is detached, if you ignore the nit, I would not know these details, I mostly do code copy and paste, not fully understanding the details