[dmitry-tomsk 0]

1 hour ago, faa said:

Есть проект wupper на opencores. Работает. Под 6 ГБ/сек на Gen3 x8 по DMA выдает. Больше нам не надо было.

Драйвера и софт в комплекте. В драйвере надо надо включить pci bus master - там этого нет :)

У нас работает на xilinx Kintex 7 (XC7Z045) и US (XCKU085). Правда, под 45 Zynq пришлось переписывать довольно много.

Но там есть фича - каждую TLP пытается писать по следующему свободному дескриптору. Но это довольно просто лечится.

Спасибо! А под windows драйвер есть?

[faa 4]

29 минут назад, dmitry-tomsk сказал:

Спасибо! А под windows драйвер есть?

Нет. Это ж Церн ;)

Наши драйвер виндовый сами писали. Там все довольно просто.

Но под виндой 96МБ dma буфер только был. Больше 7-ка не дает сделать.

А под линуксом на х86_64 до 1ГБ на дескриптор через hugepage-1GB. И scatter-gather не нужен.

Родной драйвер cmem тоже работает, но с hugepage программистам проще показалось.

Нужно только конвертировать адреса из virt в phys через ioctl.

И да, cmem на больших размерах буфера очень долго их может выделять (пока он непрерывного пространства страничками по 4К наберет).

 

[dmitry-tomsk 0]

6 minutes ago, faa said:

Нет. Это ж Церн ;)

Наши драйвер виндовый сами писали. Там все довольно просто.

Но под виндой 96МБ dma буфер только был. Больше 7-ка не дает сделать.

А под линуксом на х86_64 до 1ГБ на дескриптор через hugepage-1GB. И scatter-gather не нужен.

Родной драйвер cmem тоже работает, но с hugepage программистам проще показалось.

Нужно только конвертировать адреса из virt в phys через ioctl.

И да, cmem на больших размерах буфера очень долго их может выделять (пока он непрерывного пространства страничками по 4К наберет).

 

Спасибо, понял. С большим куском непрервной памяти проблемы всегда были, поэтому я хотел сделать очередь из 256k буферов непрервной памяти. Под линукс вроде можно сразу в gpu писать, а под виндой всё равно через память придётся

[faa 4]

31 минуту назад, dmitry-tomsk сказал:

Спасибо, понял. С большим куском непрервной памяти проблемы всегда были, поэтому я хотел сделать очередь из 256k буферов непрервной памяти. Под линукс вроде можно сразу в gpu писать, а под виндой всё равно через память придётся

Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись.

[dmitry-tomsk 0]

6 minutes ago, faa said:

Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись.

Я вот тоже хотел под линукс, но у нас алгритмисты пишут на Matlab через gpuArray,  какой там прямой доступ к памяти, по-моему проще алгоритм на ultrascale opencv переписать с ускорением в плис.

[dxp 33]

4 часа назад, dmitry-tomsk сказал:

Простой ход чтобы не попадать на границу rcb - первый запрос выравнивающий, если материнка поддерживает пакет только 128 байт, например, адрес заканчивается на 126, сначала шлём или запрашиваем 2 байта, а остальные - полные 128, кроме последнего.

У нас хост поддерживает MPS в 256 байт и MRRS в 512 байт, а RCB 64 байта. При этом CplD получаются разного размера, я проводил эксперимент, и результат такой: шлётся MRd на полный размер (на самом деле там на полную страницу, но контроллер должен порубить на MRRS размеры, т.е. сами MRd улетают на 512 байт), первый Cpld прилетает 64, следующий тоже на 64, потом на 128 и последний на 256.

 

Финт с "выравнивающим" запросом ничего не решает - всё равно придётся "склеивать" эти два байта последующими CplD, сдвигая байты на потоке. Например, слово данных 128 бит,  16 байт, приняли 2 байта в первом ("выравнивающем ") CplD, потом приходит 64 байта (4 слова) в следующем CplD, чтобы объединить данные, нужно взять первые 14 байт из первого слова, сдвинуть их на два байта и объединить с теми двумя байтами, что приняли раньше. Оставшиеся два байта этого первого слова надо сдвинуть на 14 байт, и повторить операцию со вторым словом, и т.д. Если ещё и CplD летят вперемешку от разных MRd, то вообще весело. И надо отслеживать, когда MRd закончен, т.е. прилетели все CplD. И надо отслеживать, когда прилетели все MRd, т.е. исходный запрос к контроллеру с прикладного уровня завершён, и данные можно отдавать. Всё это отнюдь не просто.

 

