В Mellanox ConnectX-3 не поддерживается фрагментация пакетов DPDK?

Question

Привет эксперты Stackru,

Я использую DPDK на сетевой плате Mellanox, но пытаюсь применить фрагментацию пакетов в приложении DPDK.

sungho@c3n24:~$ lspci | grep Mellanox
81:00.0 Ethernet controller: Mellanox Technologies MT27500 Family
[ConnectX-3]

приложение dpdk (l3fwd, ip-фрагментация, ip-сборка) не распознало полученный пакет как заголовок ipv4.

Сначала я создавал свои собственные пакеты при отправке заголовков ipv4, поэтому предположил, что создавал пакеты неправильно.

Поэтому я использовал DPDK-pktgen, но dpdk-application (l3fwd, ip-фрагментация, ip-сборка) не распознал заголовок ipv4. В качестве последнего средства я протестировал dpdk-testpmd и выяснил это в информации о состоянии.

********************* Infos for port 1 *********************
MAC address: E4:1D:2D:D9:CB:81
Driver name: net_mlx4
Connect to socket: 1
memory allocation on the socket: 1
Link status: up
Link speed: 10000 Mbps
Link duplex: full-duplex
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 127
Maximum number of MAC addresses of hash filtering: 0
VLAN offload:
strip on
filter on
qinq(extend) off
No flow type is supported.
Max possible RX queues: 65408
Max possible number of RXDs per queue: 65535
Min possible number of RXDs per queue: 0
RXDs number alignment: 1
Max possible TX queues: 65408
Max possible number of TXDs per queue: 65535
Min possible number of TXDs per queue: 0
TXDs number alignment: 1
testpmd> show port

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

Supported flow types:
ipv4-frag
ipv4-tcp
ipv4-udp
ipv4-sctp
ipv4-other
ipv6-frag
ipv6-tcp
ipv6-udp
ipv6-sctp
ipv6-other
l2_payload
port
vxlan
geneve
nvgre

Итак, мой сетевой адаптер Mellanox Connect X-3 не поддерживает фрагментацию IP-адреса DPDK? Или есть дополнительная настройка, которую необходимо выполнить перед тем, как попробовать фрагментацию пакетов?

- [EDIT] Итак, я проверил пакеты от DPDK-PKTGEN и пакеты, полученные приложением DPDK. Пакеты, которые я получаю, являются именно теми, которые я отправил из приложения. (Я получаю правильные данные)

Проблема начинается с кода

struct rte_mbuf *pkt
RTE_ETH_IS_IPV4_HDR(pkt->packet_type) 

Это определяет, является ли пакет ipv4 или нет. и значение pkt->packet_type равно как от DPDK-PKTGEN, так и от приложения DPDK. и если pkt-packet_type равен нулю, тогда приложение DPDK рассматривает этот пакет как заголовок NOT IPV4.

Этот базовый тип проверки неверен с самого начала. Поэтому я считаю, что либо образец DPDK неверен, либо NIC по какой-то причине не может поддерживать ipv4.

Данные, которые я получил, вначале имеют некоторую структуру. Я получаю правильное сообщение, но после этой последовательности пакетов данные MAC-адреса и смещения данных различаются.

Поэтому я предполагаю, что они по-разному интерпретируют данные и получают неправильный результат.

Answer 1

Я уверен, что любая сетевая карта, включая Mellanox ConnectX-3, ДОЛЖНА поддерживать фрагменты ip.

Тип потока, на который вы ссылаетесь, относится к директору потока, то есть отображает конкретные потоки в определенные очереди RX. Даже если ваша сетевая карта не поддерживает потоковый директор, это не имеет значения для фрагментации IP.

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

приложение dpdk не распознало полученный пакет как заголовок ipv4.

Я хотел бы изучить это более внимательно. Попробуйте сбросить эти пакеты с dpdk-pdump или даже просто выгрузив принимающий пакет на консоль с помощью rte_pktmbuf_dump()

Если вы все еще подозреваете сетевой адаптер, лучшим вариантом будет временная замена его другим брендом или виртуальным устройством. Просто чтобы подтвердить, что это действительно NIC.

РЕДАКТИРОВАТЬ:

Посмотри на mlx4_ptype_table для фрагментированных пакетов IPv4 должен возвращаться packet_type установлен в RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_FRAG

Обратите внимание, что функциональность была добавлена ​​в DPDK 17.11.

Я предлагаю вам сбросить pkt->packet_type на консоли, чтобы убедиться, что это действительно ноль. Также убедитесь, что у вас есть последние libmlx4 установлены.