Содержание

Обработка по быстрому маршруту

Упрощенная картинка обработки пакета по быстрому маршруту (кликабельно):

Блок EMAC

Блок EMAC принимает пакет от внешнего PHY и передает в блок GPI. Параметры EMAC:

Блок GPI

Каждый блок EMAC работает в паре со своим блоком GPI. Параметры GPI:

GPI_RX

Если в памяти LMEM нет свободных буферов и BMU не может вернуть адрес свободного буфера, то GPI некуда передать данные из своего FIFO. Тогда GPI выдерживает паузу прежде чем запросить новый буфер. Ожидается, что за это время буфер может освободиться - его освободит GPI от другого ЕМАС порта. Пауза задается в количествах тактов частоты ядра в регистре GPI_RX_CONFIG, поле csr_alloc_retry_cycles [25:16].

Если трафик очень высокий, то может возникнуть переполнение FIFO. Данные фрейма в таком случае являются утерянными. Адрес буфера такого пакета все-равно передается в классификатор. Классификатор поймет, что пакет не полный по полю "Статус переполнения FIFO" в расширенном заголовке. (Предположительно, классификатор по полям фрейма МАС и прочим, сможет обновить таблицу маршрутизации, но не будет дальше пересылать пакет. Количество отброшенных пакетов можно узнать чтением регистра GPI_CSR_OVERRUN_DROPCNT.)

Блок BMU

Блок "разделяет" сплошную память LMEM на буферы определенной длины, по умолчанию 128 байт. Память под пакеты выделяется и освобождается такими буферами. С содержимым буферов работают прочие блоки. Например, блок GPI разделяет каждый буфер на заголовок и область под данные. В заголовке указывается указатель на следующий буфер и дополнительная информация. Таким образом буферы образуют цепь и могут хранить большие фреймы, например Jumbo фреймы. Но BMU про это ничего не знает, область его ответственности - это выделить буфер 128 байт и освободить буфер.

Блок Classifier

Необходимо обратить внимание, что заголовок первого буфера в 48 байт используется для передачи RX_STATUS от GPI в классификатор. Поэтому только в этих блоках есть регистр AXI_GPI_HDR_SIZE, который определяет этот размер заголовка. Для всех последующих буферов заголовок составляет 16 байт и задается регистром LMEM_DATA_OFFSET, что говорит с какого смещения начинаются данные пакета после заголовка.

Классификатор используется этот первый заголовок в 48 байт для обработки пакета. Классификатор может внести изменение в пакет, например снять или вставить тег VLAN. Поэтому GPI при сохранении пакета в память резервирует второй буфер для того, чтобы классификатор смог положить туда модифицированный пакет. Соответственно, после того как классификатор отработал, то первый буфер становится не нужен, поэтому классификатор сразу освобождает первый буфер.

Отсюда следует то, что:

Модификации пакета, указанные в спецификации:

Поскольку первый буфер был освобожден, то значение длины пакета, которое раньше хранилось в RX_STATUS, теперь передается классификатором в блок TMU через регистр TMU_PHY_INQ_PKTINFO.

О содержимом заголовков буферов нет детальной информации. Но о некоторых составляющих можно судить по логу, полученному при инжекции пакета от Host процессора:

По логу видно, что второй буфер тоже имеет заголовок в 48 байт, а кроме этого содержит заголовок описанный в п. 5.9.5 спецификации - "Структура передаваемого пакета".

Маршрутизация по таблицам МАС и VLAN

Для обслуживания таблиц маршрутизации нужен внешний "Процессорный модуль" (PE - Processing Engine), далее называется Хост. Только Хост может добавлять/удалять/обновлять записи в данных таблицах. Сама микросхема 1928KX028 таблицы редактировать никак не может. В качестве Хоста, может выступать:

Чтобы Хост мог обслуживать таблицы, входящие пакеты должны пересылаться на хост - это называется PUNT. Пересылку пакетов на Хост назначает классификатор когда для этого есть причины. Причины по которым происходит захват пакета на Хост:

(SA -это Source MAC Address, DA - это Destination MAC Address)

Когда классификатор вычитывает в свою локальную память первый буфер с пакетом, то он проверяет наличие записей в таблицах маршрутизации для полей MAC_SRC и MAC_DEST данного пакета.

Поиск по МАС_SRC:

