Разгрузка сегментов объединения сегментов (RSC)

Статья
05/22/2024

При получении данных большинство слоев в стеке TCP/IP должны искать сведения о заголовках каждого сегмента отдельно. Это создает большую нагрузку при получении больших объемов данных.

объединения сегментов (RSC) снижает эту нагрузку, объединяя последовательность полученных сегментов и указывая на них стек TCP/IP в одном объединяемом сегменте. Верхние слои в стеке TCP/IP должны рассматривать только один заголовок для всей последовательности.

Сетевая карта (NIC), поддерживающая RSC на аппаратном уровне, может значительно повысить производительность приёма данных. Кроме того, он может снизить загрузку ЦП узла, так как он освобождает уровень протокола от выполнения RSC в программном обеспечении.

Дополнительные сведения о RSC см. в обзоре объединения полученных сегментов .

NetAdapterCX также поддерживает UDP RSC (URO) начиная с версии 2.5. Дополнительные сведения см. в UDP RSC Offload (URO).

Ключевые слова INF для управления разгрузкой RSC

NetAdapterCx проверяет ключевые слова реестра и учитывает их при включении активных возможностей разгрузки. Драйверу не нужно предпринимать никаких дальнейших действий.

Ключевые слова RSC, указанные в стандартных INF-ключевых словах для RSC, можно использовать для включения или отключения разгрузки RSC с помощью настройки в реестре.

Значения ключевых слов должны иметь тип REG_SZ.

Настройка разгрузки RSC

Клиентские драйверы сначала объявляют возможности RSC оборудования во время инициализации сетевого адаптера. Это может произойти в функции обратного вызова EvtDevicePrepareHardware, перед запуском сетевого адаптера.

Чтобы настроить возможности RSC, драйвер клиента:

Выделяет структуру NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES.
Вызывает NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES_INIT для инициализации структуры.
Регистрация структуры в NetAdapterCx осуществляется вызовом NetAdapterOffloadSetRscCapabilities.

Во время вызова NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES_INIT драйвер клиента предоставляет указатель на обратный вызов EVT_NET_ADAPTER_OFFLOAD_SET_RSC. Система вызывает этот обратный вызов позже, если активные возможности разгрузки изменяются.

Правила для указания возможностей RSC оборудования

Драйверы клиентов должны НЕ выполнять программную RSC на любом типе трафика, который не поддерживается аппаратно в сетевом адаптере.

Следующие правила применяются к структуре NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES:

NetAdapterOffloadLayer3FlagIPv4NoOptions и NetAdapterOffloadLayer3FlagIPv6NoExtensions являются единственными допустимыми значениями поля Layer3Flags. Эти флаги указывают на поддержку IPv4 и IPv6 соответственно.
NetAdapterOffloadLayer4FlagTcpNoOptions и NetAdapterOffloadLayer4FlagUdp являются единственными допустимыми значениями поля Layer4Flags. Эти флаги указывают на поддержку TCP и UDP соответственно.
Флаги уровня 3 должны быть заданы, если установлен флаг NetAdapterOffloadLayer4FlagTcpNoOptions.
Поле tcpTimestampOption необязательно. Клиентские драйверы задают это поле после вызова NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES_INIT и перед вызовом NetAdapterOffloadSetRscCapabilities, чтобы указать, поддерживает ли сетевой адаптер параметр метки времени TCP.

В следующем примере показано, как драйвер клиента может настроить возможности разгрузки оборудования RSC.

VOID
MyAdapterSetRscOffloadCapabilities(
    NETADAPTER NetAdapter
)
{
    // Configure the hardware's RSC offload capabilities
    NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES rscOffloadCapabilities;
    NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES_INIT(
        &rscOffloadCapabilities,
        NetAdapterOffloadLayer3FlagIPv4NoOptions | NetAdapterOffloadLayer3FlagIPv6NoExtensions,
        NetAdapterOffloadLayer4FlagTcpNoOptions,
        MyEvtAdapterOffloadSetRsc);
    rscOffloadCapabilities.TcpTimestampOption = FALSE;

    // Set the current RSC offload capabilities and register the callback for future changes in active capabilities
    NetAdapterOffloadSetRscCapabilities(NetAdapter, &rscOffloadCapabilities);
}

Обновление разгрузок оборудования RSC

Если стек TCP/IP или протокольный драйвер, расположенный над ним, запрашивает изменение активных возможностей RSC сетевого адаптера, NetAdapterCx вызывает EVT_NET_ADAPTER_OFFLOAD_SET_RSC обратного вызова драйвера клиента, зарегистрированного в NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES. В этом обратном вызове система предоставляет обновленные возможности в объекте NETOFFLOAD, который драйвер клиента может запрашивать для обновления своих возможностей разгрузки.

Клиентские драйверы могут вызывать следующие функции, чтобы определить, какие разгрузки RSC включены:

В следующем примере показано, как драйвер клиента может обновить свои возможности разгрузки RSC:

VOID
MyEvtAdapterOffloadSetRsc(
    NETADAPTER NetAdapter,
    NETOFFLOAD Offload
)
{
    PMY_NET_ADAPTER_CONTEXT adapterContext = NetvAdapterGetContext(NetAdapter);

    // Store the updated information in the context
    adapterContext->IsRscIPv4Enabled = NetOffloadIsTcpRscIPv4Enabled(Offload);
    adapterContext->IsRscIPv6Enabled = NetOffloadIsTcpRscIPv6Enabled(Offload);
    adapterContext->IsRscTcpTimestampOptionEnabled = NetOffloadIsRscTcpTimestampOptionEnabled(Offload);
}

UDP RSC Offload (URO)

URI обеспечивает объединение полученных сегментов UDP. Сетевые адаптеры могут объединять диаграммы данных UDP из одного потока, который соответствует набору правил в логически смежный буфер. Затем эти объединенные диаграммы данных указываются в сетевом стеке Windows в виде одного большого пакета. Сведения о правилах URO см. в Правила для объединения пакетов UDP .

Ключевое слово URO, указанное в ключевом слове INF для управления URO, можно использовать для включения/выключения URO с помощью настройки ключа реестра.

Клиентские драйверы NetAdapterCx могут использовать существующие структуры RSC и API RSC для URI. Чтобы настроить URO, клиентские драйверы должны задать поле Layer4Flags в структуре NET_ADAPTER_OFFLOAD_RSC_CAPABILITIES на NetAdapterOffloadLayer4FlagUdp.

Поведение URO отражает RSC с одним исключением. Когда обратный вызов EVT_NET_ADAPTER_OFFLOAD_SET_RSC отключает URO, драйвер должен указать существующие объединенные сегменты и дождаться завершения всех невыполненных индикаций URO. Этот подход гарантирует, что после возврата обратного вызова нет активных признаков URO.

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