Saeed Mahameed <sae...@mellanox.com> writes: > On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote: >> On Thu, 2019-02-07 at 19:08 +0000, Saeed Mahameed wrote: >> > >> > So >> > 1) on dev_map_update_elem() we will call >> > dev->dev->ndo_bpf() to notify the device on the intention to >> > start/stop >> > redirect, and wait for it to create/destroy the HW resources >> > before/after actually updating the map >> > >> >> silly me, dev_map_update_elem must be atomic, we can't hook driver >> resource allocation to it, it must come as a separate request >> (syscall) >> from user space to request to create XDP redirect resources. >> > > Well, it is possible to render dev_map_update_elem non-atomic and fail > BPF programs who try to update it in the verifier > check_map_func_compatibility. > > if you know of any case where devmap needs to be updated from the BPF > program please let me know.
Well, maybe? My plan for dealing with the non-map redirect variant is essentially to have a hidden map that does just-in-time insertion of ifindexes if they are not already there; and rework XDP_REDIRECT to use that. However, this would essentially be an insert from eBPF; but I guess maybe it could be deferred until the RX-side driver exits its NAPI loop (as we're buffering frames in the map anyway)? -Toke
