On Mon, Jul 30, 2018 at 5:45 PM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Mon, 30 Jul 2018 17:33:39 -0700, Daniel Colascione wrote: >> On Mon, Jul 30, 2018 at 5:26 PM, Jakub Kicinski wrote: >> > On Mon, 30 Jul 2018 03:25:43 -0700, Daniel Colascione wrote: >> > > On Mon, Jul 30, 2018 at 3:04 AM, Daniel Borkmann <dan...@iogearbox.net> >> > > wrote: >> > > > Hmm, I don't think such UAPI as above is future-proof. In case we >> > > > would want >> > > > a similar mechanism in future for other maps, we would need a whole >> > > > new bpf >> > > > command or reuse BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES as a workaround >> > > > though >> > > > the underlying map may not even be a map-to-map. Additionally, we >> > > > don't have >> > > > any map object at hand in the above, so we couldn't make any finer >> > > > grained >> > > > decisions either. Something like below would be more suitable and >> > > > leaves room >> > > > for extending this further in future. >> > > >> > > YAGNI. Your proposed mechanism doesn't add anything under the current >> > > implementation. >> > >> > FWIW in case of HW offload targeting a particular map may allow users >> > to avoid a potentially slow sync with all the devices on the system. >> >> Sure. But such a thing doesn't exist right now (right?), and we can >> add that more-efficient-in-that-one-case BPF interface when it lands. >> I'd rather keep things simple for now. > > You mean map-in-map offload doesn't exist today? True, but it's on the > roadmap for Netronome.
Sounds cool. I'd still wait until map-in-map offload lands until adding the map-specific API though. > Tangentially it would be really useful for us to have a "the map has > actually been freed" notification/barrier. We have complaints of users > creating huge maps and then trying to free and recreate them quickly, > and the creation part failing with -ENOMEM, because the free from a > workqueue didn't run, yet :( It'd probably require a different API to > solve than what's discussed here, but since we're talking about syncing > things I thought I'd put it out there... Yeah. What you're talking about is what I meant upthread when I briefly mentioned a "refcount draining approach" --- you'd block until all references except your own to a map disappeared.