Наличие МАС_SRC PORT_SRC в PortList Fresh bit Реакция Классификатора
+ + 0 Действий не требуется
1 Требуется обновление записи, PUNT_SA_IS_ACTIVE
+ - x Требуется переобучение, PUNT_SA_RELEARN
- х x Требуется обучение, PUNT_SA_MISS

(х - значение не имеет влияния)

Очевидно, что если МАС источника нет в таблице МАС, то Хост должен добавить в таблицу запись о том, на каком порте находится данный МАС адрес. Если порт сменился, то данную запись необходимо обновить. Если же МАС запись в таблице уже есть и порт совпадает, то происходит проверка устаревания фрейма. Обработка устаревания производится программным обеспечением Хоста. Хост периодически, например раз в 5 минут, читает все активные записи в МАС таблице и далее:

Поиск по МАС_DEST:

Чаще всего, поиск по МАС_DEST необходим чтобы найти порты, на которые следует переслать пакет. Но помимо пересылки фрейма, можно настроить прочие действия с фреймом. Действия с фреймом задаются полями внутри записи в таблицах. Если же для фрейма нет записей в таблицах, то берется действие по умолчанию, которое настраивается в регистрах CLASS_GLOBAL_CFG[31:1] и CLASS_GLOBAL_CFG1[23:0].

Наличие МАС_DEST Наличие VLAN Источник действий
+ + поле ActionFields таблицы МАС
- + поле ACTIONS таблицы VLAN
- - регистры CLASS_GLOBAL_CFG и CLASS_GLOBAL_CFG1

Поле действие занимает 3 бита, значения в поле могут быть такие:

Значение поля Описание
0: ACT_FORWARD Пересылка пакета согласно Forward_list из записи в таблице MAC / VLAN / CLASS_GLOBAL_CFG
1: ACT_FLOOD Рассылка (unicast) пакета согласно Forward_list из записи в таблице VLAN / CLASS_GLOBAL_CFG
2: ACT_PUNT Пересылка пакета на Хост для обработки
3: ACT_DISCARD Отбросить пакет
4: ACT_OVERRIDE Действие берется из поля UNICAST_HIT_ACT записи таблицы VLAN / CLASS_GLOBAL_CFG1
5: ACT_FWD_MASK Пересылка в MAC Forward_list & VLAN Forward_list
6: ACT_COS_DISCARD Сравнивается (1 « VLAN_PCP & CLASS_NPU_CTRL[31:24].csr_discard_cos_n ):
≠ 1 - Пакет рассылается согласно Forward_list из записи в таблице VLAN / CLASS_GLOBAL_CFG
= 0 - Пакет отбрасывается (flood supression)

(Здесь VLAN_PCP - это поле PCP внутри тэга VLAN обрабатываемого пакета. Пересылка по Forward_list исключает пересылку на порт, с которого принят фрейм.)

Поиск MAC_DEST и выбор действия для обработки пакета происходит по такому сценарию:

Работая с таблицами, Хост сам задает необходимую реакцию на обработку фреймов. Это позволяет получить от микросхемы то, или иное поведение. Все что делает с таблицами Хост также может быть выполнено в режиме Mode2 внешним контроллером, подключенным по интерфейсу SPI.

MAC Table

На картинке показан случай, когда два фрейма имеют разные поля МАС и/или VLAN, но при этом функция вычисления HASH выдает одинаковый результат. В результате, при приходе нового фрейма с МАСх и VLANx, по вдресу Хэша в таблице маршрутизации МАС лежит не совпадающая с МАСх и VLANx запись. Поэтому аппаратура проверяет валидность флага коллизий и переходит по адресу в поле коллизий. В области коллизий поиск происходит по связному списку, пока не будет найдена запись со значениями МАСх и VLANx.

Чтобы новая запись появилась в таблицах, ее должен туда прописать HOST контроллер (Драйвер РС через PCIe в режиме MODE_0 / Микроконтроллер через Slave-SPI в режиме MODE_2).

При инициализации таблицы все поля коллизий равны нулю. Связный список в поле коллизий должен прописать HOST контроллер перед началом работы!

Флаги:

VLAN Table

Поиск по VLAN таблице происходит аналогично поиску по MAC таблице. По сравнению с МАС таблицей, здесь другие поля в разделе Actions и отсутствует поле МАС адреса.

Поля:

(Действия здесь, это значение из ACT_FORWARD .. ACT_COS_DISCARD, описано выше.)

HIF трансфер из HOST в коммутатор

