Multi-core network packet steering: Difference between revisions

Content deleted Content added
FrancioT (talk | contribs)
No edit summary
FrancioT (talk | contribs)
No edit summary
Line 22:
[[File:ARFS architecture.png|upright=1.7|thumb|Simple view of the accelerated receive flow steering architecture]]
Accelerated Receive Flow Steering (aRFS) is another hardware supported technique, born with the idea of leveraging [[Locality of reference|cache locality]] to improve performances by routing incoming packet flows to specific cores.
Differently from RSS which is a fully hardware independent implementation, aRFS needs to interface with the software (the [[Kernel (operating system)|kernel]]) to properly function.<ref>{{Cite web|title=aRFS kernel linux docs|url=https://www.kernel.org/doc/html/v5.1/networking/scaling.html#accelerated-rfs|access-date=2025-07-08|website=kernel.org|publisher=The Linux Kernel documentation|language=en-US}}</ref><br>
RSS simply load balance incoming traffic across the cores; however if a packet flow is directed to the ''core i'' (as a result of the hash function) while the application needing the received packet is running on ''core j'', many cache misses could be avoided by simply forcing ''i=j'', so that packets are received exactly where they are needed and consumed.<ref name="aRFS by nvidea" /><br>
To do this aRFS doesn't forward packets directly from the result of the hash function, but using a configurable routing table (which can be filled and updated for instance by the [[Scheduling (computing)|scheduler]] through an [[API]]) packet flows can be steered to the specific consuming core.<ref name="aRFS by nvidea" /><ref name="aRFS by redhat" /><ref>{{Cite web|title=aRFS kernel linux docs|url=https://www.kernel.org/doc/html/v5.1/networking/scaling.html#accelerated-rfs|access-date=2025-07-08|website=kernel.org|publisher=The Linux Kernel documentation|language=en-US}}</ref>
 
== Software techniques ==
Software techniques like RPS and RFS employ one of the CPU cores to steer incoming packets across the other cores of the processor. This comes at the cost of introducing additional [[Inter-processor interrupt|inter-processor interrupts (IPIs)]]; however the number of hardware interrupts will not increase and potentially, by employing an [[Interrupt coalescing|interrupt aggregation]] technique, it could even be reduced.<ref name="RPS kernel linux docs">{{Cite web|title=RPS kernel linux docs|url=https://www.kernel.org/doc/html/v5.1/networking/scaling.html#rps-receive-packet-steering|access-date=2025-07-08|website=kernel.org|publisher=The Linux Kernel documentation|language=en-US}}</ref><br>
The benefits of a software solutions is the ease in implementation, without having to change any component (like the [[Network_interface_controller|NIC]]) of the currently used architecture, but by simply deploying the proper [[Loadable kernel module|kernel module]]. This benefit can be crucial especially in cases where the server machine can't be customized or accessed (like in [[Cloud computing#Infrastructure as a service (IaaS)|cloud computing]] environment), even if the network performances could be reduced as compared the hardware supported ones.<ref name="RPS linux news (LWM)">{{Cite web|title=RPS linux news (LWM)|url=https://lwn.net/Articles/362339/|access-date=2025-07-08|website=lwn.net|publisher=Linux Weekly News|language=en-US}}</ref><ref name="RPS by redhat">{{Cite web|title=RPS by redhat|url=https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/performance_tuning_guide/network-rps|access-date=2025-07-08|website=docs.redhat.com|publisher=Red Hat Documentation|language=en-US}}</ref><ref name="RFS by nvidea" />
 
Line 35:
Moreover thanks to the hash properties, packets belonging to the same flow will always be steered to the same core. <br>
This is usually done in the kernel, right after the NIC driver. Having handled the network interrupt and before it can be processed, the packet is sent to the receiving queue of a core, which is then notified thanks to an inter process interrupt. <br>
RPS can be used in conjunction with RSS, in case the number of queues managed by the hardware is lower than the number of cores. In this case after having distributed across the RSS queues the incoming packets, a pool of cores can be assigned to each queue and RPS will be used to spread again the incoming flows across the specified pool.<ref name="RPS linux news (LWM)" /><ref name="RPS by redhat" /><ref>{{Cite web|titlename="RPS kernel linux docs|url=https://www.kernel.org/doc/html/v5.1/networking/scaling.html#rps-receive-packet-steering|access-date=2025-07-08|website=kernel.org|publisher=The" Linux Kernel documentation|language=en-US}}</ref>
 
=== RFS ===