Поделиться через

UDP Receive Segment Coalescing Offload (URO)

  • Статья

Начиная с Windows 11 версии 24H2, UDP Receive Segment Coalescing Offload (URO) позволяет сетевому интерфейсу карта (СЕТЕВЫе адаптеры) объединения сегментов получения UDP. Сетевые адаптеры могут объединять диаграммы данных UDP из одного потока, который соответствует набору правил в логически смежный буфер. Затем эти объединенные диаграммы данных указываются в сетевом стеке Windows в виде одного большого пакета.

Объединение диаграмм данных UDP снижает затраты ЦП на обработку пакетов в потоках высокой пропускной способности, что приводит к повышению пропускной способности и меньшему объему циклов на байт.

В следующих разделах описаны правила объединения пакетов UDP и записи мини-порта URO.

Правила объединения пакетов UDP

Объединение URI может выполняться только на пакетах, которые соответствуют всем следующим критериям:

  • IpHeader.Version идентичен для всех пакетов.
  • IpHeader.SourceAddress и IpHeader.DestinationAddress идентичны для всех пакетов.
  • UdpHeader.SourcePort и UdpHeader.DestinationPort идентичны для всех пакетов.
  • UdpHeader.Length идентичен для всех пакетов, за исключением последнего пакета, который может быть меньше.
  • UdpHeader.Length должен быть ненулевой.
  • UdpHeader.Checksum, если ненулевая, должна быть правильной для всех пакетов. Это означает, что разгрузка проверка sum должна проверить пакет.
  • Заголовки уровня 2 должны быть одинаковыми для всех пакетов.

Если пакеты являются IPv4, они также должны соответствовать следующим критериям:

  • IPv4Header.Protocol == 17 (UDP) для всех пакетов.
  • EthernetHeader.EtherType == 0x0800 для всех пакетов.
  • IPv4Header.HeaderChecksum для полученных пакетов должен быть правильным. Это означает, что загрузка проверка sum должна проверить заголовок.
  • IPv4Header.HeaderLength == 5 (без заголовков параметров IPv4) для всех пакетов.
  • IPv4Header.ToS идентичен для всех пакетов.
  • IPv4Header.ECN идентичен для всех пакетов.
  • IPv4Header.DontFragment идентичен для всех пакетов.
  • Протокол IPv4Header.TTL идентичен для всех пакетов.
  • IPv4Header.TotalLength == UdpHeader.Length + length(IPv4Header) для всех пакетов.

Если пакеты являются IPv6, они также должны соответствовать следующим критериям:

  • IPv6Header.NextHeader == 17 (UDP) для всех пакетов (без заголовков расширений).
  • EthernetHeader.EtherType == 0x86dd (IPv6) для всех пакетов.
  • IPv6Header.TrafficClass и IPv6Header.ECN идентичны для всех пакетов.
  • IPv6Header.FlowLabel идентичен для всех пакетов.
  • IPv6Header.HopLimit идентичен для всех пакетов.
  • IPv6Header.PayloadLength == UdpHeader.Length для всех пакетов.

Структура пакетов URI

Результирующая единица единого объединения (SCU) должна иметь один заголовок IP и заголовок UDP, а затем полезные данные UDP для всех объединенных диаграмм данных.

Указания URI должны задать для поля IPv4Header.TotalLength общую длину SCU или IPv6Header.PayloadLength в длину полезных данных UDP и UdpHeader.Length длиной объединенных полезных данных.

Если заголовки уровня 2 (L2) присутствуют в объединенных диаграммах данных, SCU должен содержать допустимый заголовок L2. Заголовок L2 в SCU должен напоминать заголовок L2 объединенных диаграмм данных.

Проверка и указание контрольной суммы

Признаки URI должны задать для полей IPv4Header.HeaderChecksum и UdpHeader.Checker.Checkum значение нулю и заполнить сведения об отключении проверка sum для SCU, указывающих на успешность IPv4 и UDP проверка sum.

Пакет, соответствующий всем условиям объединения, но не выполняет проверку проверка sum, должен быть указан отдельно. Пакеты, полученные после его объединения, не должны быть объединены с пакетами, полученными до него.

Например, предположим, что пакеты 1, 2, 3, 4 и 5 получаются из одного потока, но пакет 3 завершается ошибкой проверки проверка суммы. Пакеты 1 и 2 можно объединить вместе, а пакеты 4 и 5 можно объединить вместе, но пакет 3 не должен быть объединен с помощью SCU. Пакеты 1 и 2 не должны объединяться вместе с пакетами 4 и 5. Пакет 2 — это последний пакет в SCU, а пакет 4 запускает новый SCU. Кроме того, необходимо указать SCU, содержащий пакеты 1 и 2, прежде чем указан пакет 3, и перед SCU, содержащим пакеты 4 и 5, необходимо указать пакет 3.

Объединение пакетов и разделение потоков

Пакеты из нескольких потоков могут быть объединяться параллельно, как аппаратное и память разрешения. Пакеты из разных потоков не должны объединяться друг с другом.

Пакеты из нескольких приемов могут быть разделены и объединены с соответствующими потоками. Например, при выполнении потоков A, B и C, если пакеты прибывают в порядке A, A, B, A, пакеты из потока A могут быть объединяются в AAA, а пакеты из потока B объединяются в BB, а пакет из потока C может быть указан обычно или объединяется с ожидающей SCU из потока C.

