Lorenz Bauer <lmb@xxxxxxxxxxxxxx> writes: > On Wed, 2 Oct 2019 at 14:30, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> >> >> This adds support to rtnetlink for setting and getting the per-device XDP >> chain map. The map is set by means of a new netlink attribute that contains >> a pointer to a BPF map of the XDP chain type. If such an attribute is >> included, it will be inserted into the struct net_device so that the XDP >> chain call code will pick it up on program execution. >> >> To prevent old userspace programs that do not understand the chain map >> attribute from messing up the chain call order, a netlink message with no >> chain map attribute set will be rejected if a chain map has already been >> installed. >> >> When installing a new chain call map, an XDP program fd must also be >> provided, otherwise the operation will be rejected. > > Why is the program required? I kind of expected the chain call map to > override any program. Mainly because drivers expect to attach an XDP program, not a map. We could conceivably emulate this by pulling out the first program from the map on attach (after we define semantics for this; just lookup ID 0?) and pass that down to the driver. But then we'd either need to make that first program immutable in the map, or we'd need to propagate map updates all the way down to the driver. Or alternatively, we'd need to teach all the drivers how to attach a map instead of a program. Lots of cans of worms there I'd rather not open... :) A userspace application or library could emulate all of this, though, by just accepting "attach" of a map, and turning that into the right netlink message. It would have the same problem re: map updates, but if it controls those that should be doable... -Toke