4 часа назад, dmitry-tomsk сказал:

Вместо работы со страницами 4k, проще выделить 4-8 буферов неперывной памяти 256k + запасик и выровнять начальный физический адрес по границе 128 или 256 байт

А что это даст? Вы не можете метать запросы, которые пересекают границу 4к. И не важно, непрерывная там память или нет. Любой запрос (MWr или MRd), который пересекает границу 4к (т.е. адрес + длина накрывают границу), считается Malformed, а это Fatal error, такое недопустимо. Если с прикладного уровня приходит такой запрос, то его надо разбивать на два запроса PCIe, и в случае чтения потом склеивать уже на уровне PCIe слов (32 бита), тоже двигая в потоке, но уже не байты, а 32-разрядные слова.

[dmitry-tomsk 0]

9 minutes ago, dxp said:

У нас хост поддерживает MPS в 256 байт и MRRS в 512 байт, а RCB 64 байта. При этом CplD получаются разного размера, я проводил эксперимент, и результат такой: шлётся MRd на полный размер (на самом деле там на полную страницу, но контроллер должен порубить на MRRS размеры, т.е. сами MRd улетают на 512 байт), первый Cpld прилетает 64, следующий тоже на 64, потом на 128 и последний на 256.

 

Финт с "выравнивающим" запросом ничего не решает - всё равно придётся "склеивать" эти два байта последующими CplD, сдвигая байты на потоке. Например, слово данных 128 бит,  16 байт, приняли 2 байта в первом ("выравнивающем ") CplD, потом приходит 64 байта (4 слова) в следующем CplD, чтобы объединить данные, нужно взять первые 14 байт из первого слова, сдвинуть их на два байта и объединить с теми двумя байтами, что приняли раньше. Оставшиеся два байта этого первого слова надо сдвинуть на 14 байт, и повторить операцию со вторым словом, и т.д. Если ещё и CplD летят вперемешку от разных MRd, то вообще весело. И надо отслеживать, когда MRd закончен, т.е. прилетели все CplD. И надо отслеживать, когда прилетели все MRd, т.е. исходный запрос к контроллеру с прикладного уровня завершён, и данные можно отдавать. Всё это отнюдь не просто.

 

А что это даст? Вы не можете метать запросы, которые пересекают границу 4к. И не важно, непрерывная там память или нет. Любой запрос (MWr или MRd), который пересекает границу 4к (т.е. адрес + длина накрывают границу), считается Malformed, а это Fatal error, такое недопустимо. Если с прикладного уровня приходит такой запрос, то его надо разбивать на два запроса PCIe, и в случае чтения потом склеивать уже на уровне PCIe слов (32 бита), тоже двигая в потоке, но уже не байты, а 32-разрядные слова.

Я уже не помню тонконстей выравнивания, у меня быы fifo интерфейс  - 32 бита на вход - 32 на выход без byte enable. Сдвиговые регистры помню были, значит внутри слова выранивались байты.

 

По памяти это много даст. 4k страница в виндах получается когда делаешь lock памяти из user space. Куча дескрипторов, которые нужно где то хранить или подкачивать. А второй вариант - это кускок непрерывной физической памяти, но небольшой, как правило, не больше 1 мбайта. Для такого варианта все tlp имеют max payload size, пересечения 4k исключены.

В своё премя я смотрел со стороны плис, как выглядят пакеты после lock - первый и последний не выровнены, остальные выровнены по границе 4k

[new123 0]

1 hour ago, faa said:

А под линуксом на х86_64 до 1ГБ на дескриптор

а на плисине такие дескрипторы где лежат? в ddr?

[faa 4]

4 минуты назад, new123 сказал:

а на плисине такие дескрипторы где лежат? в ddr?

