While it is useful on its own for testing, I have two questions:
Does it make sense to include this directly in x/net/bpf? Perhaps even in a package like x/net/bpf/bpftest, akin to net/http/httptest.
This package is useful for testing the logic of complicated BPF programs, without needing to actually create a socket and load the BPF program directly. This also allows testing of BPF programs on platforms like Windows, which do not have BPF.
Could this package be useful for more than just testing?
For example, on Windows, there is no BPF. But, perhaps this package could be used as a pseudo-BPF guarded by build tags, so that additional filtering logic would not need to be written when running a program that makes use of a BPF filter on Windows. Of course, this approach would not be nearly as fast as using the in-kernel VM on Linux or BSD, but it would help reduce code duplication.
I'd love to hear your thoughts on these ideas, @danderson and @mikioh . Ultimately, it may just be better for the package to continue existing on my personal GitHub, but I figured I would at least get a discussion around it started. Thanks for your time!
The text was updated successfully, but these errors were encountered:
Having a Go implementation of the BPF VM sounds great to have in x/net/bpf directly, IMO. It only grows the package API by one function (or is there more?), and it's a natural fit. The package docs will need to be tweaked to point out that this is not how you access the in-kernel filtering functionality, but that's simple enough.
My standard concern when implementing something like that is having a good interoperability test, to make sure the VM matches the reference implementation's behavior. Do you have such a test already?
I'm -0.5 on having automagic use of the VM on platforms that don't support BPF. To me, the packet filtering performance is part of the BPF contract when you attach a program to a socket, so having it sometimes be fast and sometimes be much slower is an undesirably surprising behavior. If a caller wants that behavior, I'd rather have it be explicit in their code, where they do a RecvFrom followed by running the Go VM themselves.
Very cool, thanks so much for doing that work! I'd suggest making the interop tests Skip() themselves when not run on linux, that'll make them always run with Go's own test infrastructure, without having to do manual tweaking of tags.
Sending a CL sounds great to me. I don't have commit rights to x/net, but I'll gladly throw in a review/+1.