diff options
Diffstat (limited to 'docs/configuration/interfaces')
| -rw-r--r-- | docs/configuration/interfaces/ethernet.rst | 42 | 
1 files changed, 28 insertions, 14 deletions
| diff --git a/docs/configuration/interfaces/ethernet.rst b/docs/configuration/interfaces/ethernet.rst index d7bc8518..1d99019c 100644 --- a/docs/configuration/interfaces/ethernet.rst +++ b/docs/configuration/interfaces/ethernet.rst @@ -69,28 +69,42 @@ Ethernet options  Offloading  ---------- -.. cfgcmd:: set interfaces ethernet <interface> offload <gro | gso | sg | -  tso | ufo> +.. cfgcmd:: set interfaces ethernet <interface> offload <gro | gso | sg | tso | +  ufo | rps>    Enable different types of hardware offloading on the given NIC. -  Generic segmentation offload is a pure software offload that is meant to deal -  with cases where device drivers cannot perform the offloads described above. -  What occurs in GSO is that a given skbuff will have its data broken out over -  multiple skbuffs that have been resized to match the MSS provided via -  skb_shinfo()->gso_size. +  :abbr:`GSO (Generic Segmentation Offload)` is a pure software offload that is +  meant to deal with cases where device drivers cannot perform the offloads +  described above. What occurs in GSO is that a given skbuff will have its data +  broken out over multiple skbuffs that have been resized to match the MSS +  provided via skb_shinfo()->gso_size.    Before enabling any hardware segmentation offload a corresponding software    offload is required in GSO. Otherwise it becomes possible for a frame to be    re-routed between devices and end up being unable to be transmitted. -  Generic receive offload is the complement to GSO. Ideally any frame assembled -  by GRO should be segmented to create an identical sequence of frames using -  GSO, and any sequence of frames segmented by GSO should be able to be -  reassembled back to the original by GRO. The only exception to this is IPv4 -  ID in the case that the DF bit is set for a given IP header. If the value of -  the IPv4 ID is not sequentially incrementing it will be altered so that it is -  when a frame assembled via GRO is segmented via GSO. +  :abbr:`GRO (Generic receive offload)` is the complement to GSO. Ideally any +  frame assembled by GRO should be segmented to create an identical sequence of +  frames using GSO, and any sequence of frames segmented by GSO should be able +  to be reassembled back to the original by GRO. The only exception to this is +  IPv4 ID in the case that the DF bit is set for a given IP header. If the +  value of the IPv4 ID is not sequentially incrementing it will be altered so +  that it is when a frame assembled via GRO is segmented via GSO. + +  :abbr:`RPS (Receive Packet Steering)` is logically a software implementation +  of :abbr:`RSS (Receive Side Scaling)`. Being in software, it is necessarily +  called later in the datapath. Whereas RSS selects the queue and hence CPU that +  will run the hardware interrupt handler, RPS selects the CPU to perform +  protocol processing above the interrupt handler. This is accomplished by +  placing the packet on the desired CPU's backlog queue and waking up the CPU +  for processing. RPS has some advantages over RSS: + +  - it can be used with any NIC, +  - software filters can easily be added to hash over new protocols, +  - it does not increase hardware device interrupt rate (although it does +    introduce inter-processor interrupts (IPIs)). +  .. cmdinclude:: /_include/interface-xdp.txt     :var0: ethernet | 
