Jump to content

    

k000858

Участник
  • Content Count

    324
  • Joined

  • Last visited

Community Reputation

0 Обычный

About k000858

  • Rank
    Местный

Recent Profile Visitors

3261 profile views
  1. Embedded Linux

  2. Проприетарный драйвер

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

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