[1891ВМ12Я 0]

10 hours ago, Doka said:

я этот момент спецом отмоделировал на срезе AXI stream

Это понятно. А на стороне драйвера? Там можно проверить паттерном в самой ранней точке получения. Если и в HDL-модели всё пучком, и в драйвере - тогда это становится веселее

https://github.com/Xilinx/dma_ip_drivers/blob/017b4bd985cc776ce75b78fc71cfa6bef6afd890/XDMA/linux-kernel/xdma/xdma_cdev.c#L605 - везде слова cdev, интуитивно кажется cdev = char device

[gosha-z 2]

53 minutes ago, AVR said:

везде слова cdev, интуитивно кажется cdev = char device

Разумеется character. Block device там не нужен, ла и character нужен только для того, чтобы ioctl кидать да mmap сделать

[Doka 1]

On 8/13/2020 at 11:07 AM, gosha-z said:

Я же говорил, алгоритм другой:

1. Открываем chardev

2. Через ioctl запрашиваем максимальный размер блока памяти, который драйвер уже распределил

3. Делаем mmap без предварительного malloc, получаем адрес этого блока в userspace

4. Встаем в epoll-цикл, ждем, когда драйвер нам скажет "Готово, забирай"

read подразумевает под собой копирование данных kernel space -> user space, что есть накладные расходы

Дошёл  я до этой стадии поэтому доп.вопросы:

 

1. Какой таймаут при вызове epoll_wait  задавать?.. милиссикунды - слишком много, либо задавать 0 и использовать нанослип()?

 

 

 

2. не могу уловить в моём кейсе правильнее будет использовать epoll с событиями по уровню или по фронту. интуитивно кажется, что надо по фронту, но хотелось бы проверить себя

 

 

3. достаточно ли  epoll_wait или надо использовать вариант функции epoll_pwait ?

 

4. ну и конечно самый концептуальный вопрос: как соотнести выбор таймаута (для epoll_wait), размера пакета и требуемой пропускной способности?!

Мне надо принять (и передать at the same time) порядка 1 ГБайт/с, выбрал размер пакета 4КБ, но чувствуется его придётся поднимать (агреггировать пакеты в ПЛИС, складывая в один большой), чтобы добиться такой прорускной способности.

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

 

 

 

 

[gosha-z 2]

epoll_wait отваливается по таймауту если не было никаких других событий в этом наборе дескрипторов. Какой вам нужен - зависит от вашей задачи. На скорость передачи это не влияет.

[Doka 1]

On 8/13/2020 at 11:07 AM, gosha-z said:

read подразумевает под собой копирование данных kernel space -> user space, что есть накладные расходы

что это означает?.. не использовать read или альтернатив read всёже нет?!

(примеров epoll без read|write в сети найти не удалось)

11 minutes ago, gosha-z said:

epoll_wait отваливается по таймауту если не было никаких других событий в этом наборе дескрипторов. Какой вам нужен - зависит от вашей задачи. На скорость передачи это не влияет.

тут есть варианты:

минимальное время 1мс - как мне кажется, это ОЧЕНЬ много, выходит либо использовать "0" и нанослип() либо вообще ставить "-1"

[gosha-z 2]

poll - это всего лишь, образно говоря, некий флаг, который означает, есть данные или нет. Он никоим образом не определяет способ, каким вы эти данные заберете.

[xvr 12]

On 8/20/2020 at 9:26 PM, Doka said:

либо вообще ставить "-1"

Именно так. epoll должен работать без таймаутов в отдельной нитке исполнения. Она должна заниматься исключительно приёмом данных (ну можно ещё попутной обработкой). Всё, что не зависит от данных с карты, должно исполняться в других нитях.

 

NB. Если поток данных с FPGA очень большой, то работа по прерываниям может не сдюжить по требуемым временным ресурсам, придётся делать програмный поллинг (он быстрее, но жрёт 100% CPU)

[Doka 1]

8 hours ago, xvr said:

epoll должен работать без таймаутов в отдельной нитке исполнения. Она должна заниматься исключительно приёмом данных (ну можно ещё попутной обработкой). Всё, что не зависит от данных с карты, должно исполняться в других нитях.

спасибо, это ценная информация.

уточню: нить исполнения - это те функции, что описаны в threads.h так?

 

8 hours ago, xvr said:

NB. Если поток данных с FPGA очень большой, то работа по прерываниям может не сдюжить по требуемым временным ресурсам, придётся делать програмный поллинг (он быстрее, но жрёт 100% CPU)

вот тут как раз интересен практический опыт в разрезе выбора размера пакета для транзакций по PCI-E:выберешь маленький - перегруз процессора по утилизации ресурсов (поллинг), либо вообще пропажа пакетов, а выберешь большой -  увеличивается latency всей цепочки (отправить на ускоритель, обработать, принять с ускорителя), что тоже нехорошо.

 

В реальном кейсе надо принять (и передать at the same time) порядка 1 ГБайт/с,  размер пакета 4КБ наверное будет маловать для "безбедной жизни" на среднем процессоре, но как научиться выбирать такие вещи не ставя множество натурных экспериментов, а эмпирически?!

[RobFPGA 27]

Приветствую!

28 minutes ago, Doka said:

...

вот тут как раз интересен практический опыт в разрезе выбора размера пакета для транзакций по PCI-E:выберешь маленький - перегруз процессора по утилизации ресурсов (поллинг), либо вообще пропажа пакетов, а выберешь большой -  увеличивается latency всей цепочки (отправить на ускоритель, обработать, принять с ускорителя), что тоже нехорошо.

