"Brian G. Merrell" <brian.g.merrell@xxxxxxxxx> writes: > On 21/02/11 12:18PM, Toke Høiland-Jørgensen wrote: >> "Brian G. Merrell" <brian.g.merrell@xxxxxxxxx> writes: >> >> > On 21/01/29 01:02PM, Toke Høiland-Jørgensen wrote: >> >> Hi Brian >> >> >> >> I've posted a first draft of this protocol description here: >> >> https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/protocol.org >> >> >> >> Please take a look and let me know what you think. And do feel free to >> >> point out any places that are unclear, as I said this is a first draft, >> >> and I'm expecting it to evolve as I get feedback from you and others :) >> >> >> >> -Toke >> >> >> > >> > Thanks so much for doing this Toke. There's a lot of great information. >> > I did one read-through, and didn't notice any surprises compared to the >> > code that I've read so far. >> >> Awesome! :) > > A question for anyone (sorry if it's a silly one)... > > I did a second read-through of the protocol this evening. I wanted to > take a deeper look at the function calls that are referenced. Some of > them are BPF syscalls, which should be relatively straightforward to > interface with from Go. However, some functions like > bpf_get_link_xdp_info() appear to reside deep in the bowels of libbpf. > I'd really like to avoid needing cgo bindings, so my question is if > there some way to 1) interface with these functions that I'm just not > seeing, or 2) achieve what's necessary for implementing libxdp by only > utilizing syscalls. bpf_get_link_xdp_info() is a wrapper around the kernel rt_netlink interface. It issues an RTM_GETLINK with flags NLM_F_DUMP | NLM_F_REQUEST and parses the IFLA_XDP attribute on the return value to extract the program ID of the currently attached XDP program. I'm pretty sure you can find an existing netlink library for Go, so this should be pretty straight-forward to implement. But point well taken that a document such as the protocol doc should refer to the kernel interface and not the libbpf internals - I'll fix that :) -Toke
|