Toke Høiland-Jørgensen wrote: > John Fastabend <john.fastabend@xxxxxxxxx> writes: > > > Björn Töpel wrote: > >> From: Björn Töpel <bjorn.topel@xxxxxxxxx> > >> > >> Now that all XDP maps that can be used with bpf_redirect_map() tracks > >> entries to be flushed in a global fashion, there is not need to track > >> that the map has changed and flush from xdp_do_generic_map() > >> anymore. All entries will be flushed in xdp_do_flush_map(). > >> > >> This means that the map_to_flush can be removed, and the corresponding > >> checks. Moving the flush logic to one place, xdp_do_flush_map(), give > >> a bulking behavior and performance boost. > >> > >> Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > >> Signed-off-by: Björn Töpel <bjorn.topel@xxxxxxxxx> > >> --- > > > > __dev_map_flush() still has rcu_read_lock/unlock() around flush_list by > > this point, assuming I've followed along correctly. Can we drop those > > now seeing its per CPU and all list ops are per-cpu inside napi context? > > Hmm, I guess so? :) > > > Two reasons to consider, with this patch dev_map_flush() is always > > called even if the list is empty so even in TX case without redirect. > > But probably more important it makes the locking requirements more clear. > > Could probably be done in a follow up patch but wanted to bring it up. > > This series was already merged, but I'll follow up with the non-map > redirect change. This requires a bit of refactoring anyway, so I can > incorporate the lock removal into that... > > -Toke > Ah I was just catching up with email and missed itwas already applied. I can also submit a few fixup patches no problem for the comments and this. .John
