Dear Chris, Please take a look at https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html#complications et seq.
I tried to document this exact bit of code. Let me know if the document helps, or if it raises more questions than it answers. Feel free to push doc patches to improve the writeup. HTH... Dave -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Christian Hopps Sent: Monday, June 3, 2019 6:25 PM To: [email protected] Cc: Christian Hopps <[email protected]> Subject: [vpp-dev] "owner node" help understanding. Hi, I'm going through the VPP infra code to fully understand how everything hangs together. I'm getting close to understanding things, except (at least) one thing. I can't figure out what the "owner node" thing is for. The concept appears to be that only one vlib_next_frame_t should "own" the enqueue rights to a given (next) node at any given time. I'm not sure why this is so important though b/c, as I understand, things are run-to-completion so whatever node is currently running should "own" the right to enqueue to all of it's next nodes. It might have something to do with item 1 below though. Two things are done to establish this owning relationship. 1) The code swaps the content of the previous "owning" vlib_next_frame_t with the current nodes vlib_next_frame_t for the given next node -- which looks like a cache-line size copy so i guess no big deal. Plus this would copy any current vlib_frame_t to be used by the newly running node (good maximal use of the frame I guess). 2) If the old owning next-frame was "PENDING" (thus the new owner will be b/c of the swap), the code goes back through all vlib_pending_frame_ts and updates their vlib_next_frame_t "back-pointers" to point to the new "owning" vlib_next_frame_t. The code also does a bunch of housekeeping in other places to make sure this back-pointer is kept valid. This seems more expensive than (1) and I'm not sure I understand why it's done. The only place this back-pointer appears to be used is to grab a next-frame during pending frame dispatch. This next frame is then used in the following ways during dispatch: a) Before dispatch: Set TRACE on node if set in next-frame flags b) After dispatch: Possibly return the now unused frame to the next-frame. But, the trace flag could be copied into the vlib_pending_frame_t (after adding a flag field to hold it), so (a) shouldn't needed. And, returning the frame to re-use (vs freeing) in (b) is good, but why not just return it to the original next-frame that created the pending_frame in the first place? It seems to make more sense to do this anyway, and would be what happened if (2) never went back updating the back-pointers in the first place. I'm sure I probably missed something else, so thanks for any help with fixing my understanding. :) Thanks again, Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13208): https://lists.fd.io/g/vpp-dev/message/13208 Mute This Topic: https://lists.fd.io/mt/31915933/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
