k000858 0 24 мая, 2018 Опубликовано 24 мая, 2018 · Жалоба В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 24 мая, 2018 Опубликовано 24 мая, 2018 (изменено) · Жалоба В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины? сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов. попробуйте изменить кол-во дескрипторов, например #define DEF_RXDESC_NUM (100 вместо 4 если память позволяет..) если все пакеты теряются на нижнем уровне то это должно помочь. Изменено 24 мая, 2018 пользователем winniethepooh Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 24 мая, 2018 Опубликовано 24 мая, 2018 · Жалоба сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов. попробуйте изменить кол-во дескрипторов, например #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 24 мая, 2018 Опубликовано 24 мая, 2018 · Жалоба поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет. то есть у этих 2х эффектов одна причина. пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила. да это интересно, что то в пакетах делает их невидимыми для ОС? может можно сравнить с пакетами от другой системы.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 28 мая, 2018 Опубликовано 28 мая, 2018 · Жалоба распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 28 мая, 2018 Опубликовано 28 мая, 2018 · Жалоба распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом вставлять заголовки может как ядра так и сетевое устройство.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 28 мая, 2018 Опубликовано 28 мая, 2018 · Жалоба Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 28 мая, 2018 Опубликовано 28 мая, 2018 · Жалоба Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера? если я не ошибаюсь, сетевое устройство может убрать ip заголовок из пакета(зависит от настоек NIC). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 31 мая, 2018 Опубликовано 31 мая, 2018 · Жалоба По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 7 июня, 2018 Опубликовано 7 июня, 2018 · Жалоба В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 7 июня, 2018 Опубликовано 7 июня, 2018 · Жалоба В общем победил настройки встроенного в 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 14 июня, 2018 Опубликовано 14 июня, 2018 · Жалоба В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 14 июня, 2018 Опубликовано 14 июня, 2018 · Жалоба В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект? почему вы думаете драйвер нагружает а не сокет например? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k000858 0 14 июня, 2018 Опубликовано 14 июня, 2018 · Жалоба почему вы думаете драйвер нагружает а не сокет например? При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован) тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winniethepooh 0 14 июня, 2018 Опубликовано 14 июня, 2018 · Жалоба тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным ничего не знаю про тест openwrt, но сомневаюсь что он может показать в каком слое стека застревают пакеты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться