Hi Ole,
Thanks for the clarification, that makes more sense.
So the RX core is essentially doing LB across worker cores, not that
dis-similar to the RSS.
I think this work will end up being useful outside of NAT, you can
imagine this pattern being useful in a number of scenarios.
Ray K
On 02/10/2017 12:48, Ole Troan wrote:
Ray,
I gave the code a quick read through - as this is question I get all the time
about VPP.
So can I assign different worker threads to 'In' and 'Out' interfaces.
The NAT'ing plugin is breaking up the In/Out pipelines,
doing the NAT'ing itself on a given worker, and then the routing on another
worker thread?
Not quite.
The NAT code distributes the "state space" by the configured <n> workers.
Each worker owns a part of the NAT session space (which are bidirectional
flows).
An RX worker / IO thread, does a calculation on the incoming packet and hands
it off to the worker that owns that particular state (or will own it, if not
created yet). That worker will then continue processing the packet through the
rest of the graph, including TX.
Matus is doing quite a bit of performance work on NAT now, and we'll see if this is the
most efficient way of doing it. E.g. we might not want to mix features which would split
the "state" space differently and hand over yet again to another worker. Which
might be an argument for a general connection tracker. Very much open for comments here.
Best regards,
Ole
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
