On Thu, 18 Apr 2019 18:13:37 +0000, Vlad Buslov wrote: > On Thu 18 Apr 2019 at 21:02, Jakub Kicinski <jakub.kicin...@netronome.com> > wrote: > > On Thu, 18 Apr 2019 17:58:26 +0000, Vlad Buslov wrote: > >> On Thu 18 Apr 2019 at 20:46, Jakub Kicinski <jakub.kicin...@netronome.com> > >> wrote: > >> > On Thu, 18 Apr 2019 16:33:22 +0000, Vlad Buslov wrote: > >> >> Considering this, I tried to improve my solution to remove possibility > >> >> of multiple adds of same filter and it seems to me that it would be > >> >> enough to move hw_filters list management in flower offloads functions: > >> >> add filter to list while holding rtnl lock in fl_hw_replace_filter() and > >> >> remove it from list while holding rtnl lock in fl_hw_destroy_filter(). > >> >> What do you think? > >> > > >> > Sounds good for now, but I presume the plan is to get rid of rtnl > >> > around the driver call.. at which point we would switch to a rwlock? :) > >> > > >> > >> Yes, but I would like the lock to be in cls hw offloads API > >> (tc_setup_cb_replace(), etc) and not in flower itself. That would also > >> solve deadlock issue and make code reusable for any further unlocked > >> classifiers implementations. > > > > And then the HW list goes along with it into the common code? > > That'd be quite nice. > > The goal is to have a lock in tcf_block and use it synchronize cb_list > and all related counters (offloadcnt, etc). Now I also want to use it to > protect hw_filters list and prevent the double-add issue. Meanwhile rtnl > lock can do the job.
SGTM 👍
