Linux tso gro gso

Segmentation Offloads¶

Introduction¶

This document describes a set of techniques in the Linux networking stack to take advantage of segmentation offload capabilities of various NICs.

The following technologies are described:

TCP Segmentation Offload — TSO

UDP Fragmentation Offload — UFO

IPIP, SIT, GRE, and UDP Tunnel Offloads

Generic Segmentation Offload — GSO

Generic Receive Offload — GRO

Partial Generic Segmentation Offload — GSO_PARTIAL

SCTP acceleration with GSO — GSO_BY_FRAGS

TCP Segmentation Offload¶

TCP segmentation allows a device to segment a single frame into multiple frames with a data payload size specified in skb_shinfo()->gso_size. When TCP segmentation requested the bit for either SKB_GSO_TCPV4 or SKB_GSO_TCPV6 should be set in skb_shinfo()->gso_type and skb_shinfo()->gso_size should be set to a non-zero value.

TCP segmentation is dependent on support for the use of partial checksum offload. For this reason TSO is normally disabled if the Tx checksum offload for a given device is disabled.

In order to support TCP segmentation offload it is necessary to populate the network and transport header offsets of the skbuff so that the device drivers will be able determine the offsets of the IP or IPv6 header and the TCP header. In addition as CHECKSUM_PARTIAL is required csum_start should also point to the TCP header of the packet.

For IPv4 segmentation we support one of two types in terms of the IP ID. The default behavior is to increment the IP ID with every segment. If the GSO type SKB_GSO_TCP_FIXEDID is specified then we will not increment the IP ID and all segments will use the same IP ID. If a device has NETIF_F_TSO_MANGLEID set then the IP ID can be ignored when performing TSO and we will either increment the IP ID for all frames, or leave it at a static value based on driver preference.

UDP Fragmentation Offload¶

UDP fragmentation offload allows a device to fragment an oversized UDP datagram into multiple IPv4 fragments. Many of the requirements for UDP fragmentation offload are the same as TSO. However the IPv4 ID for fragments should not increment as a single IPv4 datagram is fragmented.

UFO is deprecated: modern kernels will no longer generate UFO skbs, but can still receive them from tuntap and similar devices. Offload of UDP-based tunnel protocols is still supported.

IPIP, SIT, GRE, UDP Tunnel, and Remote Checksum Offloads¶

In addition to the offloads described above it is possible for a frame to contain additional headers such as an outer tunnel. In order to account for such instances an additional set of segmentation offload types were introduced including SKB_GSO_IPXIP4, SKB_GSO_IPXIP6, SKB_GSO_GRE, and SKB_GSO_UDP_TUNNEL. These extra segmentation types are used to identify cases where there are more than just 1 set of headers. For example in the case of IPIP and SIT we should have the network and transport headers moved from the standard list of headers to “inner” header offsets.

Currently only two levels of headers are supported. The convention is to refer to the tunnel headers as the outer headers, while the encapsulated data is normally referred to as the inner headers. Below is the list of calls to access the given headers:

In addition to the above tunnel types there are also SKB_GSO_GRE_CSUM and SKB_GSO_UDP_TUNNEL_CSUM. These two additional tunnel types reflect the fact that the outer header also requests to have a non-zero checksum included in the outer header.

Finally there is SKB_GSO_TUNNEL_REMCSUM which indicates that a given tunnel header has requested a remote checksum offload. In this case the inner headers will be left with a partial checksum and only the outer header checksum will be computed.

Generic Segmentation Offload¶

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¶

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.

Partial Generic Segmentation Offload¶

Partial generic segmentation offload is a hybrid between TSO and GSO. What it effectively does is take advantage of certain traits of TCP and tunnels so that instead of having to rewrite the packet headers for each segment only the inner-most transport header and possibly the outer-most network header need to be updated. This allows devices that do not support tunnel offloads or tunnel offloads with checksum to still make use of segmentation.

With the partial offload what occurs is that all headers excluding the inner transport header are updated such that they will contain the correct values for if the header was simply duplicated. The one exception to this is the outer IPv4 ID field. It is up to the device drivers to guarantee that the IPv4 ID field is incremented in the case that a given header does not have the DF bit set.

SCTP acceleration with GSO¶

SCTP — despite the lack of hardware support — can still take advantage of GSO to pass one large packet through the network stack, rather than multiple small packets.

