Content deleted Content added
No edit summary |
No edit summary |
||
Line 10:
=== RSS ===
[[File:RSS architecture.png|upright=1.7|thumb|
Receive Side Scaling (RSS) is an hardware supported technique, leveraging an [[indirection|indirection table]] indexed by the last bits of the result provided by an [[hash function]], taking as inputs the [[Header (computing)|header fields]] of the packets.
The hash function input is usually customizable and the header fields used can vary between use case and implementations.
Line 18:
=== aRFS ===
[[File:ARFS architecture.png|upright=1.7|thumb|
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. <br>
Line 29:
=== RPS ===
[[File:RPS logic.png|upright=1.7|thumb|
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.
Line 36:
=== RFS ===
[[File:RFS logic.png|upright=1.7|thumb|
Receive Flow Steering (RFS) upgrades RPS in the same direction as the aRFS hardware solution does.
By routing packet flows to the same CPU core running the consuming application, cache locality can be improved and leveraged, avoiding many misses and reducing the latencies introduced by the retrieval of the data from the [[Memory hierarchy|central memory]]. <br>
| |||