Перейти к содержанию

k000858

Участник
  • Публикаций

    319
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о k000858

  • Звание
    Местный
  1. благодарю за пинок в возможно верном направлении :smile3046:
  2. Qt на STM32 comming soon

    http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/ Вот тут то и пригодятся суперпроизводительные F7/H7. На мой взгляд технология поперспективнее явы на STM32. Как считаете?
  3. Как в драйвере задать битовую маску CPU, которая после создания соединения прописывается в rps_cpus (/sys/class/net/<device>/queues/<rx-queue>/rps_cpus ) ???
  4. самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет). При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ. Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет. Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?
  5. тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным
  6. В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?
  7. В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).
  8. По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2.
  9. Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера?
  10. распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом
  11. попробую увеличить. правда вряд ли это поможет, большая часть пакетов все же удачно принимается, однако счетчик Rx0 = 0. При том само устройство тоже отправляет пакеты (запрос DHCP), и этот запрос я вижу в программе DHCP сервер (мак точно устройства), но счетчик полученных пакетов на ПК 0. Как так??? ПО верхнего уровня пакет получает (DHCP запрос) а в свойствах сетевого соединения количество полученных пакетов не растет... добавлено: поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет. то есть у этих 2х эффектов одна причина. пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила.
  12. В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины?
  13. да, что то вроде того. все верно описали вы. в моем случае почему то не доходит до netif_rx, в драйвере куча ветвлений логики и препроцессора (#if) разбираюсь.
  14. Проблема с прерываниями уже решена. Что сделал: - подсмотрел номера нужных мне прерываний через cat /proc/interrupts в ОС при работающем родном драйвере openWRT (который я пытаюсь заменить на интегрируемый). - заменил номера прерываний на подсмотренные в дефайнах интегрируемого драйвера Родной openwrt инициализируется через module_platform_driver, номера прерываний задаются в device tree и передаются в драйвер через MODULE_DEVICE_TABLE (если я все верно понимаю). В интегрируемом мной драйвере же номера прерываний заданы в дефайнах. Почему они отличаются..не понимаю. К слову, мое сетевое устройство это встроенный в SoC свитч, MT7621 SoC. Прерывания на изменение линка и получение данных заработали. Так же заработала поллинг-функция. Дальше пакеты (в ОС) почему то не поступают, разбираюсь дальше.
  15. Вроде как никак не описано. Сам драйвер вызывается module_init(ra2882eth_init); module_exit(ra2882eth_cleanup_module);