This requires a different approach to other offloads, as SCTP packets cannot be just segmented to (P)MTU. Rather, the chunks must be contained in IP segments, padding respected. So unlike regular GSO, SCTP can’t just generate a big skb, set gso_size to the fragmentation point and deliver it to IP layer.

Instead, the SCTP protocol layer builds an skb with the segments correctly padded and stored as chained skbs, and skb_segment() splits based on those. To signal this, gso_size is set to the special value GSO_BY_FRAGS.

Therefore, any code in the core networking stack must be aware of the possibility that gso_size will be GSO_BY_FRAGS and handle that case appropriately.

There are some helpers to make this easier:

skb_is_gso(skb) && skb_is_gso_sctp(skb) is the best way to see if an skb is an SCTP GSO skb.

For size checks, the skb_gso_validate_*_len family of helpers correctly considers GSO_BY_FRAGS.

For manipulating packets, skb_increase_gso_size and skb_decrease_gso_size will check for GSO_BY_FRAGS and WARN if asked to manipulate these skbs.

This also affects drivers with the NETIF_F_FRAGLIST & NETIF_F_GSO_SCTP bits set. Note also that NETIF_F_GSO_SCTP is included in NETIF_F_GSO_SOFTWARE.

© Copyright The kernel development community.

Источник

table of Contents

Article catalog

Network function uninstall

In order to adapt to the high-speed network, the processing logic of the partial L3-L4 layer is generally unloaded in the modern network card (E.G. Check and calculation, transport layer fragment restructuring, etc.) to reduce the processing burden of the Host CPU. Even some NIC (E.G. RDMA NIC) also uninstall the processing of the entire L4 layer to the hardware to completely liberate the Host CPU. Thanks to these hardware unloading techniques, the Host OS network protocol stack processing can match the existing high-speed network.

TSO（TCP Segmentation Offload）

TSO（TCP Segmentation Offload）: It is a technique for fragmentation of large packets using NIC to reduce CPU load.

TSO OFF and GSO OFF:

TSO on：

GSO（Generic Segmentation Offload）

GSO（Generic Segmentation Offload）: It is a delay in fragmentation technology. It is more common than TSO because it does not require hardware support.

The process is: first check if the network card supports the TSO function. If the hardware supports TSO, the hardware slice capability of the network card is used to perform fragmentation; if the network card does not support TSO function, the execution of the fragmentation is delayed to the network card. Performed before.

• TSO OFF AND GSO ON: A large network package is separated from the last step before entering the NIC.

LRO（Large Receive Offload）

LRO（Large Receive Offload）: Combine multiple data packets received by the NIC into a large packet and then passed to the technology of network protocol stack processing. This allows the system to receive the capabilities of the packet and mitigate the CPU load.

LRO off and GRO off

Lro ON: The data is incorporated into the network card immediately.

GRO （Generic Receive Offload）

GRO （Generic Receive Offload）: It is the soft implementation of LRO, and the merger of GRO is more stringent and flexible.

• GRO on
  

Источник

роутер с включенным tso/sgo/gro = ?

После апгрейда ядра до 3.4.97 получил пики +300Мбит входящего трафика. Сетевушка — intel-82574L.

Расследование показало, что удвоение трафика связано с безумным числом ICMP DEST_UNREACH/FRAG_NEEDED на входящие пакеты более MTU (tcpdump показывает входящие tcp пакеты до 12кб (при MTU 1500)) т.е. правая рука не знает, что делает левая рука ?

отключение tso/sgo/gro убрало поток icmp.

т.е. получается, что эти фичи полезны только хостам ?

т.е. правая рука не знает, что делает левая рука ?

Дак tcpdump ведь показывает пакеты после драйвера сетёвки, а именно там и происходит объединение пакетов в большой при GSO и пр.

Не знаю, возможно это полезно ещё в случае маршрутизатора между обычным ethernet и Jumbo-frame.

Проблема то в том, что они приходят с DF(?), а дальше MTU 1500 и в ответ отсылается ICMP FRAG_NEEDED.

Cудя по изменениям в ядре, кто-то недавно исправлял ошибку с локальной обработкой DF, похоже что-то не учли.

Я пока не понял — сменить TSO/GSO/GRO на ходу без down/up интерфейса нельзя?

