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.
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13207): https://lists.fd.io/g/vpp-dev/message/13207 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]] -=-=-=-=-=-=-=-=-=-=-=-
