k000858 0 Posted May 24, 2018 · Report post В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины? Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted May 24, 2018 (edited) · Report post В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины? сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов. попробуйте изменить кол-во дескрипторов, например #define DEF_RXDESC_NUM (100 вместо 4 если память позволяет..) если все пакеты теряются на нижнем уровне то это должно помочь. Edited May 24, 2018 by winniethepooh Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted May 24, 2018 · Report post сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов. попробуйте изменить кол-во дескрипторов, например #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) но система этот пакет не переварила. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted May 24, 2018 · Report post поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет. то есть у этих 2х эффектов одна причина. пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила. да это интересно, что то в пакетах делает их невидимыми для ОС? может можно сравнить с пакетами от другой системы.. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted May 28, 2018 · Report post распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted May 28, 2018 · Report post распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом вставлять заголовки может как ядра так и сетевое устройство.. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted May 28, 2018 · Report post Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера? Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted May 28, 2018 · Report post Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера? если я не ошибаюсь, сетевое устройство может убрать ip заголовок из пакета(зависит от настоек NIC). Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted May 31, 2018 · Report post По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted June 7, 2018 · Report post В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP). Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted June 7, 2018 · Report post В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP). посмотрите https://people.cs.clemson.edu/~westall/853/notes/ Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted June 14, 2018 · Report post В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект? Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted June 14, 2018 · Report post В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект? почему вы думаете драйвер нагружает а не сокет например? Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
k000858 0 Posted June 14, 2018 · Report post почему вы думаете драйвер нагружает а не сокет например? При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован) тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
winniethepooh 0 Posted June 14, 2018 · Report post тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным ничего не знаю про тест openwrt, но сомневаюсь что он может показать в каком слое стека застревают пакеты. Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