Не знаю, насчёт того, что сделали в ядре. Но в общем случае, дальше MTU 1500, а ещё дальше может быть ещё меньше. Клиент с удалённым сервером в интернете изначально может согласовать правильный MSS, а маршрутизатор с TSO, даже если изначально фрагментирует полученный после TSO по 1500 байт, всё одно получит ICMP FRAG_NEEDED и никакой выгоды от TSO не будет.

Раньше, вроде как, по умолчению это TSO/GSO/GRO было отключено, может по этому у вас проблем и не было.

Проблема в том, что сетевушка сама собрала из фрагментов большой пакет и потом им подавилась 🙂

Если на собранном пакете есть флаг DF — значит это баг. Хорошо, если это баг в ядре, а не в сетевушке!

Источник

Настройка сети в Linux

Рассмотрим настройку сети в Linux Ubuntu.

Приведу пример команд просмотра информации о сетевых интерфейсах:

Пример включения/отключения сетевых интерфейсов:

Если имя сетевого интерфейса неизвестно, то смотрим его в logical name набрав команду:

Чтобы единоразово запросить IP адрес по DHCP выполним команду:

Ручное назначение настроек (сбрасываются после перезагрузки):

Удалить все IP с интерфейса eth0 можно так:

Чтобы настройки не сбрасывались их необходимо прописать в конфигурационный файл:

Приведу пример содержания:

В редакторе nano комбинация клавиш Ctrl+O служит для сохранения изменений, Ctrl+X для выхода.

Замечу что в новых версиях Linux сеть настраивается через Netplan.

DNS адреса добавляются в конфигурационный файл /etc/resolv.conf и директорию /etc/resolvconf/, каждый с новой строки, таким образом:

Посмотреть/добавить/удалить маршрут по умолчанию можно так:

Посмотреть таблицу маршрутизации так:

Просмотр IPv6 маршрутов:

Пример добавления маршрутов для сети через шлюз, сетевой интерфейс и маршрут для конкретного адреса через шлюз:

Например с указанным маршрутом можно удалять пакеты:

Можно добавить маршруты в отдельную таблицу, например мы добавим маршрут по умолчанию всем, а адресу 192.168.5.12 указали свой маршрут по умолчанию:

Перезапуск сетевых служб:

Либо перезапуск сервера:

В случае потерь пакетов при большом трафике или если неправильно работает шейпер, то можно попробовать отключить offload:

Посмотрим какие offload активированы, например generic-segmentation-offload — это сокращено «gso»:

Посмотреть правильно ли распределены прерывания сетевой платы по ядрам процессора можно командой:

Пример просмотра ARP таблицы (-d для удаления записи):

Источник

Русские Блоги

Понимание сетевого стека Linux (3): технология разгрузки сегментации (передающая сторона) в среде QEMU / KVM + VxLAN .

В этой серии статей описывается сетевой стек Linux, в том числе:

(4) Технология разгрузки сегментации в среде QEMU / KVM + VxLAN (принимающая сторона)

1. Тестовая среда

1.1 Общая среда

• Хост-машина: Ubuntu Linux / KVM + VxLAN + Linux bridge, сетевая карта MTU 9000
• Клиент: Ubuntu Linux + Virtio-net NIC, сетевая карта MTU 1500, использование OpenStack Kilo для управления виртуальными машинами

(Это схематическая диаграмма отправляющего хоста и клиента)

На передающей стороне виртуальная машина хочет отправить пакет данных. Она должна сначала отправить пакет на определенный Linux-мост хоста через устройство virtio, а затем мост пересылает его на виртуальную сетевую карту xvlan. Виртуальная сетевая карта превращает его в кадр UDP VxLAN. , А затем отправляется на уровень UDP, а затем снова маршрутизируется через уровень TCP / IP.На этот раз пакет данных будет отправлен в физическую сеть и, наконец, достигнет принимающей стороны.

1.2 Виртуальная сетевая карта virtio-net, используемая в клиенте

Паравиртуализированная сетевая карта virtio-net клиента на самом деле представляет собой устройство PCI, реализованное с использованием технологии прерывания и DMA, поэтому вы можете использовать команду lspci для просмотра информации о ней:

По умолчанию функция Segmentation Offloading для этой сетевой карты включена:

2. Эксперимент и реализация отправителя

2.1 Эксперимент

2.1.1 Эксперименты, когда включены GSO / TSO / UFO сетевых карт клиента и хоста

(1) MSS iperf составляет 1448 байт.

