Hey, I can provide insight into the NAT bit.
On 17 Mar 2022, at 06:06, Yueyang Pan via lists.fd.io<http://lists.fd.io> <yueyang.pan=epfl...@lists.fd.io<mailto:yueyang.pan=epfl...@lists.fd.io>> wrote: Also I noticed size of handoff queue is very much important to the performance of NAT44 but I was wondering why the congestion drop in NAT handoff would increase after the handoff queue size (NAT_FQ_NELTS) is larger than a certain value (in my case 512). Does anyone also experience this case and have any ideas? Handoff queue size is in frames, so a size of 64 can hold up to 64*256 packets, but there is rarely a full frame there, because these frames are the result of an incoming frame being split in between workers. Say you have 2 workers and a full frame of 256 packets hits worker #1, which sifts through the packets and decides that 156 packets are for #1 and 100 are for #2. So in this case, 156 packets continue processing on worker #1 and there is a new frame created with 100 packets and put into a queue to be processed on worker #2. If you are hitting congestion drop it means your system is very close to or simply cannot handle such packet rates. Increasing frame queue size might help with some slight invariances, but ultimately makes the situation worse as packets begin to pile up within vpp waiting to be process. If you continued increasing this size, eventually you’d hit a situation where NIC driver would have problems allocating new vlib_buffers, because all buffers would be stuck in queues waiting. Regards, Klement
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21047): https://lists.fd.io/g/vpp-dev/message/21047 Mute This Topic: https://lists.fd.io/mt/89839411/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
