Jump to content

    

Recommended Posts

1 hour ago, faa said:

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

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

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

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

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

Share this post


Link to post
Share on other sites
29 минут назад, dmitry-tomsk сказал:

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

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

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

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

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

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

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

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

 

Share this post


Link to post
Share on other sites
6 minutes ago, faa said:

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
31 минуту назад, dmitry-tomsk сказал:

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

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

Share this post


Link to post
Share on other sites
6 minutes ago, faa said:

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

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

Share this post


Link to post
Share on other sites
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-разрядные слова.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
9 часов назад, dmitry-tomsk сказал:

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

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

Share this post


Link to post
Share on other sites
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ГБ/сек имели некоторые неудобства.

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

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

Share this post


Link to post
Share on other sites
3 часа назад, blackfin сказал:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
13 hours ago, faa said:

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

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

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

Edited by new123

Share this post


Link to post
Share on other sites
5 hours ago, dxp said:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.