Пакеты в заданном потоке не должны быть переупорядочены относительно друг друга. Например, пакеты из потока A должны быть объединяются в порядке, полученном независимо от пакетов из потоков B и C, полученных между ними.

INF ключевое слово для управления URI

Следующие ключевое слово можно использовать для включения и отключения URI с параметром раздела реестра.

*UdpRsc

Перечисление стандартных INF-ключевое слово имеет следующие атрибуты:

SubkeyName
Имя ключевое слово, которое необходимо указать в INF-файле и которое отображается в реестре.

ParamDesc
Отображаемый текст, связанный с SubkeyName.

Значение
Целочисленное значение перечисления, связанное с каждым параметром в списке. Это значение хранится в значении NDI\params\ SubkeyName\.

EnumDesc
Отображаемый текст, связанный с каждым значением, отображаемым в меню.

По умолчанию.
Значение по умолчанию для меню.

SubkeyName ParamDesc Значение EnumDesc
*UdpRsc УРО 0 Выключено
1 (по умолчанию) Включен

Дополнительные сведения об использовании ключевое слово перечисления см. в разделе "Ключевые слова перечисления".

Создание минипорта URO

Начиная с версии NDIS 6.89 интерфейс NDIS для URO упрощает обмен данными между TCP/IP и мини-драйвером NDIS.

Возможность URI отчета

Минипорт драйвер объявляет URI в члене UdpRsc структуры NDIS_OFFLOAD, которую он передает в функцию NdisMSetMiniportAttributes.

Возможность запроса URI

Чтобы проверка, если минипорт-драйвер поддерживает URO, драйверы NDIS и другие приложения могут запрашивать OID_TCP_OFFLOAD_HARDWARE_CAPABILITIES OID, который возвращает структуру NDIS_OFFLOAD.

Состояние URI запроса

Чтобы определить текущее состояние URI, драйверы NDIS и другие приложения могут запрашивать запрос OID_TCP_OFFLOAD_CURRENT_CONFIG OID. NDIS обрабатывает этот OID и не передает его в мини-порт.

Изменение состояния URI

URI можно включить или отключить, отправив запрос OID_TCP_OFFLOAD_PARAMETERS OID. Этот OID использует структуру NDIS_OFFLOAD_PARAMETERS . В этой структуре член UdpRsc.Enabled может иметь следующие значения:

Значение Значение
NDIS_OFFLOAD_PARAMETERS_UDP_RSC_NO_CHANGE
0		 Драйвер минипорта не должен изменять текущий параметр.
NDIS_OFFLOAD_PARAMETERS_UDP_RSC_DISABLED
1		 URI отключен.
NDIS_OFFLOAD_PARAMETERS_UDP_RSC_ENABLED
2		 URI включен.

Когда драйвер обрабатывает запрос OID_TCP_OFFLOAD_PARAMETERS OID с NDIS_OFFLOAD_PARAMETERS_UDP_RSC_DISABLED набором флагов, сетевой адаптер должен ждать завершения запроса до тех пор, пока не будут указаны все существующие объединенные сегменты и выдающиеся признаки URI. Это обеспечивает синхронизацию событий включения и отключения URI между компонентами NDIS.

После обработки запроса OID_TCP_OFFLOAD_PARAMETERS OID драйвер минипорта должен выдать указание состояния NDIS_STATUS_TASK_OFFLOAD_CURRENT_CONFIG с обновленным состоянием разгрузки.

Флаг NDIS_OFFLOAD_PARAMETERS_SKIP_REGISTRY_UPDATE в NDIS_OFFLOAD_PARAMETERS позволяет отключить URI только для среды выполнения. Изменения, внесенные с этим флагом, не сохраняются в реестре.

Отказ от URI в NDIS 6.89 и более поздних версий

Драйверы, предназначенные для NDIS 6.89 и более поздних версий, должны понимать пакеты URO и обрабатывать их корректно. Чтобы отказаться от URI, выполните приведенные действия.

Этот подход гарантирует, что компоненты, не знакомые с URI, не получают NBL URO. NDIS отключает URI в мини-порте во время привязки, если присутствует драйвер LWF или протокол, не поддерживающий URI.

Рекомендации по программированию драйверов URI

При реализации мини-порта, поддерживающего URI, рассмотрите следующие проблемы.

Winsock URO API

Сведения об API URI Winsock см. в разделе IPPROTO_UDP параметры сокета. См. сведения о UDP_RECV_MAX_COALESCED_SIZE и UDP_COALESCED_INFO.

Обновления стека TCP/IP Для Windows

Транспорт Microsoft TCP/IP включает URI во время привязки с NDIS, если только конфигурация не препятствует этому.

Выноски МПП могут использовать FWP_CALLOUT_FLAG_ALLOW_URO в FWPS_CALLOUT2 , чтобы объявить свою поддержку URO. Если несовместимый выносок МПП зарегистрирован на уровне с учетом URO, ос отключит URI во время регистрации выноски.

Если сокет выбирает URO с максимальным размером объединения больше или равен размеру аппаратной разгрузки, стек будет доставлять NBL из оборудования, не измененного в сокет. Если сокет выбирается на меньший максимальный размер объединения, стек разорвит объединенный прием в меньший размер сокета.

Если сокет не принимает участие в URI, стек будет повторно получать для этого сокета. В отсутствие аппаратного URI существующий компонент программного обеспечения URO будет по-прежнему доступен.