xdp-for-windows
xdp-for-windows copied to clipboard
microsoft
Add API to tear down XDP queue from interface
For NetVSC, interfaces will need to dynamically close queues. Add an XDP callback to initiate queue teardown.
Partially implemented: see XdpTxQueueNotify.
What does Linux have here as far as an API?
We don't have much knowledge of the Linux driver API since it's GPL. I don't think they have much use for per-queue info, though, so they might not even have a notion of this problem.
What does Linux have here as far as an API?
We don't have much knowledge of the Linux driver API since it's GPL. I don't think they have much use for per-queue info, though, so they might not even have a notion of this problem.
It is still straightforward to ask someone familiar with Linux XDP APIs. Point is that this project should really not have gratuitously different APIs when there is a widely used answer already in the industry. Just because you can't look at the implementation doesn't mean you can't look at existing callers for example.
The NIC interface is certainly not gratuitously different.
First off, Windows NIC drivers are already substantially different from Linux NIC drivers. The NIC driver environment provided by Windows and Linux are substantially different, and major NIC vendors have distinct Windows and Linux driver developer teams, and therefore tend to have substantially different NIC driver codebases. In short, convergence with Linux at the NIC layer is both impractical and provides minimal value for already-diverged NIC drivers.
Second, and less important, our API is different because we knew that Linux had been grappling with per-frame offload issues specifically, and per-frame metadata generally. The decision we made to support offloads and per-frame metadata as first-class citizens via shared per-queue descriptor rings -- along with our requirement that each NIC queue provide XDP an exclusive execution context, to simplify synchronization and enable user-mode polling in the future -- made per-queue bindings necessary and valuable.
So this isn't a case of "we don't know how Linux does this" so much as "there is no reason to mimic Linux here, and we intentionally went in a different direction".