Jump to content

    
Sign in to follow this  
k000858

Не работает драйвер сетевого устройства

Recommended Posts

ничего не знаю про тест openwrt, но сомневаюсь что он может показать в каком слое стека застревают пакеты.

самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет).

При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ.

Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет.

 

Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?

Share this post


Link to post
Share on other sites
самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет).

При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ.

Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет.

 

Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?

логика работы драйвера построена так что бы не отвлекать проц(используя dma разместить пакеты. ну вы должны это знать сами..)

у меня тоже проблема с медленной обработкой пакетов, я думаю это в уровне между стеком и пользовательским приложением(обработка совтовых прерываний, переключение из режима ядра в режим пользователя). я потратил много времени просматривая движение пакетов вверх по стеку и видел что они передаются без задержки. На уровне где расположены сокеты перестал работат printk и посмотреть где точно происходит задержка и потеря пакетов не удалось.

я предполагаю учитывая тяжеловесность слоя сокетов (я использую ARM Cortex-M3 144 Мгц, 16Мб ОЗУ uClinux) что задержка происходит в этом слое.

Edited by winniethepooh

Share this post


Link to post
Share on other sites
Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?

В модели NAPI есть такой важный параметр как счётчик числа сетевых пакетов, при приёме меньше которого драйвер возвращается из режима программного пулинга и переходимт в режим ожидания прерываний. Поиграйтесь с этим параметром.

 

P.S. Может подскажет какую мелочь, из об ласти сетевых драйверов или модулей фильтров сетевых протоколов вот этот текст: Практикум по Linux Kernel.

Ну и Сетевое программирование в Linux - здесь о стыке сокетных буферов в ядре с сокетами простанства пользователя.

Share this post


Link to post
Share on other sites
В модели NAPI есть такой важный параметр как счётчик числа сетевых пакетов, при приёме меньше которого драйвер возвращается из режима программного пулинга и переходимт в режим ожидания прерываний. Поиграйтесь с этим параметром.

 

P.S. Может подскажет какую мелочь, из об ласти сетевых драйверов или модулей фильтров сетевых протоколов вот этот текст: Практикум по Linux Kernel.

Ну и Сетевое программирование в Linux - здесь о стыке сокетных буферов в ядре с сокетами простанства пользователя.

благодарю за пинок в возможно верном направлении :smile3046:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this