в триггерах. Там 8 дескрипторов всего.

[dmitry-tomsk 0]

Кто-нибудь пробовал такие макетки для pcie?

 

https://aliexpress.ru/item/1005003142993313.html?_1ld=3120413_1&_randl_currency=RUB&_randl_shipto=RU&acnt=4173237791&aff_platform=jvru&aff_short_key=brxT3bLh&albad=481188168148&albag=110288398221&albagn=mbag&albch=dspl&albcp=11664845271&albkwd=pla-325425753764&campaignName=JVRU_CM_ALI_WEBall_RU_UA_sTRADE_ROAS_TOPSALEDIRECT_0_Perform&cn=11664845271&dp=EAIaIQobChMIu_XB5MyE9QIVHQmiAx0gWwaNEAEYASABEgISgvD_BwE&feed_id=191&gclid=EAIaIQobChMIu_XB5MyE9QIVHQmiAx0gWwaNEAEYASABEgISgvD_BwE&isdl=y&netw=u&sellermenu_hide=true&sku_id=12000024326506506&src=googleweb&tracelog=googleweb_jvru_mbag_11664845271&utm_campaign=JVRU_CM_ALI_WEBall_RU_UA_sTRADE_ROAS_TOPSALEDIRECT_0_Perform&utm_medium=mbag_cpc&utm_source=google

 

 

[dxp 33]

9 часов назад, dmitry-tomsk сказал:

Для такого варианта все tlp имеют max payload size, пересечения 4k исключены.

В общем случае адрес произвольный и длина тоже. Поэтому можно легко попасть на комбинацию адрес/данные, когда будет пересечение. Например, запрос с адреса (младшие биты) 0xfffc на, например, всего-то 16 байт. Вот и попались Тут нужно будет разбивать на две транзакции 4 байта + 12 байт. И если слово данных, например, те же 128 бит (16 байт), то сдвиги данных по стриму встают в полный рост.

[blackfin 16]

13 hours ago, faa said:

Под 6 ГБ/сек на Gen3 x8 по DMA выдает. Больше нам не надо было.

Как-то противоречит сказанному ранее:

On 4/7/2018 at 8:57 PM, faa said:

Из шишек: замирание PCIe, при пиковой (расчетной) для Gen3 x8 более 6ГБ/сек (даже при TLP128) для 4.8ГБ/сек имели некоторые неудобства.

Пришлось городить эластик-буфер и резать лишнее ;).

Или это уже другой проект? :)

[faa 4]

3 часа назад, blackfin сказал:

Как-то противоречит сказанному ранее:

Или это уже другой проект? :)

Почти тот же. А в чем противоречие? ;)

Что на Интеле были замирания?

Заменили хосты на EPYC 7002 и все стало хор и ок. Замираний нет, рестартов нет, потерь нет. Аптаймы - пока не выключишь.

Тут еще AMD дает утилитку интересную. Ну и тюнинг сервера нужен, у AMD есть рекомендации.

[new123 0]

13 hours ago, faa said:

Там 8 дескрипторов всего.

если это дескрипторы, как в понимании DMA, я бы на 8 со своей нагрузкой фиг справился. У альтеры их 128, пришлось временами до сайза 512 байт подымать, чтоб потерь на sfp не было. 

А так конечно можно и 8 до гигабайта каждый раздуть, но это прям наверное задержки серьезные

Изменено 28 декабря, 2021 пользователем new123

[dmitry-tomsk 0]

5 hours ago, dxp said:

В общем случае адрес произвольный и длина тоже. Поэтому можно легко попасть на комбинацию адрес/данные, когда будет пересечение. Например, запрос с адреса (младшие биты) 0xfffc на, например, всего-то 16 байт. Вот и попались Тут нужно будет разбивать на две транзакции 4 байта + 12 байт. И если слово данных, например, те же 128 бит (16 байт), то сдвиги данных по стриму встают в полный рост.

Где же я попался? Первый запрос выравнивающий - 4 байта, последний - неполный. Остальные по 128 байт. Раньше материнки только 128 поддерживали, да и можно payload size принудительно ограничить в самой плис. Ну или учесть.