В реальном кейсе надо принять (и передать at the same time) порядка 1 ГБайт/с,  размер пакета 4КБ наверное будет маловать для "безбедной жизни" на среднем процессоре, но как научиться выбирать такие вещи не ставя множество натурных экспериментов, а эмпирически?!

Вопрос не в размере пакета по PCIe  - вопрос в организации  буферов DMA на стороне хоста  -  При стриме данных кольцевой буфер дескрипторов делится на блоки (установкой соответствующих флагов в дескрипторах) только по окончанию пересылки которых и генерируется прерывание.  Размер боков  выбирается исходя из  потока и желаемой/максимальной частоты прерывания.   Как именно  будет организованно вычитка данных  - через копирование из kernel space или  zero-copy через мапинг  user-space памяти в пространство драйвера не столь важно (естественно при достаточной скорости CPU).  Для  обычной системы можно за ориентир брать 500-1000  прерываний в сек.   Для хороших  серверных систем  и до 10К IRQ/s.  Но без экcэкспериментов увы не обойтись.     

 

У меня по такой схеме работало несколько систем с непрерывным потоком 3-6 GByte/s 

 

Удачи! Rob.

[new123 0]

11 hours ago, Doka said:

) порядка 1 ГБайт/с

мне кажется, при pcie x8 gen3 (не смог найти, какой вы pcie собираете), траффик слабый. Можно легко на прерываниях делать. И размер дескриптора 256 байт.
Я на свой поллинг в отдельном ядре CPU c 100% загрузкой перешел, когда надо было два 10гб порта с высокой нагрузкой в такой pcie пихать. И пришлось размер дескпритора до 512 поднять, чтобы драйвер сильно очередями не нагружать.

Изменено 26 августа, 2020 пользователем new123

[RobFPGA 27]

Приветствую!

23 minutes ago, new123 said:

мне кажется, при pcie x8 gen3 (не смог найти, какой вы pcie собираете), траффик слабый. Можно легко на прерываниях делать. И размер дескриптора 256 байт.
Я на свой поллинг перешел, когда надо было два 10гб порта с высокой нагрузкой в такой pcie пихать. И пришлось размер дескпритора до 512 поднять, чтобы драйвер сильно очередями не нагружать.

1 ГБайт/с  это как раз поток с одной  10G  в одну сторону.  Прерывание после каждого дескриптора в 256 байт?  4M IRQ/s  ??? 
Скорее  всего тут недопонимание  что такое этот "дескриптор"  и его размер.  И опять же тип PCie не играет тут особой роли - это только показывает макс лимит трафика которой вы теоретически можете  прогнать по шине. 

 

Для  выбора  оптимальной схемы работы DMA  важно  понимать  общую картину (схему) dataflow.  Кто шлет данные,  с какой периодичностью, как эти данные группированы, средний/пиковый трафик, требования к latency, ...    

 

Удачи!  Rob.

[xvr 12]

14 hours ago, Doka said:

уточню: нить исполнения - это те функции, что описаны в threads.h так?

Да

14 hours ago, Doka said:

В реальном кейсе надо принять (и передать at the same time) порядка 1 ГБайт/с,

Это немного

14 hours ago, Doka said:

размер пакета 4КБ наверное будет маловать для "безбедной жизни"

А это маловато :)

 

В прерываниях самое плохое их латентность - обработка прерывания + доставка его на User Space (в виде пробуждения нити исполнения) довольно медленный процесс (особенно доставка в User Space)

14 hours ago, Doka said:

но как научиться выбирать такие вещи не ставя множество натурных экспериментов, а эмпирически?!

Никак. Процессоры совершенствуются, ОС тоже развиваются. Несколько лет назад проводили замеры латентности прерываний (на Linux, насколько помню) - порядка нескольких десятков ms (10-20)

Стройте систему так, что бы латентность прерываний не была на критическом пути

 

 

[new123 0]

2 hours ago, RobFPGA said:

1 ГБайт/с  это как раз поток с одной  10G  в одну сторону

ой да, спасибо, мельком прочитал Гбит

2 hours ago, RobFPGA said:

Прерывание после каждого дескриптора в 256 байт?  4M IRQ/s  ??? 
Скорее  всего тут недопонимание  что такое этот "дескриптор"  и его размер

да, я делал после каждого дескриптора. В среднем подсчитал, что средний размер получаемого пакета для моих задач 160-190байт. Подумал 256 байт на дескриптор dma хватит. Но в критические очень моменты, tcp заходит по 1500 байт пачками и пришлось поднять до 512 байт на дескриптор, чтобы кольцо дескприпторов не так быстро заполнялось.

Делать прерывание не после каждого дескриптора, а после накопления N дескрипторов не совсем мой вариант, поэтому перешел на свой поллинг.

[dxp 32]

26.08.2020 в 04:15, RobFPGA сказал:

установкой соответствующих флагов в дескрипторах, только по окончанию пересылки которых и генерируется прерывание

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

[RobFPGA 27]

Приветствую!

55 minutes ago, dxp said:

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

Ну так классика - добавить сюда  еще  таймер чтобы генерировал прерывание по timeout если буфер не пуст но и не заполнен до порога, и будет классический interrupt-coalescin.

В хороших  сетевых картах  это еще дополняется динамической подстройкой timeout и переключением с IRQ на поолинг  при разных нагрузках если требуется малый latency.  

 

Удачи! Rob.