При чтении схемы трафика между приложением и хостом надо смотреть на номера в подписях. Например, цифры в надписях "1Т Request …", "2Т TX BD …" и т.д. показывают очередность обработки трафика передачи, Transmit. Надписи с R, показывают очередность приема, Receive.

Слева на данной картинке сигналы идут к контроллеру PCIe. Справа находится HGPI и ядро коммутатора.

Пакеты в памяти LMEM

Всего памяти LMEM в коммутаторе 512КБ. Это два блока по 256КБ - LMEM0 и LMEM4, для каждого классификатора по своему блоку памяти.

На картинке ниже представлено расположение принятого пакета в памяти LMEM при обращении за обучением к хосту. По полям CTRL и Size хост узнает по какой причине пакет отправлен на хост и какой длины этот фрейм (плюс заголовок). Это первый буфер, поэтому у него заголовок составляет 48 байт. Со второго буфера заголовок имеет длину 16 байт, остальное место отдано под данные пакета.

Планировщики и формирователи TMU (TLITE)

Алгоритмы работы планировков:

HIF Transfer

Упрощенное представление обмена дескрипторами между блоком HIF и сетевым драйвером.

Краткое пояснение:

  1. Когда по сетевому стеку в драйвер спускается фрейм на отправку (в виде SKB буфера), то в самом skb, в поле skb→dev указывается каким сетевым устройсвом данный skb следует передать.
  2. Когда сетевое устройство регистрировалось в системе, оно выдало системе стек функций struct net_device_ops, через которые система работает с данным устройством. В данном стеке функций есть поле ndo_start_xmit, в котором хранится указатель на функцию реализующую отправку фрейма. Соответственно, skb передается в данную функцию ndo_start_xmit(skb) для отправки.
  3. В драйвере 1923КХ028 фрейм модицируется необходимым заголовком и записывается в один или несколько буферов (несколько - в случае посылки jumbo фрейма). Для этого в кольцевом буфере дескрипторов BD ищется свободный дескриптов, а данные из SKB копируются в буфер ассоциированный с данным дескриптором. Дескриптор помечается активным, т.е. выставляется бит DESC_EN в поле CTRL дескриптора.
  4. HIF интерфейс через механизм DMA постоянно вычитывает дескрипторы и проверяет наличие бита DESC_EN. Когда такой дескриптор встречается, то вычитывается его буфер данных - т.е. фрейм. Далее фрейм через интерфейс HGPI копируется в память LMEM микросхемы и далее обрабатывается микросхемой.
    • Если фрейм с битом инжекции, то он сразу отправляется в назначеный порт инжекции.
    • Если фрейм без инжекции, то он пропускается через классификатор, который уже решает куда фрейм следует отправить.
  5. По окончании приема фрейма, HIF записывает в текущий WriteBack буфер (BDWB) сколько данных он принял и выставляет в нем seq_num от обработанного BD. После этого генерируется PCI прерывание TXPKT_INT.
  6. Получив прерывание, драйвер видит причину прерывания - TXPKT_INT в регистре INT_SRC и обрабатывает буфер BDWB. Фрейм считается переданным, а в дескрипторе BD снимается бит DESC_EN. Т.е. дескриптор BD становится свободным для следующего использования.

HIF состоит из 4-х каналов, в каждом канале есть кольцевой буфер дескрипторов для приема данных из PC и кольцевой буфер для передачи данных в РС. Каждый из этих кольцевых буферов опрашивается интерфейсом HIF. Когда микросхема отправляет на Хост фрейм, то:

  1. Она находит свободный BD в кольце на передачу данных в РС.
  2. Копирует данные в буфер ассоциированный с BD посредством DMA.
  3. Указывает в WriteBack дестрипторе сколько данных передал в РС и записывает seq_num от BD.
  4. Генерирует прерывание RXPKT_INT на шине PCI
  5. Драйвер, получив прерывание, обрабатывает все дескрипторы BD, для которых активны дескрипторы WriteBack. Он аллоцирует объекты skb и копирует в них данные из буферов BD. skb передаются наверх в сетевой стек.

ИТОГО:

  1. BD (Дескриптор Буфера) записывается драйвером и читается HIF блоком микросхемы.
  2. BUFF (буфер в памяти РС) пишется драйвером, если BD в кольце передачи данных в микросхему. И читается драйвером, если BD в кольце чтения данных из микросхемы.
  3. BDWB (Обратный дескриптор) пишется блоком HIF микросхемы и читается драйвером.