On 2018-12-18 03:36, Jakub Kicinski wrote:
On Mon, 17 Dec 2018 14:39:57 +0100, Björn Töpel wrote:
OTOH the implementation would probably look different if there was a
per-q program, because this would open up for more optimizations. One
could even imagine that the socket fd was part of the program (part of
relocation process) when loading the program. That could get rid of yet
another if-statement that check for socket existence. :-)
Interesting thought, then we would have to teach the BPF subsystem to
express program dependencies (this program can only be used on queue
where given XSK is attached), and have the networking subsystem
(drivers?) check those constraints when attaching. Did I get this right?
Yes. Well, yet another dependency, similar to how a program refers to maps.
The per-queue loading could be similar to passing the prog_ifindex
in the prog-loading attribute, used by the HW offloading. I.e. in
addition to prog_ifindex, there would be, say, prog_ifqueue.
For the XDP socket constraint checking I see two models. The BPF program
refers to an unbound socket(s), and by installing the program to a
certain Rx queue, the socket(s) will be implicitly bound. If the
socket(s) are bound to certain device/queue at install time, the
networking subsystem will scream if the program is installed to a
ifindex/queue != prog ifindex/queue.
Is the XDP HW offloading program verified at load or install time, or both?
Again, this is just me thinking out loud... Might be a lousy idea. :-)
Side-note: When we started AF_XDP, we played around with the idea to
associate the XSKMAP to a certain ifindex/queue, to be able to reject
sockets bound to another device/queue and elide a couple of checks in
the fast-path. My ramblings above is somewhat in the same vein. We'd
like to be able to set program constraints for netdev/queue target, so
that we can remove checks in the fast-path.
Björn