Эксперименты показывают, что TCP MSS в клиенте связан только с MTU сетевой карты клиента и не имеет ничего общего с другими факторами, такими как MTU сетевой карты хоста. Более того, MSS в двух направлениях TCP-соединения может быть разным. Именно из-за независимости MSS это может иметь разные последствия, которые будут объяснены ниже.

Еще один интересный результат заключается в том, что размер MTU сетевой карты клиента мало влияет на производительность сети. В следующем тесте MTU клиентской сетевой карты увеличен с 1500 до 8000, а производительность улучшилась только на 6,8%.

(2) Сетевая карта клиента: размер кадра, очевидно, превышает MSS, что указывает на то, что при включении GSO / TSO, пока каждый пакет данных не превышает максимальный размер IP-пакета, равный 64 КБ, сетевая карта virtio-net может быть отправлена ​​напрямую через virtqueue Отдать бэкенд в QEMU. Ошибка в контрольном коде указывает на то, что расчет контрольной суммы был выгружен на сетевую карту, но расчет сетевой карты может быть неправильным.

(3) Ответвительное устройство, соответствующее клиентской сетевой карте на хосте: то же, что и на клиентской сетевой карте, что указывает на то, что virtio-queue (backend) в QEMU и ответвительное сетевое устройство на хосте отправляют эти пакеты напрямую. , Никаких субподрядных и иных операций не выполнял.

(4) Мост linux, соединяющий устройство ответвления и интерфейс vxlan на хосте: размер кадра превышает его MTU, что указывает на то, что он напрямую пересылает объединенный кадр после GSO / TSO.

(5) vxlan-interface в хосте: размер кадра превышает его MTU, что указывает на то, что он напрямую пересылает объединенный кадр после GSO / TSO.

(6) Физическая сетевая карта, привязанная к UDP-сокету хоста VxLAN. Были протестированы три случая, и было доказано, что сетевая карта была фрагментирована по IP согласно MSS.

2.1.2 Закройте GSO / TSO / UFO на клиенте

Этот процесс показывает, что сегментация TCP генерируется в клиенте, что имеет некоторое снижение производительности сети.

2.1.3 TSO / GSO виртуальной машины включен, а GSO / TSO хоста выключен

Этот процесс показывает, что здесь генерируется фрагментация UDP / IP.

2.1.4 Сравнение производительности передачи TCP

И клиент, и хост GSO / TSO / UFO включены> клиент включен, а хост выключен> клиент выключен.

2.2 Ядро Linux поддерживает GSO для туннелей UDP: «udp: Generalize GSO for UDP Tunnels»

Эта поддержка была добавлена ​​в ядро ​​Linux в 2014 году, дополнительную информацию см. В исходном тексте.https://lwn.net/Articles/613999/. Этот патч добавляет поддержку технологии туннелей UDP в GSO.

• Вам необходимо добавить новую опцию: inner_protocol, прежде чем skb будет отправлен в стек протокола UDP. Вы можете использовать метод skb_set_inner_ipproto или skb_set_inner_protocol, чтобы установить его. Соответствующий код в драйвере vxlan: skb_set_inner_protocol(skb, htons(ETH_P_TEB));
• функция
• Поддержка нескольких типов инкапсуляции, включая SKB_GSO_UDP_TUNNEL

2.3 Реализация VxLAN

2.3.1 VxLAN interface

Как и название, интерфейс VxLAN также используется в качестве интерфейса сетевого устройства, а логика его драйвера реализована в файле vxlan.c. Он находится на уровне драйвера устройства уровня канала данных и реализует драйвер устройства интерфейса vxlan. Интерфейс vxlan также может использовать ethtool для просмотра возможностей разгрузки сегментации:

Его драйвер установлен Переменная структуры net_device_ops определяет важные функции для работы net_device.Vxlan заполняет эти функции в драйвере в соответствии с требуемыми операциями, среди которых функции обработки пакетов и приема.

Взглянем на реализацию кода:

(1) Первый взгляд static netdev_tx_t vxlan_xmit( struct sk_buff *skb, struct net_device * dev), его входом является sk_buff, соответствующий передаваемым пакетам и передаваемому интерфейсу vxlan dev:

Его основная логика — получить vxlan dev, а затем вызвать для каждого skb в sk_buff vxlan_xmit_skb метод.

(2) Функция vxlan_xmit_skb изменяет skb, добавляет заголовок VxLAN и устанавливает параметры GSO.

