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

    

k000858

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Местный

Посетители профиля

3 130 просмотров профиля
  1. Проприетарный драйвер

    окей, поставлю вопрос по-другому: как программно обойти эти заморочки? Простой рефакторинг вариант, но довольно время-затратный (драйвер состоит из более чем 700 файлов исходного кода). Если просто вложить драйвер в предкомпилированном виде в код ядра?
  2. Проприетарный драйвер

    Есть дистрибутив, который необходимо выкладывать в открытый доступ, и который включает драйвер, скачанный из интернета (считай сворованный). Необходимо чтобы все компилировалось, но исходники проприетарного драйвера светить нельзя. Очевидный выход - завернуть исходники в блобы (предкомпилированный бинарник). Это нарушит лицензию? Что если автору проприетарного драйвера это не понравится, что он может от меня потребовать? Как обойти эти заморочки с лицензиями?
  3. пффф с web технологиями в embedded не сталкивались?))
  4. благодарю за пинок в возможно верном направлении :smile3046:
  5. Qt на STM32 comming soon

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