Jump to content

    
Sign in to follow this  
k000858

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

Recommended Posts

В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается.

 

При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое).

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

Share this post


Link to post
Share on other sites
В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается.

 

При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое).

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

 

сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов.

попробуйте изменить кол-во дескрипторов, например

#define DEF_RXDESC_NUM (100 вместо 4 если память позволяет..)

если все пакеты теряются на нижнем уровне то это должно помочь.

Edited by winniethepooh

Share this post


Link to post
Share on other sites
сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов.

попробуйте изменить кол-во дескрипторов, например

#define DEF_RXDESC_NUM (100 вместо 4 если память позволяет..)

если все пакеты теряются на нижнем уровне то это должно помочь.

попробую увеличить. правда вряд ли это поможет, большая часть пакетов все же удачно принимается, однако счетчик Rx0 = 0.

 

При том само устройство тоже отправляет пакеты (запрос DHCP), и этот запрос я вижу в программе DHCP сервер (мак точно устройства), но счетчик полученных пакетов на ПК 0. Как так??? ПО верхнего уровня пакет получает (DHCP запрос) а в свойствах сетевого соединения количество полученных пакетов не растет...

 

добавлено:

 

поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig

Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет.

 

то есть у этих 2х эффектов одна причина.

 

пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила.

Share this post


Link to post
Share on other sites
поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig

Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет.

 

то есть у этих 2х эффектов одна причина.

 

пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила.

 

да это интересно, что то в пакетах делает их невидимыми для ОС?

может можно сравнить с пакетами от другой системы..

Share this post


Link to post
Share on other sites

распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее:

- интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом

Share this post


Link to post
Share on other sites
распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее:

- интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом

вставлять заголовки может как ядра так и сетевое устройство..

Share this post


Link to post
Share on other sites
Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера?

если я не ошибаюсь, сетевое устройство может убрать ip заголовок из пакета(зависит от настоек NIC).

Share this post


Link to post
Share on other sites

По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2.

Share this post


Link to post
Share on other sites

В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери.

 

По видимому причина в netif_receive_skb = -1

 

В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).

Share this post


Link to post
Share on other sites
В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери.

 

По видимому причина в netif_receive_skb = -1

 

В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).

 

посмотрите https://people.cs.clemson.edu/~westall/853/notes/

Share this post


Link to post
Share on other sites

В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит.

Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?

Share this post


Link to post
Share on other sites
В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит.

Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?

 

почему вы думаете драйвер нагружает а не сокет например?

 

Share this post


Link to post
Share on other sites
почему вы думаете драйвер нагружает а не сокет например?

 

При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован)

 

тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным

Share this post


Link to post
Share on other sites
тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным

 

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

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