(3) Затем войдите в стек протоколов TCP / IP Linux, войдите из UDP, а затем на уровень IP. Если оборудование поддерживает это, оно вызывает функцию UDP GSO в ядре Linux; если оборудование не поддерживает ее, ядро ​​Linux вызывает функцию фрагментации UDP GSO перед входом в очередь драйверов устройства. Затем вплоть до сетевой карты.

Наконец, в этой функции ip_finish_output_gso сначала вызовите функцию сегментации GSO, а затем при необходимости выполните сегментацию IP:

Это функция обратного вызова gso, зарегистрированная на уровне UDP:

Его реализация здесь:

Более сомнительным является то, что VXLAN не определяет функцию обратного вызова gso_segment, что приводит к возможности отсутствия полного заголовка VXLAN в сегменте UDP GSO. . Это требует дальнейших исследований. Причина может заключаться в том, что во внутреннем сегменте сегментация заключается в сегментировании кадра уровня 2, инкапсулированного UDP в качестве полезной нагрузки, поэтому заголовок VXLAN останется в каждом сегменте.

(4) Видно, что во всем процессе на клиенте есть настройки на уровне протокола TCP.skb_shinfo(skb)->gso_sizeОн всегда остается таким же, как MSS.Поэтому окончательная фрагментация GSO для дейтаграмм UDP GSO, сделанных в сетевой карте, основана на длине фрагмента в соответствии со значением skb_shinfo (skb) -> gso_size, что является TCP MSS.

3. Проблемы и методы улучшения существующих решений у отправителя

3.1 Проблема

Как видно из процесса, описанного выше, в текущем протоколе и реализации VXLAN есть проблема, а именно: фрагментация IP, выполняемая на хосте, основана на MSS TCP-соединения в клиенте, но фактическая В сетевой среде MTU сетевой карты хоста часто устанавливается равным 9000 байтов с использованием технологии jumbo frame, в то время как MTU клиентской сетевой карты часто устанавливается равным 1500 байтам по умолчанию. Когда принимающая сторона также является узлом того же типа, текущая фрагментация Это огромная трата ресурсов.

Есть несколько идеальных ситуаций:

• (1) Если принимающей стороной является тот же узел, который использует VXLAN VETP, IP-фрагментация должна выполняться в соответствии с MTU физической сетевой карты. После того, как реорганизация IP-фрагментации выполнена на противоположном конце, VXLAN VTEP напрямую доставляет виртуальную машину.
• (2) Если другая сторона является узлом шлюза VXLAN, который будет подключен к внешней сети, после того, как VXLAN VTEP противоположной стороны получит большой сетевой пакет после фрагментации и реорганизации IP, он разделяет большой пакет самостоятельно или с помощью технологии разгрузки сегментации стека сетевых протоколов Linux. Фильм, а потом переадресовал во внешнюю сеть.
• (3) Если другая сторона является обычным сетевым узлом (в настоящее время отправителем является узел шлюза VXLAN), используйте текущий режим, используйте фрагментацию UDP / IP в соответствии с TCP MSS, а затем отправьте его.

3.2 Схема реализации

СтатьяSegmentation Offloading Extension for VXLANПредложена схема реализации VXLAN Segmentation Offloading Extension (VXLAN-soe). Это решение расширяет заголовок VXLAN и добавляет несколько новых битов флага: (бит S-флага, использовать ли эту технологию; Overlay MSS Hi и Lo: для TCP это MSS; для UDP это MTU)

Отправитель VXLAN VTEP в соответствии с конфигурацией или другими условиями

• Установите S = 1, что означает разгрузку сегментации для VXLAN VTEP на противоположном узле, и установите Overlay MSS Hi и Lo.
• Установите S = 0, что означает, что выгрузка удаленной сегментации не будет выполняться, а будет выполняться обычная обработка.

Принимающая сторона VXLAN Hypervisor VTEP проверит флаг S:

• Если он равен 1, проверка MTU не выполняется, и пакет доставляется напрямую на виртуальную машину.
• Бит флага S, если он равен 0, следуйте нормальному потоку обработки

Приемник VXLAN Gateway VTEP:

• Проверьте флаг S, если он равен 1, тогда он может использовать технологию разгрузки сегментации для сегментации.

Проблема с этим решением заключается в том, что при S = ​​1 произойдет фрагментация UDP / IP.

Источник