I'm not clear on what you mean by table add/del, but I can give you the scenario I'm concerned with.
I have a packet P input and it has some state S associated with it. The API wants to delete state S. When is it safe? Say P's arc from input to output contains E edges. Each node on the arc could conceivably handoff packet P to another worker for processing. So if I read things correctly I need to wait at least E laps until I know for sure that P is out of the system, and S is safe to delete. Q: How do I know what value E is? I am not in control of all nodes along a P's arc and how they might handoff packets, and the graph is not acyclic so I couldn't even use a max value like the total number of nodes in the graph for E as the packet may loop back. Q: Which lap counter am I looking at? As you point out each vlib_main_t has it's own counter (main_loop_count?) so I think I have to record every workers main_loop_count in the state S and wait for every counter to be +E before deleting S. Thanks for the help! Chris. > On Mar 25, 2020, at 12:15 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote: > > +1. > > View any metadata subject to table add/del accidents with suspicion. There is > a safe delete paradigm: each vlib_main_t has a “lap counter”. When deleting > table entries: atomically update table entries. Record the lap counter and > wait until all worker threads have completed a lap. Then, delete (or > pool_put) the underlying data structure. > > Dave > > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Damjan Marion > via Lists.Fd.Io > Sent: Wednesday, March 25, 2020 12:10 PM > To: Christian Hopps <cho...@chopps.org> > Cc: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] worker barrier state > > > > > On 25 Mar 2020, at 16:01, Christian Hopps <cho...@chopps.org> wrote: > > > > Is it supposed to be the case that no packets are inflight (*) in the graph > > when the worker barrier is held? > > > > I think perhaps MP unsafe API code is assuming this. > > > > I also think that the frame queues used by handoff code violate this > > assumption. > > > > Can someone with deep VPP knowledge clarify this for me? :) > > > correct, there is small chance that frame is enqueued right before worker > hits barrier… > > — > Damjan > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15873): https://lists.fd.io/g/vpp-dev/message/15873 Mute This Topic: https://lists.fd.io/mt/72542383/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
