dmitry-tomsk 0 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 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 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 29 минут назад, dmitry-tomsk сказал: Спасибо! А под windows драйвер есть? Нет. Это ж Церн ;) Наши драйвер виндовый сами писали. Там все довольно просто. Но под виндой 96МБ dma буфер только был. Больше 7-ка не дает сделать. А под линуксом на х86_64 до 1ГБ на дескриптор через hugepage-1GB. И scatter-gather не нужен. Родной драйвер cmem тоже работает, но с hugepage программистам проще показалось. Нужно только конвертировать адреса из virt в phys через ioctl. И да, cmem на больших размерах буфера очень долго их может выделять (пока он непрерывного пространства страничками по 4К наберет). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dmitry-tomsk 0 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 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 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 31 минуту назад, dmitry-tomsk сказал: Спасибо, понял. С большим куском непрервной памяти проблемы всегда были, поэтому я хотел сделать очередь из 256k буферов непрервной памяти. Под линукс вроде можно сразу в gpu писать, а под виндой всё равно через память придётся Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dmitry-tomsk 0 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 6 minutes ago, faa said: Под линуксом мы и пишем прямо в gpu. Только gpu д.б. quadro/tesla/ampere и т.п., где разлочена прямая запись. Я вот тоже хотел под линукс, но у нас алгритмисты пишут на Matlab через gpuArray, какой там прямой доступ к памяти, по-моему проще алгоритм на ultrascale opencv переписать с ускорением в плис. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 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 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 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 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 1 hour ago, faa said: А под линуксом на х86_64 до 1ГБ на дескриптор а на плисине такие дескрипторы где лежат? в ddr? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
faa 4 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба 4 минуты назад, new123 сказал: а на плисине такие дескрипторы где лежат? в ddr? в триггерах. Там 8 дескрипторов всего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dmitry-tomsk 0 27 декабря, 2021 Опубликовано 27 декабря, 2021 · Жалоба Кто-нибудь пробовал такие макетки для 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 56 28 декабря, 2021 Опубликовано 28 декабря, 2021 · Жалоба 9 часов назад, dmitry-tomsk сказал: Для такого варианта все tlp имеют max payload size, пересечения 4k исключены. В общем случае адрес произвольный и длина тоже. Поэтому можно легко попасть на комбинацию адрес/данные, когда будет пересечение. Например, запрос с адреса (младшие биты) 0xfffc на, например, всего-то 16 байт. Вот и попались Тут нужно будет разбивать на две транзакции 4 байта + 12 байт. И если слово данных, например, те же 128 бит (16 байт), то сдвиги данных по стриму встают в полный рост. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 23 28 декабря, 2021 Опубликовано 28 декабря, 2021 · Жалоба 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 28 декабря, 2021 Опубликовано 28 декабря, 2021 · Жалоба 3 часа назад, blackfin сказал: Как-то противоречит сказанному ранее: Или это уже другой проект? :) Почти тот же. А в чем противоречие? ;) Что на Интеле были замирания? Заменили хосты на EPYC 7002 и все стало хор и ок. Замираний нет, рестартов нет, потерь нет. Аптаймы - пока не выключишь. Тут еще AMD дает утилитку интересную. Ну и тюнинг сервера нужен, у AMD есть рекомендации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
new123 0 28 декабря, 2021 Опубликовано 28 декабря, 2021 (изменено) · Жалоба 13 hours ago, faa said: Там 8 дескрипторов всего. если это дескрипторы, как в понимании DMA, я бы на 8 со своей нагрузкой фиг справился. У альтеры их 128, пришлось временами до сайза 512 байт подымать, чтоб потерь на sfp не было. А так конечно можно и 8 до гигабайта каждый раздуть, но это прям наверное задержки серьезные Изменено 28 декабря, 2021 пользователем new123 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dmitry-tomsk 0 28 декабря, 2021 Опубликовано 28 декабря, 2021 · Жалоба 5 hours ago, dxp said: В общем случае адрес произвольный и длина тоже. Поэтому можно легко попасть на комбинацию адрес/данные, когда будет пересечение. Например, запрос с адреса (младшие биты) 0xfffc на, например, всего-то 16 байт. Вот и попались Тут нужно будет разбивать на две транзакции 4 байта + 12 байт. И если слово данных, например, те же 128 бит (16 байт), то сдвиги данных по стриму встают в полный рост. Где же я попался? Первый запрос выравнивающий - 4 байта, последний - неполный. Остальные по 128 байт. Раньше материнки только 128 поддерживали, да и можно payload size принудительно ограничить в самой плис. Ну или учесть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться