[k000858 0]

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

 

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

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

[winniethepooh 0]

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

 

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

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

 

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

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

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

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

Изменено 24 мая, 2018 пользователем winniethepooh

[k000858 0]

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

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

#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) но система этот пакет не переварила.

[winniethepooh 0]

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

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

 

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

 

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

 

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

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

[k000858 0]

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

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

[winniethepooh 0]

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

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

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

[k000858 0]

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

 

[winniethepooh 0]

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

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

[k000858 0]

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

[k000858 0]

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

 

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

 

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

[winniethepooh 0]

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

 

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

 

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

 

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

[k000858 0]

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

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

[winniethepooh 0]

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

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

 

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

 

[k000858 0]

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

 

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

 

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

[winniethepooh 0]

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

 

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