Add bpf_redirect_map for AF_XDP sockets#1008
Conversation
| Starting with XDP version 1.1, experimental eBPF support can be enabled by appending an `ADDLOCAL=xdp_ebpf` parameter to the `msiexec.exe` install commands. | ||
| > **Note:** The built-in rules-based program API (`XDP_RULE` / `XDP_MATCH_TYPE` | ||
| > / `XdpCreateProgram`) is deprecated and planned for removal. All users should | ||
| > migrate to eBPF programs. |
There was a problem hiding this comment.
nit: should XDP add support for multi-attach as this is being deprecated?
There was a problem hiding this comment.
Is multi-attach when the program gets loaded once and continuously applies to all interfaces?
Right now, XDP doesn't support that in any program mode - it would be a separate feature request.
There was a problem hiding this comment.
no it means a user can attach multiple different XDP programs to the same interface. Agree that that is outside the scope of this PR and is a separate feature request, but should we file an issue to track that work?
| { | ||
| .header = EBPF_HELPER_FUNCTION_PROTOTYPE_HEADER, | ||
| .helper_id = BPF_FUNC_redirect_map, | ||
| .name = "bpf_redirect_map", |
There was a problem hiding this comment.
since this helper function is also applicable for TC, should we add this in ebpfcore? ebpf supports implementing a "virtual" helper function in ebpfcore that can then be overridden by the extension. that way, multiple program info providers can have their own implementations of the same helper functions?
There was a problem hiding this comment.
Yeah, that would be perfect. Does eBPF-for-Windows support that today? Does a virtual function like that require coordination between extensions, or since TC and XDP programs are different types, they each define their own bpf_redirect_map with no overlap?
Or would this be something like a bpf_redirect_map virtual function gets implemented by eBPF core, and then it calls into a map-specific type helper?
There was a problem hiding this comment.
Yes this is currently supported in ebpf-for-windows. There will be no implementation in ebpfcore, and each extension will need to provide their own implementation. If a program type does not support this helper, and a BPF program of that type uses this helper, load of that program will fail.
See microsoft/ebpf-for-windows#3464 where bpf_get_socket_cookie() was added in the same way.
There was a problem hiding this comment.
Ah, that makes sense. I'll create a similar virtual function and hopefully catch the eBPF 1.2 release.
There was a problem hiding this comment.
Created microsoft/ebpf-for-windows#5302.
2 participants
Description
Describe the purpose of and changes within this Pull Request.
WIP
Resolves #941.
Testing
Do any existing tests cover this change? Are new tests needed?
CI, automated functional and spin tests added.
Documentation
Is there any documentation impact for this change?
Yes, docs added, and also deprecation notices are added for the built-in program API, now that the feature gap is effectively closed.
Installation
Is there any installer impact for this change?
N/A.