Компания Google представила в списке разработчиков ядра Linux реализацию механизма Device memory TCP (devmem TCP), позволяющего напрямую по сети передавать данные из памяти одних устройств в память других устройств, без промежуточного копирования этих данных в буферы, размещённые в системной памяти хоста. Реализация пока находится на стадии RFC, т.е. выставлена для обсуждения и рецензирования сообществом, но не оформлена для передачи в основной состав ядра Linux...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59434
Разве rdma не этим занимается?
А разве RDMA уже научили из видеопамяти GPU данные передавать? Для RDMA нужно вначале скопировать данные из памяти акселератора в общую память, а именно этого и пытается избежать Google.
Эти две памяти в одном адресном пространстве. Какая RDMA разница?
А нынче память PCI устройств мапится прямиком в линейное адресное пространство? Там же вроде не всё так просто было вроде.
DMA этим и занимается.
для PCI нету DMA, зато есть bus mastering.
Щито? У PCI DMA есть и прекрасно работает (как бы иначе им, например, сетевыми пользовались, или они в твоём мире на на PCI шине висят?). Более того, на базе p2p dma работает майковский direct storage для игруль (там, правда, dma между nvme и gpu).
> для PCI нету DMA, зато есть bus mastering.Вот те раз - кто это DMA у него с314дил? А bus mastering это возможность со стороны девайса транзакции инициировать - передавая данные например в другой девайс без участия системного проца в этом. При такой инверсии ролей вопрос DMA оказывается на другой стороне... и у GPU например есть свои нехилые DMA-движки на его стороне, на такие случаи и много что еще, оффлоадящие основной массив от уделения внимания шине.
напомню - что DMA controller - это был контроллер на материке подключенный к ISA шине. Который выполнял сам арбитраж шины - для передачи девайс<>память, девайс<>девайс.
в реалиях PCI v2.0+ - централизованного контроллера не существует (с некоторым натягом IO-AT можно считать таковым) - поэтому каждой карте предлагается как-то реализовывать арбитраж самому через режим bus mastering.Так что эта.. просьба показать DMA controller централизованный в районе PCI root complex - который выполняет теже функции что и старый на ISA. И в PCI spec нету ничего с DMA, зато есть bus mastering. То что через этот режим можно обращаться напрямую в память - ничего не меняет.
> напомню - что DMA controller - это был контроллер на материке подключенный
> к ISA шине. Который выполнял сам арбитраж шины - для передачи
> девайс<>память, девайс<>девайс.Напомню что многие PCI железки сейчас являют собой нефиговый программно аппаратный комплекс, с своим софтом, процами, памятью и адресными пространствами, а то и VM/paging/mmu, и чем там еще. И в этом смысле DMA может быть и с их стороны, в том смысле что оно не отвлекается на каждую операцию с шиной - а заряжает такой же хардварный автомат со своей стороны, и дальше тот интерфейс шины секвенсит все как надо для вон того сам, так что процы железки не отвлекаются на каждый дерг PCI. Это тоже DMA - с другой стороны и другим контроллером. А хост об этом вообще может ничего не знать, единственный критерий чтобы это все не было внезапностью.
> в реалиях PCI v2.0+ - централизованного контроллера не существует (с некоторым натягом
> IO-AT можно считать таковым) - поэтому каждой карте предлагается как-то реализовывать
> арбитраж самому через режим bus mastering.PCI уже давно не 2.0 да и вообще Express обычно - и там все стало немного сложнее. Но многие понятия остались.
> Так что эта.. просьба показать DMA controller централизованный в районе PCI root
DMA контроллеру вообще не обязательно быть в конкретном месте. В типовой системе PCI девайсы висят как регионы памяти в системе, системный DMA может в эти регионы лазить не хуже чем в остальное. Где этот DMA технически находится и как это по факту реализовано в железе - а какая разница? Соврменных систем где нет DMA <-> PCI я не знаю, такие потоки никто в здравом уме без DMA ворочать не станет.
А вон то про "инверсный" вариант фокуса, когда железка делает на своей стороне оффлоад своим транзакциям, своим DMA контроллером.
> complex - который выполняет теже функции что и старый на ISA.
ISA на PCI вообще не особо похож, расскажите вон тому MIPS с MINI-PCI слотом про нее? А PCI - и DMA там таки есть. И на вон том арме с PCIe сразу из проца - аналогично. И если б оно DMA не умело это был бы ацкий эпикфейл по перфомансу. Так что система без DMA но с PCI - может и возможна теоретически в какой-то ультра минимальной реализации но практически я ни разу такое не встречал.
> И в PCI spec нету ничего с DMA, зато есть bus mastering.
А почему PCI spec должен рассказывать платформе как DMA имплементить? Там в общем случае вывешивают железку как регион памяти - ну а дальше DMA и платформа уже как-нибудь сами разбираются как это. Если вы хотите сказать что теоретически возможна имплементация PCI без DMA контроллера в систему - ну, может быть. Практически я однако такого позора ни разу не видел. Даже на очень мелких платформах. Если железка достаточно большая чтобы PCI(-e) отрастить там гарантированно есть и какие-то DMA контроллеры и они ессно могут с PCI работать, иначе толку с такого PCI...
> То что через этот режим можно обращаться напрямую в память
> - ничего не меняет.А ничего что это тоже получается DMA по смыслу, хоть и иными средствами? DMA означает всего лишь direct memory access. Как именно и чем этот access реализуется - да возможно дочерта вариантов на самом деле. А DMA лишь собирательное название группы технологий где доступ к памяти случется без участия проца.
> Это тоже DMA - с другой стороны и другим контроллером. А хост об этом вообще может ничего не знать, единственный критерий чтобы это все не было внезапностью.В спецификациях - данных режим называется bus mastering. Ибо доступом к памяти он не ограничивается. Если считаете иначе - просьба предоставить линк на мануал по PCI / PCIe шине где это написано. И обсудим.
>DMA контроллеру вообще не обязательно быть в конкретном месте. В типовой системе PCI девайсы висят как регионы памяти в системе, системный DMA может в эти регионы лазить не хуже чем в остальное. ГСистемный DMA ? это какой? - линк на доку в студию. Так что бы там это называлось именно DMA. Если это о IO-AT - спасибо, посмеялся с его пропускной способности.
>PCI уже давно не 2.0 да и вообще Express обычно - и там все стало немного сложнее. Но многие понятия остались.
не многие а все. Если говорить о логической организации шины и транзакциях при передачи.
> А ничего что это тоже получается DMA по смыслу, хоть и иными средствами?
А ничего что у этого режима есть свое название. Тем более он работает не только с памятью.
> В спецификациях - данных режим называется bus mastering. Ибо доступом к памяти
> он не ограничивается.Не отменяет возможность устройств лезть в память. Поэтому...
> Если считаете иначе - просьба предоставить линк на
> мануал по PCI / PCIe шине где это написано. И обсудим.Согласно википедии,
Direct memory access (DMA) is a feature of computer systems that allows certain hardware subsystems to access main system memory independently of the central processing unit (CPU).PCI bus mastering - так может. Значит попадает под определение DMA. В этом определении нет абсолютно ничего про ISA, конкретный контроллер или что либо еще. Только доступ к системной памяти в обход системного проца. Что хотите то с этим и делайте.> Системный DMA ? это какой? - линк на доку в студию.
Это тот который есть в системе. Конкретика может дико варьироваться от системы к системе. PCI вообще платформенно-нейтральная штука и существует много где. Платформ где был бы PCI но не было бы DMA контроллера для разгрузки проца "с другой стороны" - я не знаю. Они теоретически возможны но даже так bus mastering останется формой DMA.
> Так что бы там это называлось именно DMA. Если это о IO-AT
> - спасибо, посмеялся с его пропускной способности.Нет, это не про IO-AT. В самом общем виде я имхо согласен с викой на тему определения что вообще есть DMA. А как оно там в конкретном случае реализовано - да какая разница.
> не многие а все. Если говорить о логической организации шины и транзакциях
> при передачи.Электрически однако он совсем другой. И штуки типа MSI в PCI - не помню, были ли вообще изначально? По-моему нет.
> А ничего что у этого режима есть свое название. Тем более он
> работает не только с памятью.Не отменяет того факта что это тоже вид DMA. Кто сказал что DMA обязан иметь что-то общее с ISA или каким-то конкретным контроллером?
если устройство экспортит память в BAR - то да, в линейное адресное пространство.
> А нынче память PCI устройств мапится прямиком в линейное адресное пространство? Там
> же вроде не всё так просто было вроде.Нынче? Ну же лет как двадцать. Бывали времена, когда на некоторых железках в адресное пространство CPU торчало только окно из всей памяти устройства и надо было выбирать в какой регион памяти на железке это окно отображается. Я могу ошибаться, но сейчас этим уже никто не занимается, по крайней мере на мощных железках, у которых дохрена памяти на борту.
> Разве rdma не этим занимается?разница в деталях - для RDMA используются специальные сетевые протоколы и работают они минуя сетевой стек ядра, гугловский подход намного универсальней - работает с ядрёным TCP/IP
> Данные загружаются из памяти устройства в payload-буфер сетевой карты при помощи механизма dmabuf, а заголовки переносятся из основной памяти и заполняются системным TCP/IP-стеком.
> для RDMA используются специальные сетевые протоколы ... гугловский подход намного универсальней ...
> Ожидается, что Device memory TCP позволит существенно поднять эффективность взаимодействия ...Обычно "специальные" означает сложнее/неудобнее, но эффективнее чем "универсальные". Как же гуглу удалось обойти этот принцип?
> Как же гуглу удалось обойти этот принцип?payload загружается через DMA, заголовок обрабатывается центральным процессором - что непонятно в этом принципе ? полезных данных на порядки больше чем служебных данных из заголовка. На таком же принципе весь dmabuf - буфер с данными для аппаратного DMA + служебная информация для CPU.
не понятно все. Никто кроме Mellanox такой финт ушами сделать не даст.
Для передачи можно делать, для приема - нет.
> Никто кроме Mellanox такой финт ушами сделать не даст.гугли NIC with Header Data Split, подозреваю что с 10Gb все поддерживают
Нужен не просто Header Data Split, в том то и дело.
Split означает что ты ложишь заголовок в один буфер - а данные в другой. И дальше идут 2 фрагмента по стеку. Так умеет очень большое количество карт которые умеют TCP recv offload.
А для этого режима нужно слегка больше - более похожее на режим работы в Infinityband.Ты регистрируешь буфер в сетевой карте и связываешь его с неким идентификатором - и ровно в этом буфере окажутся данные которые туда пришли. Не в произвольном буфере с разделением на header & data. А надо вот в этом конкретный. Это и мешает иметь нормальный zero-copy для приема данных - ибо на момент заполнения буфера - еще не ясно куда его ложить.
Опять же - https://fosdem.org/2023/schedule/event/meta_netdevices/attac...
Слайды 31+ TCP ZC и тп - POC для меланокса а не для всех кого можно.
> А для этого режима нужно слегка больше - более похожее на режим работы в Infinityband.не надо усложнять
https://lore.kernel.org/lkml/20230710223304.1174642-1-almasr.../
> * NIC dependencies:
1. (strict) Devmem TCP require the NIC to support header split, i.e. the
capability to split incoming packets into a header + payload and to put
each into a separate buffer. Devmem TCP works by using dmabuf pages
for the packet payload, and host memory for the packet headers.2. (optional) Devmem TCP works better with flow steering support & RSS support,
i.e. the NIC's ability to steer flows into certain rx queues. This allows the
sysadmin to enable devmem TCP on a subset of the rx queues, and steer
devmem TCP traffic onto these queues and non devmem TCP elsewhere.The NIC I have access to with these properties is the GVE with DQO support
running in Google Cloud, but any NIC that supports these features would suffice.
I may be able to help reviewers bring up devmem TCP on their NICs.кроме обязательной поддержки header split автор ничего не говорит
да я и неусложняю. Просто так получилось что в этой теме пришлось покопаться достаточно плотно.
Ибо стояла задача поиметь нормальный TCP ZС. Но перелопатив кучи кода и спецификаций - стало понятно что это очень ограничивает набор железа который можно будет использовать.
Хотя я думаю линки на более или менее новые презентации из linux net - должны были вас убедить.
В некотором смысле - да, header split хватит. Когда ты наоборот из адреса буфера получишь адрес внутри GPU и будешь использовать в своей программе. Этакое убогое решение ибо прийдется держать под буфера достаточно много памяти и потом пытаться объединить эти куски в последовательные данные.
Но не о какому удобстве работы который дает GPUfs / GDS (Nvidia) - речи уже не идет.
PS. что люди не придумают лишь бы RoCE v2 не использовать - который это режим даст штатно.
PPS. TCP в этом месте это тихий ужас. Окошко маленькое - reorder пакетов на раз - два, или прийдется отключить selective/delayed ack.
> Но не о какому удобстве работы который дает GPUfs / GDS (Nvidia) - речи уже не идет.то что гугловский патч использует стандартные ядерные интерфейсы вместо вендор-костылей огромный плюс - видимо вендор лок винтеля вас ничему не научил, кактус nvidia кажется слаще но это ведь до определённой поры.
Nvidia дает нормальный POSIX API для работы с файлами из GPU программ. что позволяет обрабатывать на GPU объемы больше чем память GPU с минимальным простоем. И когда ваш GPU будет стоять и ждать пока вы прочитаете данные и закачаете потом их в память - дабы как-то обработать, GDS закончит обрабатывать весь объем.
Привет тормозам :-)PS. ты видимо не в курсе что такое GDS и чем он облегчает жизнь.
> Nvidia дает нормальный POSIX API для работы с файлами из GPU программони так же дают eglstream, только он никому не нужен
> ты видимо не в курсе что такое GDS и чем он облегчает жизнь
обычный вендорлок, не удивительно что тут за меланокс топят и не понимают почему гугл универсальные интерфейсы использует - он ведь уже нвидии принадлежит и это один большой сладкий кактус
pps. я ниже кидал ссылки на работы Facebook по той же теме. Там тоже завязка на CX4+.
наверно не спроста ?
если глянуть в более ранную публикацию
https://netdevconf.info/0x14/pub/slides/62/Implementing%...
Ability for a NIC to dissect packets and place header and
data into separate places.
Not all NIC implement header-data split, unfortunately.
Google has for instance a fair amount of servers using Mellanox CX-3 (mlx4)Опять Mellanox.
> позволяющего напрямую по сети передавать данные из памяти одних устройств в память других устройствЧерез центральные гугловские сервера?
Through uranus, pal
Через хост device-memory-tcp.googleapis.com все будет передаваться
очень круто. например можно сделать сетевую карту GPU. Если у вас два компа и ноутбук, можно "запускать" видюшку компа на ноутбуке.
Очень круто, можно напрямую брать поток из памяти твоей видеокарты, больще не надо троянов, обходов натов и т.д. т.майор сразу получает медаль за организацию схемы :)
давай я тебя удивлю - для этого не нужно ничего кроме мелкого модуля подгрузить.
man gdrcopy. И да, для допиливания под AMD практически ничего не надо, для Intel чуть больше всего надо.
Господа и товарищи майоры всего мира аплодируют стоя.
> поднять эффективность взаимодействия в кластерах и распределённых системах машинного обученияЗачем ты смотришь цэпэ на кластере и распределённой системе машинного обучения?
Это не для смотришь, это набор данных для машинного обучения.
> очень круто. например можно сделать сетевую карту GPU. Если у вас два компа и ноутбук,
> можно "запускать" видюшку компа на ноутбуке.Еще круче трахнуть тебя по сети через DMA, запатчив сетевым пакетом сразу кернел или гипервизор. Чтобы бац - и в дамки.
Только не говорите мне что это Штадия 2.0
Хотя идея интересна, позволит окончательно поработить всех по модели Hardware-as-service
И Android будет из себя представлять лишь frontend к железу в ангаре гугла через связь 6G.
Полоса пропускания памяти Radeon RX 7900 XTX - 960 Гигабайт в секунду. Желаю удачи в постройке сети. С другой стороны, если надо просто изображение и звук перебросить, то для этого уже давным давно есть решения.
Моя любимая корпорация снова добавляет улучшения в мое любимое ядро. Нет повода не выпить.
Компания всё для людей старается - вот какая хорошая компания!
самая лучшая компания в мире
Гуглоидов у нас в фирме нет, но праздник это ничем не портит.
Зачем ты уменьшаешь свой потенциал?
> Моя любимая корпорация снова добавляет улучшения в мое любимое ядро. Нет повода не выпить.Любимая компания человека, пьющего с утра. Как им наверное приятно.
Ну т.е. обычных дыр недостаточно. Проще уж напрямую.
Понимаемо, чо.
а с учетем нейроинтерфейса, будет коллективная память, под кураторством корпораций добра
Правильно, сначала передать бинарник извне, а потом за счёт уязвимостей добиться его выполнения под рутом.
протобаф на максималках, хорошо
по сути да: там пакеты и тут пакеты. там по сети и тут тоже
Гугл очередной раз изобретает свой велосипед. RDMA от Гугл
пытается спереть код/идеи FB.
https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E326.../
https://www.phoronix.com/news/Facebook-NetGPU-LPC2020
Когда гуглятина, что-то предлагает мне становится боязно. и возникают мысли "как они хотят нас поиметь?".
Решили спереть идеи Facebook? не взлетит. Будет работать только на железе от NVidia/Mellanox.
> Будет работать только на железе от NVidiaНапоминаю, что AMD - это видюха исключительно для игр. Погамать крузис после уроков. Так что NVIDIA достаточно, стандарт индустрии.
nvidia — не стандарт, а vendor lockin.
Про вендорлок будешь рассказывать, когда у нвидии появится хоть какой-нибудь конкурент. AMD конкурирует с ним максимум за вантузогеймеров.
> Про вендорлок будешь рассказывать, когда у нвидии появится хоть какой-нибудь конкурент.
> AMD конкурирует с ним максимум за вантузогеймеров.Верхушка TOP500 суперкомпьютеров готова с этим нехило поспорить. Кто там, грите, стандарт? :)
пока в top500 царствует NVidia. Благодаря тому что пропихнула gdrcopy в MPICH-AV.
Но AMD начала наступать на пятки и то последние года 2.
> пока в top500 царствует NVidia.Царствовала. Когда-то. Понятно что легаси с этого царствия еще осталось.
> Но AMD начала наступать на пятки и то последние года 2.
Ну да, "начала" - новые модели в верхушке TOP500 набиты амд до отказа все как один. И чего это они вдруг?...
> Царствовала. Когда-то. Понятно что легаси с этого царствия еще осталось.И сейчас царствует. 2 из 10 - против 6 из 10 у Nvidia - это царствует ?
При том что фортунер это по сути кластер этого года. NVidia еще не успела ничем ответить.https://top500.org/lists/top500/2023/06/
> Ну да, "начала" - новые модели в верхушке TOP500 набиты амд до отказа все как один. И чего это они вдруг?...Не-а. Fortuner это была первая ласточка работы AMD. Но опять же, в нем дофига NVidia на борту, ибо AMD не может предложить ничего похожего на GDS. Что странно - это вопрос чисто либы для ROCm Поэтому Cray/HPe и сидит на двух стульях.
> И сейчас царствует. 2 из 10 - против 6 из 10 у Nvidia - это царствует ?Новые дизайны чего-то идут на AMD.
> При том что фортунер это по сути кластер этого года. NVidia еще
> не успела ничем ответить.Она уже достаточно поотвечала. Очень интересная компания, которой руководитель проекта операционки которой топ500 набит от и до - факом в камеру при этом слове машет. Казалось бы, что может пойти не так в бизнесе компании при таком раскладе :)
> Не-а. Fortuner это была первая ласточка работы AMD.
По-моему там AMD GPU и на еще нескольких последних топовых есть?
> ROCm Поэтому Cray/HPe и сидит на двух стульях.
Тем не менее, что-то мне подсказывает что нвидию много кто послал бы с превеликим удовольствием. И пошлют, имхо. Собссно уже. В контексте линя это кусок гимора и жоская невозможность багфикса кернелов по линии майнлайн ядерщиков. А это нехилые такие грабли, когда всем причастным на ровном месте дохрена проблем. Оно кому-то надо - делать жабу и тормозизм нвидии своей проблемой?
Не-вендорлок AMD сделали ROCm для RDNA3 только спустя почти год после выхода.Хуже вендор-лока когда вообще не работает ни хрена.
"Стандарты индустрии" это видимо cuda и nvenc. И то и другое отстой и стало стандартом потому что ничего другого тогда не было, а нвидия заносила чемоданы куда нужно. При этом нвидия всегда была дорогой, нестабильной, с отстойными дровами и отстойной поддержкой. К черту такие "стандарты".
Покажи мне инструментарий на базе Vulkan Compute, да такой же богатый как на CUDA.
Как только покажешь мне инструментарий на базе CUDA без вендорлока и с нормальными опенсурсными дровами.
А чо это отстой, если качество и того и другого на порядки превосходит конкурентов? При чём тут чемоданы? Просто кто-то работает, а кто-то на рекламу собственной опенсорсности всё впускает.
> ничего другого тогда не было, а нвидия заносила чемоданы куда нужноЯ извиняюсь, а зачем нужно было заносить чемоданы, если всё равно ничего другого не было?
Тут просто надо во времени рассматривать. Когда cuda появилась она во-первых работала так себе, во-вторых тогда было другое отношение к вычислениям, никто не хотел ввязываться в непонятную вендор-лочную технологию, многим вообще было странно считать что-то на видеокартах, "в конце концов если сильно надо, можно было и через opengl (не opencl, его тогда не было) считать матрицы как для игр". Собственно для этого и нужна была реклама, промоутинг, продвижение в основные продукты, вот это вот все. Потом появились более открытые продукты, тогда еще openCL, тут еще cuda не была таким вот прям стандартом, а была одним из конкурентов. Тоже нужны были деньги чтобы продвигать технологию в нужные продукты и задвигать конкурентов.
для индустрии натуралов. разве что. у нормальных людей задачи не ограничиваются тренеровкой модельки в один клик или игрулями
Всю жизнь слышу про нормальных людей. То им настройки в файрфокс не нужны, то наоборот им обязательно нужны свои собственные несистемные сертификаты в хроме, то им только винда с игрушками нужна и смартфоны, теперь вот наоборот только и нужно что супермодели тренировать.
Когда уже люди будут говорить за себя, а не искать негров, которым срочно нужно помочь?
спроси у сотрудника невидии выше
мне одному кажется, что эти товарищи создадут дырень?
возможно даже не дырень, а отверстие с молнией, которая будет прямиком картинки с секретами, явками и паролями кому надо отправлять.
не больше, чем ethernet/IP.
*ata/ethernet и usb/ip.
Такие вещи в изолированных физически сетях включают. Сказали же - для кластера им нужно. У тебя есть кластер? Если есть, то и сеть выделенная для него есть. Если нет - то мимо. Так же, как и ata/ethernet делали для схд, а не для тебя.
Ну мне как бы и Device Memory TCP не нужен. Очень уж узкоспециализированное решение получается. Будет ли кто-нибудь кроме гугла его использовать? Может и не место ему в апстриме, пусть у себя на свое ядро патчи и накатывают и сами его поддерживают.
> мне как бы и Device Memory TCP не нуженЧто ж ты раньше-то молчал? Пойду скажу пацанам из гугла, что могут закрывать свой RFC, что их усилия напрасны, так как Егорке из Саратова не нужно.
Гугл забыл передо мной отчитаться, вот и молчал.
> Будет ли кто-нибудь кроме гугла его использовать?Будет ограниченное число владельцев своего AI. Вот они будут использовать. И продавать сервис другим.
Покупка сервиса, вероятно, будет сродни современной покупке моб.связи.
Запрыгивай с перона в вагон, поехали. Хотя,... тебе ж не нужно.
как промышленный протокол ethernet/ip связан топиком и что через него должно утекать?
Когда хотел выпендриться, но не смог. Индустриальный протокол, про который ты только что вычитал в википедии, правильно называется EtherNet/IP и ты его ни разу в жизни не видел.
> мне одному кажется, что эти товарищи создадут дырень?да, они как раз и ковыряют специальную дырень, чтобы проталкивать в неё большие объёмы данных
а сейчас у нас -- дырень слишком маленькая )
Очередная иоурина?
Кстати, хорошая мысль. А ещё надо к этой штуке как-то прикрутить eBPF, для полноты счастья.
Я правильно понимаю, другими словами скорости передачи данных по самой сети уже ХВАТАЕТ, теперь узкое место это шина PCI?
Всё правильно понимаешь. Есть нюансы, но ты про них узнаешь когда-нибудь сам, не буду портить сюрприз.
Ну еще потому что много посредников, причем кастомных.
Облачная видяха. Интересно сколько за гиг для геймеров можно будет арендовать.
Скорее видюха с сетевым разьемом
Дополнение: И это под лозунгом. чтобы в игры в облаке играть, фильмы в супер качестве смотреть, свой комп обучать из облака. (
По факту - контроль за видео буфером и использование мощности gpu для обучения облачного ИИ.
брандмауэры, контроль трафика. сетевые фильтры и прочее подобное идут лесом?
Откуда в ML-кластере взялось всё это?
подразумевался случай, когда два таких чипа найдут друг друга в сети общего назначения (как IoT)
Чем это отличается от двух любых других сетевых устройств, находящихся в одной сети «общего назначения»?
В рамках _внутренней_сети_кластера это может иметь смысл.
Особый смысл будут иметь эксклюзивные компетенции Гугла по подготовке специально подготовленных наборов данных для ML.
Людей формируют по подготовленным паттернам в информационных технологиях. (
Подразумевалось не только ML, а что-то подобное _общая_память_кластера_
Не пора ли для таких вещей таки взять специализированные асики, ы?
встроенные сетевухи есть везде. Остается открыть им прямой доступ к памяти. (
Дополнение: То есть убрать сетевой стэк.
Тут не о памяти речь, а вообще о третьих устройствах.
Коммуникация PCIe-PCIe в принципе возможна, почему бы для вот таких вот задач, которые нужны в 1.5 вырожденных случаях, не сваять простенький ASIC вместо тонны костылей в ядре.
Она не в принципе возможна, а работает.
man gdrcopy / man gds и man dma-buf и куча всего типа 2х видюх в ноутах.Хрень в том что для этого патча и вообще для этих задач не нужны ASIC - ваще.. ваще.
все сетевые карты и так умеют bus master что бы выливать данные из сети в буфера в памяти.
А теперь.. сюрприз.. этот же самый буфер может оказаться в памяти другой карты через режим dma-buf - который мапит BAR0 от другой карты как память а атрибутом память адаптера (так работают все GPU NVidia/AMD и числодробилка Intel).
После чего сетевуха инициируя передачу передает данные не в буфер который в ядре, а в память сетевой карты. Вот тут и начинаются чудеса..С передачей из карты проблем нету никаких. Любая сетевуха это позволит сделать. Берем из pci address и пуляем в внутренний буфер, откуда уходит в сеть. По сути это то что называют TCP send offloading.
С приемом из сети - начинаются вопросы. TCP recv offload это слегка не то... Он не позволяет определять получателя и по нему выбирать буфер куда ложить. Только склеивать фрагменты в один большой буфер.
100% работают карты Mellanox. возможно Broadcom и Intel. Которые поддерживают RoCE v2. И которые можно заставить анализировать поток и раскидывать входящие пакеты куда надо.
Так-то так, но все эти дмабуфы всё равно требуют занятия root complex.
Я про PtP, применение редкое, но в спецификации есть.
Ключевое слово тут было "мапит" - без root complex не обойтись. А оно в многослотовоых системах узкое место.
Вот работа гугл через добро.
И содержимое вашей памяти будет течь... прямо в google
xD
Ой, да это они лишь для своей Stadia хотят пропихнуть, не более.
с разморозкой, стадия уже упокоилась в январе этого года
Гугл что-то последнее время ничего толкового не сделал. Багов в хроме столько детских, что даже не смешно уже. Ничего быстрого последнее время не делали, а только тормозное все. Вроде большая компания и сильные программеры, но в совокупности говно почему -то на выходе
Что-то мне это напоминает очередной заход гугола к афедрону пользователя.
Уд гугла стоит, а афедрон пользователя уже смазан рекламой)))))
А обычный аппаратный DMA слабо гуглу использовать? Опять "велосипед" необходим?Хотя гугл очередной раз изобретает... Но теперь уже PlayStation 3.