Content deleted Content added
finished aRFS explenation |
added RPS description |
||
Line 19:
=== RSS ===
[[File:RSS architecture.png|upright=1.7|thumb|simple view of the receive side scaling architecture]]
The hash function input is usually customizable and the header fields used can vary between use case and implementations.
Some notable example of header fields used are the [[Internet Protocol|layer 3 IP]] source and destination addresses, the protocol and the [[transport layer|layer 4]] source and destination port.
Line 31:
=== aRFS ===
[[File:ARFS architecture.png|upright=1.7|thumb|simple view of the accelerated receive flow steering architecture]]
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''. <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.
Line 39:
== 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 is achieved by leveraging [[Inter-processor interrupt|inter-processor interrupts (IPIs)]].<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|language=en-US}}</ref>
Line 47:
=== RPS ===
[[File:RPS logic.png|upright=1.7|thumb|diagram showing how RPS load balance incoming packets across the CPU cores]]
Receive Packet Steering (RPS) is the RSS parallel implemented in software. All packets received by the NIC are load balanced between the cores' queues by implementing an hash function using as configurable key the header fields (like the layer 3 source and destination IP and layer 4 source and destination ports), in the same fashion as RSS does.
Moreover thanks to the hash function, packets belonging to the same flow will always be steered to the same core.
This is usually done within the NIC driver, before the packets can be loaded in any of the receiving queues.
<ref name="RPS linux news (LWM)" />
<ref name="RPS by redhat" />
<ref>{{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|language=en-US}}</ref>
=== RFS ===
[[File:RFS logic.png|upright=1.7|thumb|diagram showing how the RFS logic distribute each incoming packet to the core running the corresponding application]]
<ref name="RFS by redhat" />
<ref name="RFS by nvidea" />
|