2015-07-03 6 views
0

Мое приложение получает данные от клиента NFS на сервер NFS (пространство пользователя NFS-сервер - NFS Ganesha), и как только пакеты принимаются на сервере, приложение начинает обработку пакета и отправляет его.Приложение примера DPDK KNI

Я новичок в DPDK, и я анализирую функции в нем, чтобы понять и адаптировать к моему приложению, чтобы ускорить работу, избегая некоторых копий данных из/в пространство ядра/пользователя.

Я нашел KNI полезным и после запуска приложения примера KNI, я видел следующий вывод. Также я могу видеть новые интерфейсы vEth0_0 и vEth1_0. Но я даже не могу выполнить операцию ping для этих интерфейсов после назначения IP-адресов.

$$ ./examples/kni/build/kni -n 4 -c 0xf0 - -P -p 0x3 --config = "(0,4,6,8), (1,5,7, 9) «

*Checking link status 
.done 
Port 0 Link Up - speed 10000 Mbps - full-duplex 
Port 1 Link Up - speed 10000 Mbps - full-duplex 
APP: Lcore 5 is reading from port 1 
APP: Lcore 6 is writing to port 0 
APP: Lcore 7 is writing to port 1 
APP: Lcore 4 is reading from port 0 
APP: Configure network interface of 0 up 
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 32. 
APP: Configure network interface of 1 up 
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 32.* 

Таким образом, мой вопрос в том, каков ожидаемый результат применения образца KNI в DPDK? И как я могу использовать для своего приложения? (Могу ли я делать операции с интерфейсом vEth0_0, так что я могу избежать многократного ядро ​​/ пользовательское копия)

Update: выше вопрос решен в хост-машине, установив правильные параметры GRUB, как IOMMU = пт, intel_iommu = на

Вопрос 2: Как использовать KNI внутри виртуальной машины? Возникновение KNI внутри виртуальной машины имеет проблемы.

KNI: /dev/kni opened 
KNI: Creating kni... 
KNI: tx_phys:  0x000000017a6af140, tx_q addr:  0xffff88017a6af140 
KNI: rx_phys:  0x000000017a6b1180, rx_q addr:  0xffff88017a6b1180 
KNI: alloc_phys: 0x000000017a6b31c0, alloc_q addr: 0xffff88017a6b31c0 
KNI: free_phys: 0x000000017a6b5200, free_q addr: 0xffff88017a6b5200 
KNI: req_phys:  0x000000017a6b7240, req_q addr:  0xffff88017a6b7240 
KNI: resp_phys: 0x000000017a6b9280, resp_q addr: 0xffff88017a6b9280 
KNI: mbuf_phys: 0x0000000187c00000, mbuf_kva:  0xffff880187c00000 
KNI: mbuf_va:  0x00002aaa32800000 
KNI: mbuf_size: 2048 
KNI: pci_bus: 00:03:00 
KNI: Error: Device not supported by ethtool 
+0

Любые эксперты могут мне помочь – sak

+0

При дальнейшем анализе я обнаружил, что пакеты отправляются интерфейсом vEth0_0 (проверяется tcpdump для интерфейса vEth0_0). Таким образом, кажется, что чтение с интерфейса NIC ядра и запись его в интерфейс физического интерфейса не происходит. Кто-то столкнулся с этой проблемой? – sak

ответ

1

Проблема в приложении KNI заключается в том, что в нем не будет отображаться ошибка непосредственно с идентификатором, возникают проблемы с отображением DMA. «dmesg» в хост-системе показывает, что отображение DMA имело проблемы с сетевым устройством.

Позже я обнаружил, что для драйвера igb_uio требуется установка опции ядра «iommu = pt, intel_iommu = on». поэтому после установки этого в /etc/default/grub файл и выполнение «update-grub» Я могу подключить интерфейс KNI с помощью драйвера igb_uio, и сетевой стек работает нормально.

Все еще KNI внутри гостевой ВМ не работает. Проверка на этом.

 Смежные вопросы

  • Нет связанных вопросов^_^