k000858

А есть у когонибудь опыт по отладке ядерной части ПО? Например драйверы и тд. Что нужно сделать что бы можно было по тому же gdb отлаживать, скажем, драйвер в ядре на уже загруженной системе? (про отладку загрузки того же драйвера пока молчу)

такое стоит не 25к. 25к - это половина месячной з/п самого дешевого джуна, который не сможет интегрировать драйвер wifi в сборку openwrt (говорю по опыту работы с кучей джунов как на удаленке так и нет). прокачанный системный программист может сделать это и за день, если супер-повезет и драйвер в исходном состоянии совместим с версией ядра linux в вашей сборке openwrt, а это ни так 99.999% Так же стоит учитывать, что если ваш драйвер не умеет работать со старндартным /etc/config/wireless то веб-интерфейс OpenWrt придется значительно дорабатывать. а это еще вся работа x2

1000$

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

Есть дистрибутив, который необходимо выкладывать в открытый доступ, и который включает драйвер, скачанный из интернета (считай сворованный). Необходимо чтобы все компилировалось, но исходники проприетарного драйвера светить нельзя. Очевидный выход - завернуть исходники в блобы (предкомпилированный бинарник). Это нарушит лицензию? Что если автору проприетарного драйвера это не понравится, что он может от меня потребовать? Как обойти эти заморочки с лицензиями?

пффф с web технологиями в embedded не сталкивались?))

благодарю за пинок в возможно верном направлении :smile3046:

http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/ Вот тут то и пригодятся суперпроизводительные F7/H7. На мой взгляд технология поперспективнее явы на STM32. Как считаете?

Как в драйвере задать битовую маску CPU, которая после создания соединения прописывается в rps_cpus (/sys/class/net/<device>/queues/<rx-queue>/rps_cpus ) ???

самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет). При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ. Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет. Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?

тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным

В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?

В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).

По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2.

Больше волнует вопрос: при получении пакета, должен ли содержаться заголовок IP протокола в sk_buff->data при передаче его в ядро из драйвера?

распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее: - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом

попробую увеличить. правда вряд ли это поможет, большая часть пакетов все же удачно принимается, однако счетчик Rx0 = 0. При том само устройство тоже отправляет пакеты (запрос DHCP), и этот запрос я вижу в программе DHCP сервер (мак точно устройства), но счетчик полученных пакетов на ПК 0. Как так??? ПО верхнего уровня пакет получает (DHCP запрос) а в свойствах сетевого соединения количество полученных пакетов не растет... добавлено: поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет. то есть у этих 2х эффектов одна причина. пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила.

В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается. При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое). Так же похоже после определенного количества принятых пакетов устройство перестает их принимать, во всяком случае счетчик принятых пакетов перестает расти. Такое ощущение что в систему пакеты поступают из драйвера, но не разгребаются там, занимаются всю доступную память, после чего устройство перестает отправлять пакеты в систему. может такое быть? какие могут быть причины?

да, что то вроде того. все верно описали вы. в моем случае почему то не доходит до netif_rx, в драйвере куча ветвлений логики и препроцессора (#if) разбираюсь.

Проблема с прерываниями уже решена. Что сделал: - подсмотрел номера нужных мне прерываний через cat /proc/interrupts в ОС при работающем родном драйвере openWRT (который я пытаюсь заменить на интегрируемый). - заменил номера прерываний на подсмотренные в дефайнах интегрируемого драйвера Родной openwrt инициализируется через module_platform_driver, номера прерываний задаются в device tree и передаются в драйвер через MODULE_DEVICE_TABLE (если я все верно понимаю). В интегрируемом мной драйвере же номера прерываний заданы в дефайнах. Почему они отличаются..не понимаю. К слову, мое сетевое устройство это встроенный в SoC свитч, MT7621 SoC. Прерывания на изменение линка и получение данных заработали. Так же заработала поллинг-функция. Дальше пакеты (в ОС) почему то не поступают, разбираюсь дальше.

Вроде как никак не описано. Сам драйвер вызывается module_init(ra2882eth_init); module_exit(ra2882eth_cleanup_module);

сравниваю интегрируемый драйвер с имеющимися под новое ядро: - в старом интегрируемом драйвере номер прерывания задан дифайном #define IRQ_ENET0 3 /* hardware interrupt #3, defined in ... - в новом драйвере номер прерывания выбирается вызовом функции platform_get_irq может тут какое то несоответствие? мне этот момент не очень понятен..

что могло так смениться в версиях ядра? сам драйвер прекрасно работает в 3.10.* все подозрения на неработающее прерывание (нет реакции на изменение линка) в начале работы драйвер даже не компилировался, например изза отсутствия в ядре IRQF_DISABLED (удален с 4.12.5 ядра).

Вы все верно описали - мой драйвер работает по NAPI модели: 1. Драйвер включает NAPI, но изначально тот находится в неактивном состоянии. 2. Прибывает пакет, и сетевая карта напрямую отправляет его в память. 3. Сетевая карта генерирует IRQ посредством запуска обработчика прерываний в драйвере. 4. Драйвер будит подсистему NAPI с помощью SoftIRQ (подробнее об этом — ниже). Та начинает собирать пакеты, вызывая в отдельном треде исполнения (thread of execution) зарегистрированную драйвером функцию poll. 5. Драйвер должен отключить последующие генерирования прерываний сетевой картой. Это нужно для того, чтобы позволить подсистеме NAPI обрабатывать пакеты без помех со стороны устройства. 6. Когда вся работа выполнена, подсистема NAPI отключается, а генерирование прерываний устройством включается снова. 7. Цикл повторяется, начиная с пункта 2. Прерываний нет (не только по прибытию входящих пакетов но и на изменение линка).