You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LRO refers to a host OS or NIC's ability to coalesce multiple packets together, with the aim of reducing the amount of packets processed per second (and delivering larger contiguous data segments to TCP stacks). This can apply to stream transports like TCP, or fragmented UDP reassembly (which is not really applicable on the current dataplane).
Part of the performance boost seen from #614 comes down to the fact that we are abusing the wider underlay MTU to achieve a form of send-side LRO. Fewer packets transit OPTE (eliding identical parse/decision cycles), and fewer packets are handed upstack to guests/zones.
We have some different options here:
Attempt optimistic LRO before processing by OPTE. This reduces the cost on packets crossing OPTE (only one parse/process/modify), but when flowstats come around we might need to take some care to prevent the packet_in numbers from surprising customers.
Attempt optimistic LRO after processing by OPTE. This has minimal impact on stats
In both cases, illumos zones behave well when served larger packets (i.e., NTP and Nexus zones today) and the setup work for #614 means that viona can always accept and split an oversize/receive-offloaded TCP packet, even if the guest cannot.
This will be blocked on having full packet chain Rx from mac (IPD45).
The text was updated successfully, but these errors were encountered:
FelixMcFelix
changed the title
xde: LRO
Want implementation of Large Receive Offload
Jan 23, 2025
LRO refers to a host OS or NIC's ability to coalesce multiple packets together, with the aim of reducing the amount of packets processed per second (and delivering larger contiguous data segments to TCP stacks). This can apply to stream transports like TCP, or fragmented UDP reassembly (which is not really applicable on the current dataplane).
Part of the performance boost seen from #614 comes down to the fact that we are abusing the wider underlay MTU to achieve a form of send-side LRO. Fewer packets transit OPTE (eliding identical parse/decision cycles), and fewer packets are handed upstack to guests/zones.
We have some different options here:
packet_in
numbers from surprising customers.In both cases, illumos zones behave well when served larger packets (i.e., NTP and Nexus zones today) and the setup work for #614 means that viona can always accept and split an oversize/receive-offloaded TCP packet, even if the guest cannot.
This will be blocked on having full packet chain Rx from
mac
(IPD45).The text was updated successfully, but these errors were encountered: