The prevailing vector size is a self-timed, stable equilibrium value, arranged by the graph dispatcher. Individual graph nodes don't have to worry about the problem. Follow the coding patterns you'll see all over the place, and you should be good.
The graph dispatcher is essentially a while(1) loop which scrapes as many packets as it can from an input device rx ring. We form a vector of packets from each RX ring scrape, and process them through a directed graph of nodes. It takes a certain amount of time to process the vector. During that time, packets accumulate on the RX ring. As the vector size N grows, the fixed costs of visiting a graph dispatch function are amortized over a larger number of packets. The first packet in the vector warms up the I-cache, and all the rest of the packets profit from it. And so on. Imagine an external event which increases the while(1) loop time by a certain amount. The vector size increases. The computation runs more efficiently, and the vector size will return to the previous equilibrium value. Thanks... Dave From: [email protected] [mailto:[email protected]] On Behalf Of Mli Sent: Tuesday, December 6, 2016 1:49 PM To: [email protected] Subject: [vpp-dev] vpp consistent per-packet latency Based on VPP doc., the vector size (i.e. workload) for each node needs be adjusted dynamically for the consistent per-packet latency. Can someone point to me where are the codes or funcs. which change the vector size for consistent per-packet latency? When we implement a new node, do we need to call these codes/funcs ? Thx Ming
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
