The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Google предложил Device Memory TCP для сетевой передачи данных между устройствами"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от opennews (??), 13-Июл-23, 12:11 
Компания Google представила в списке разработчиков ядра Linux реализацию механизма Device memory TCP (devmem TCP), позволяющего напрямую по сети передавать данные из памяти одних устройств в память других устройств, без промежуточного копирования этих данных в буферы, размещённые в системной памяти хоста. Реализация пока находится на стадии RFC, т.е. выставлена для обсуждения и рецензирования сообществом, но не оформлена для передачи в основной состав ядра Linux...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59434

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (1), 13-Июл-23, 12:11 
Разве rdma не этим занимается?
Ответить | Правка | Наверх | Cообщить модератору

3. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (3), 13-Июл-23, 12:15 
А разве RDMA  уже научили из видеопамяти GPU данные передавать? Для RDMA нужно вначале скопировать данные из памяти акселератора в общую память, а именно этого и пытается избежать Google.
Ответить | Правка | Наверх | Cообщить модератору

5. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Страдивариус (?), 13-Июл-23, 12:38 
Эти две памяти в одном адресном пространстве. Какая RDMA разница?
Ответить | Правка | Наверх | Cообщить модератору

8. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (8), 13-Июл-23, 13:00 
А нынче память PCI устройств мапится прямиком в линейное адресное пространство? Там же вроде не всё так просто было вроде.
Ответить | Правка | Наверх | Cообщить модератору

14. "Google предложил Device Memory TCP для сетевой передачи данн..."  –1 +/
Сообщение от Unnamed Player (?), 13-Июл-23, 13:11 
DMA этим и занимается.
Ответить | Правка | Наверх | Cообщить модератору

22. "Google предложил Device Memory TCP для сетевой передачи данн..."  –1 +/
Сообщение от Аноним (22), 13-Июл-23, 13:25 
для PCI нету DMA, зато есть bus mastering.
Ответить | Правка | Наверх | Cообщить модератору

51. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (51), 13-Июл-23, 15:48 
Щито? У PCI DMA есть и прекрасно работает (как бы иначе им, например, сетевыми пользовались, или они в твоём мире на на PCI шине висят?). Более того, на базе p2p dma работает майковский direct storage для игруль (там, правда, dma между nvme и gpu).
Ответить | Правка | Наверх | Cообщить модератору

84. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (84), 14-Июл-23, 01:35 
> для PCI нету DMA, зато есть bus mastering.

Вот те раз - кто это DMA у него с314дил? А bus mastering это возможность со стороны девайса транзакции инициировать - передавая данные например в другой девайс без участия системного проца в этом. При такой инверсии ролей вопрос DMA оказывается на другой стороне... и у GPU например есть свои нехилые DMA-движки на его стороне, на такие случаи и много что еще, оффлоадящие основной массив от уделения внимания шине.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

90. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Анонним (?), 14-Июл-23, 10:34 
напомню - что DMA controller - это был контроллер на материке подключенный к ISA шине. Который выполнял сам арбитраж шины - для передачи девайс<>память, девайс<>девайс.
в реалиях PCI v2.0+ - централизованного контроллера не существует (с некоторым натягом IO-AT можно считать таковым) - поэтому каждой карте предлагается как-то реализовывать арбитраж самому через режим bus mastering.

Так что эта.. просьба показать DMA controller централизованный в районе PCI root complex - который выполняет теже функции что и старый на ISA. И в PCI spec нету ничего с DMA, зато есть bus mastering. То что через этот режим можно обращаться напрямую в память - ничего не меняет.

Ответить | Правка | Наверх | Cообщить модератору

99. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (-), 14-Июл-23, 15:12 
> напомню - что 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 лишь собирательное название группы технологий где доступ к памяти случется без участия проца.

Ответить | Правка | Наверх | Cообщить модератору

103. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 18:57 
> Это тоже DMA - с другой стороны и другим контроллером. А хост об этом вообще может ничего не знать, единственный критерий чтобы это все не было внезапностью.

В спецификациях - данных режим называется bus mastering. Ибо доступом к памяти он не ограничивается. Если считаете иначе - просьба предоставить линк на мануал по PCI / PCIe шине где это написано. И обсудим.


>DMA контроллеру вообще не обязательно быть в конкретном месте. В типовой системе PCI девайсы висят как регионы памяти в системе, системный DMA может в эти регионы лазить не хуже чем в остальное. Г

Системный DMA ? это какой? - линк на доку в студию. Так что бы там это называлось именно DMA. Если это о IO-AT - спасибо, посмеялся с его пропускной способности.

>PCI уже давно не 2.0 да и вообще Express обычно - и там все стало немного сложнее. Но многие понятия остались.

не многие а все. Если говорить о логической организации шины и транзакциях при передачи.

> А ничего что это тоже получается DMA по смыслу, хоть и иными средствами?  

А ничего что у этого режима есть свое название. Тем более он работает не только с памятью.

Ответить | Правка | Наверх | Cообщить модератору

113. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (-), 16-Июл-23, 01:31 
> В спецификациях - данных режим называется 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 или каким-то конкретным контроллером?

Ответить | Правка | Наверх | Cообщить модератору

21. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 13-Июл-23, 13:24 
если устройство экспортит память в BAR - то да, в линейное адресное пространство.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

95. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Страдивариус (?), 14-Июл-23, 13:21 
> А нынче память PCI устройств мапится прямиком в линейное адресное пространство? Там
> же вроде не всё так просто было вроде.

Нынче? Ну же лет как двадцать. Бывали времена, когда на некоторых железках в адресное пространство CPU торчало только окно из всей памяти устройства и надо было выбирать в какой регион памяти на железке это окно отображается. Я могу ошибаться, но сейчас этим уже никто не занимается, по крайней мере на мощных железках, у которых дохрена памяти на борту.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

91. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от ebanyrust (?), 14-Июл-23, 11:32 
> Разве rdma не этим занимается?

разница в деталях - для RDMA используются специальные сетевые протоколы и работают они минуя сетевой стек ядра, гугловский подход намного универсальней - работает с ядрёным TCP/IP

> Данные загружаются из памяти устройства в payload-буфер сетевой карты при помощи механизма dmabuf, а заголовки переносятся из основной памяти и заполняются системным TCP/IP-стеком.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

94. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от An2 (?), 14-Июл-23, 12:58 
> для RDMA используются специальные сетевые протоколы ... гугловский подход намного универсальней ...
> Ожидается, что Device memory TCP позволит существенно поднять эффективность взаимодействия ...

Обычно "специальные" означает сложнее/неудобнее, но эффективнее чем "универсальные". Как же гуглу удалось обойти этот принцип?

Ответить | Правка | Наверх | Cообщить модератору

96. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от ebanyrust (?), 14-Июл-23, 13:28 
> Как же гуглу удалось обойти этот принцип?

payload загружается через DMA, заголовок обрабатывается центральным процессором - что непонятно в этом принципе ? полезных данных на порядки больше чем служебных данных из заголовка. На таком же принципе весь dmabuf - буфер с данными для аппаратного DMA + служебная информация для CPU.

Ответить | Правка | Наверх | Cообщить модератору

98. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 14:52 
не понятно все. Никто кроме Mellanox такой финт ушами сделать не даст.
Для передачи можно делать, для приема - нет.
Ответить | Правка | Наверх | Cообщить модератору

102. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от ebanyrust (?), 14-Июл-23, 15:40 
> Никто кроме Mellanox такой финт ушами сделать не даст.

гугли NIC with Header Data Split, подозреваю что с 10Gb все поддерживают

Ответить | Правка | Наверх | Cообщить модератору

104. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 19:07 
Нужен не просто 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 для меланокса а не для всех кого можно.

Ответить | Правка | Наверх | Cообщить модератору

106. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от ebanyrust (?), 14-Июл-23, 19:53 
> А для этого режима нужно слегка больше - более похожее на режим работы в 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 автор ничего не говорит

Ответить | Правка | Наверх | Cообщить модератору

107. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 23:11 
да я и неусложняю. Просто так получилось что в этой теме пришлось покопаться достаточно плотно.
Ибо стояла задача поиметь нормальный TCP ZС. Но перелопатив кучи кода и спецификаций - стало понятно что это очень ограничивает набор железа который можно будет использовать.
Хотя я думаю линки на более или менее новые презентации из linux net - должны были вас убедить.


В некотором смысле - да, header split хватит. Когда ты наоборот из адреса буфера получишь адрес внутри GPU и будешь использовать в своей программе. Этакое убогое решение ибо прийдется держать под буфера достаточно много памяти и потом пытаться объединить эти куски в последовательные данные.
Но не о какому удобстве работы который дает GPUfs / GDS (Nvidia) - речи уже не идет.


PS. что люди не придумают лишь бы RoCE v2 не использовать - который это режим даст штатно.
PPS. TCP в этом месте это тихий ужас. Окошко маленькое - reorder пакетов на раз - два, или прийдется отключить selective/delayed ack.

Ответить | Правка | Наверх | Cообщить модератору

115. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (115), 16-Июл-23, 12:08 
> Но не о какому удобстве работы который дает GPUfs / GDS (Nvidia) - речи уже не идет.

то что гугловский патч использует стандартные ядерные интерфейсы вместо вендор-костылей огромный плюс - видимо вендор лок винтеля вас ничему не научил, кактус nvidia кажется слаще  но это ведь до определённой поры.

Ответить | Правка | Наверх | Cообщить модератору

116. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (116), 16-Июл-23, 12:29 
Nvidia дает нормальный POSIX API для работы с файлами из GPU программ. что позволяет обрабатывать на GPU объемы больше чем память GPU с минимальным простоем. И когда ваш GPU будет стоять и ждать пока вы прочитаете данные и закачаете потом их в память - дабы как-то обработать, GDS закончит обрабатывать весь объем.
Привет тормозам :-)

PS. ты видимо не в курсе что такое GDS и чем он облегчает жизнь.

Ответить | Правка | Наверх | Cообщить модератору

117. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (115), 16-Июл-23, 12:38 
> Nvidia дает нормальный POSIX API для работы с файлами из GPU программ

они так же дают eglstream, только он никому не нужен

> ты видимо не в курсе что такое GDS и чем он облегчает жизнь

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

Ответить | Правка | Наверх | Cообщить модератору

109. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 23:22 
pps. я ниже кидал ссылки на работы Facebook по той же теме. Там тоже завязка на CX4+.
наверно не спроста ?
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

105. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 19:09 
если глянуть в более ранную публикацию
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.

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

2. "Google предложил Device Memory TCP для сетевой передачи данн..."  +13 +/
Сообщение от Аноним (2), 13-Июл-23, 12:14 
> позволяющего напрямую по сети передавать данные из памяти одних устройств в память других устройств

Через центральные гугловские сервера?

Ответить | Правка | Наверх | Cообщить модератору

6. "Google предложил Device Memory TCP для сетевой передачи данн..."  +4 +/
Сообщение от Аноним (6), 13-Июл-23, 12:39 
Through uranus, pal
Ответить | Правка | Наверх | Cообщить модератору

88. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (88), 14-Июл-23, 07:22 
Через хост device-memory-tcp.googleapis.com все будет передаваться
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (4), 13-Июл-23, 12:37 
очень круто. например можно сделать сетевую карту GPU. Если у вас два компа и ноутбук, можно "запускать" видюшку компа на ноутбуке.
Ответить | Правка | Наверх | Cообщить модератору

18. "Google предложил Device Memory TCP для сетевой передачи данн..."  –1 +/
Сообщение от Аноним (18), 13-Июл-23, 13:21 
Очень круто, можно напрямую брать поток из памяти твоей видеокарты, больще не надо троянов, обходов натов и т.д. т.майор сразу получает медаль за организацию схемы :)
Ответить | Правка | Наверх | Cообщить модератору

20. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 13-Июл-23, 13:24 
давай я тебя удивлю - для этого не нужно ничего кроме мелкого модуля подгрузить.
man gdrcopy. И да, для допиливания под AMD практически ничего не надо, для Intel чуть больше всего надо.


Ответить | Правка | Наверх | Cообщить модератору

48. "Google предложил Device Memory TCP для сетевой передачи данн..."  –1 +/
Сообщение от Аноним (48), 13-Июл-23, 15:34 
Господа и товарищи майоры всего мира аплодируют стоя.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

61. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (61), 13-Июл-23, 18:42 
> поднять эффективность взаимодействия в кластерах и распределённых системах машинного обучения

Зачем ты смотришь цэпэ на кластере и распределённой системе машинного обучения?

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

83. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Аноним (83), 13-Июл-23, 22:57 
Это не для смотришь, это набор данных для машинного обучения.
Ответить | Правка | Наверх | Cообщить модератору

26. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Аноним (-), 13-Июл-23, 13:52 
> очень круто. например можно сделать сетевую карту GPU. Если у вас два компа и ноутбук,
> можно "запускать" видюшку компа на ноутбуке.

Еще круче трахнуть тебя по сети через DMA, запатчив сетевым пакетом сразу кернел или гипервизор. Чтобы бац - и в дамки.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

46. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Kuromi (ok), 13-Июл-23, 15:28 
Только не говорите мне что это Штадия 2.0
Хотя идея интересна, позволит окончательно поработить всех по модели Hardware-as-service
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

81. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (81), 13-Июл-23, 22:10 
И Android будет из себя представлять лишь frontend к железу в ангаре гугла через связь 6G.
Ответить | Правка | Наверх | Cообщить модератору

89. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от boo (??), 14-Июл-23, 10:33 
Полоса пропускания памяти Radeon RX 7900 XTX - 960 Гигабайт в секунду. Желаю удачи в постройке сети. С другой стороны, если надо просто изображение и звук перебросить, то для этого уже давным давно есть решения.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. Скрыто модератором  +6 +/
Сообщение от Аноним (7), 13-Июл-23, 12:48 
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  +3 +/
Сообщение от Аноним (10), 13-Июл-23, 13:05 
Ответить | Правка | Наверх | Cообщить модератору

58. Скрыто модератором  +1 +/
Сообщение от Аноним (58), 13-Июл-23, 17:56 
Ответить | Правка | Наверх | Cообщить модератору

15. Скрыто модератором  +/
Сообщение от Аноним (15), 13-Июл-23, 13:12 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

36. Скрыто модератором  +/
Сообщение от Пряник (?), 13-Июл-23, 14:54 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

43. Скрыто модератором  +1 +/
Сообщение от freehckemail (ok), 13-Июл-23, 15:12 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. "Google предложил Device Memory TCP для сетевой передачи данн..."  +7 +/
Сообщение от Аноним (9), 13-Июл-23, 13:04 
Ну т.е. обычных дыр недостаточно. Проще уж напрямую.
Понимаемо, чо.
Ответить | Правка | Наверх | Cообщить модератору

59. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (58), 13-Июл-23, 18:04 
а с учетем нейроинтерфейса, будет коллективная память, под кураторством корпораций добра
Ответить | Правка | Наверх | Cообщить модератору

11. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (11), 13-Июл-23, 13:06 
Правильно, сначала передать бинарник извне, а потом за счёт уязвимостей добиться его выполнения под рутом.
Ответить | Правка | Наверх | Cообщить модератору

13. "Google предложил Device Memory TCP для сетевой передачи данн..."  –2 +/
Сообщение от ZVVZemail (?), 13-Июл-23, 13:10 
протобаф на максималках, хорошо
Ответить | Правка | Наверх | Cообщить модератору

39. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Аноним (39), 13-Июл-23, 15:00 
по сути да: там пакеты и тут пакеты. там по сети и тут тоже
Ответить | Правка | Наверх | Cообщить модератору

16. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Unnamed Player (?), 13-Июл-23, 13:13 
Гугл очередной раз изобретает свой велосипед. RDMA от Гугл
Ответить | Правка | Наверх | Cообщить модератору

23. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Аноним (22), 13-Июл-23, 13:27 
пытается спереть код/идеи FB.
https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E326.../
https://www.phoronix.com/news/Facebook-NetGPU-LPC2020
Ответить | Правка | Наверх | Cообщить модератору

17. Скрыто модератором  +2 +/
Сообщение от Аноним (-), 13-Июл-23, 13:15 
Ответить | Правка | Наверх | Cообщить модератору

19. "Google предложил Device Memory TCP для сетевой передачи данн..."  +2 +/
Сообщение от Аноним (22), 13-Июл-23, 13:22 
Решили спереть идеи Facebook? не взлетит. Будет работать только на железе от NVidia/Mellanox.
Ответить | Правка | Наверх | Cообщить модератору

25. "Google предложил Device Memory TCP для сетевой передачи данн..."  –10 +/
Сообщение от Аноним (25), 13-Июл-23, 13:49 
> Будет работать только на железе от NVidia

Напоминаю, что AMD - это видюха исключительно для игр. Погамать крузис после уроков. Так что NVIDIA достаточно, стандарт индустрии.

Ответить | Правка | Наверх | Cообщить модератору

29. "Google предложил Device Memory TCP для сетевой передачи данн..."  +9 +/
Сообщение от Аноним (29), 13-Июл-23, 13:58 
nvidia — не стандарт, а vendor lockin.
Ответить | Правка | Наверх | Cообщить модератору

32. "Google предложил Device Memory TCP для сетевой передачи данн..."  –6 +/
Сообщение от Аноним (7), 13-Июл-23, 14:27 
Про вендорлок будешь рассказывать, когда у нвидии появится хоть какой-нибудь конкурент. AMD конкурирует с ним максимум за вантузогеймеров.
Ответить | Правка | Наверх | Cообщить модератору

85. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (85), 14-Июл-23, 01:38 
> Про вендорлок будешь рассказывать, когда у нвидии появится хоть какой-нибудь конкурент.
> AMD конкурирует с ним максимум за вантузогеймеров.

Верхушка TOP500 суперкомпьютеров готова с этим нехило поспорить. Кто там, грите, стандарт? :)


Ответить | Правка | Наверх | Cообщить модератору

93. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (22), 14-Июл-23, 11:50 
пока в top500 царствует NVidia. Благодаря тому что пропихнула gdrcopy в MPICH-AV.
Но AMD начала наступать на пятки и то последние года 2.
Ответить | Правка | Наверх | Cообщить модератору

101. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (101), 14-Июл-23, 15:18 
> пока в top500 царствует NVidia.

Царствовала. Когда-то. Понятно что легаси с этого царствия еще осталось.

> Но AMD начала наступать на пятки и то последние года 2.

Ну да, "начала" - новые модели в верхушке TOP500 набиты амд до отказа все как один. И чего это они вдруг?...

Ответить | Правка | Наверх | Cообщить модератору

108. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (22), 14-Июл-23, 23:19 
> Царствовала. Когда-то. Понятно что легаси с этого царствия еще осталось.

И сейчас царствует. 2 из 10 - против 6 из 10 у Nvidia - это царствует ?
При том что фортунер это по сути кластер этого года. NVidia еще не успела ничем ответить.

https://top500.org/lists/top500/2023/06/


> Ну да, "начала" - новые модели в верхушке TOP500 набиты амд до отказа все как один. И чего это они вдруг?...

Не-а. Fortuner это была первая ласточка работы AMD. Но опять же, в нем дофига NVidia на борту, ибо AMD не может предложить ничего похожего на GDS. Что странно - это вопрос чисто либы для ROCm Поэтому Cray/HPe и сидит на двух стульях.

Ответить | Правка | Наверх | Cообщить модератору

114. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (-), 16-Июл-23, 01:43 
> И сейчас царствует. 2 из 10 - против 6 из 10 у Nvidia - это царствует ?

Новые дизайны чего-то идут на AMD.

> При том что фортунер это по сути кластер этого года. NVidia еще
> не успела ничем ответить.

Она уже достаточно поотвечала. Очень интересная компания, которой руководитель проекта операционки которой топ500 набит от и до - факом в камеру при этом слове машет. Казалось бы, что может пойти не так в бизнесе компании при таком раскладе :)

> Не-а. Fortuner это была первая ласточка работы AMD.

По-моему там AMD GPU и на еще нескольких последних топовых есть?

> ROCm Поэтому Cray/HPe и сидит на двух стульях.

Тем не менее, что-то мне подсказывает что нвидию много кто послал бы с превеликим удовольствием. И пошлют, имхо. Собссно уже. В контексте линя это кусок гимора и жоская невозможность багфикса кернелов по линии майнлайн ядерщиков. А это нехилые такие грабли, когда всем причастным на ровном месте дохрена проблем. Оно кому-то надо - делать жабу и тормозизм нвидии своей проблемой?

Ответить | Правка | Наверх | Cообщить модератору

41. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (41), 13-Июл-23, 15:08 
Не-вендорлок AMD сделали ROCm для RDNA3 только спустя почти год после выхода.

Хуже вендор-лока когда вообще не работает ни хрена.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

30. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от keydon (ok), 13-Июл-23, 14:17 
"Стандарты индустрии" это видимо cuda и nvenc. И то и другое отстой и стало стандартом потому что ничего другого тогда не было, а нвидия заносила чемоданы куда нужно. При этом нвидия всегда была дорогой, нестабильной, с отстойными дровами и отстойной поддержкой. К черту такие "стандарты".
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

42. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (41), 13-Июл-23, 15:09 
Покажи мне инструментарий на базе Vulkan Compute, да такой же богатый как на CUDA.
Ответить | Правка | Наверх | Cообщить модератору

49. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним2 (?), 13-Июл-23, 15:36 
Как только покажешь мне инструментарий на базе CUDA без вендорлока и с нормальными опенсурсными дровами.
Ответить | Правка | Наверх | Cообщить модератору

53. "Google предложил Device Memory TCP для сетевой передачи данн..."  –1 +/
Сообщение от Аноним (53), 13-Июл-23, 16:21 
А чо это отстой, если качество и того и другого на порядки превосходит конкурентов? При чём тут чемоданы? Просто кто-то работает, а кто-то на рекламу собственной опенсорсности всё впускает.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

56. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (56), 13-Июл-23, 17:41 
> ничего другого тогда не было, а нвидия заносила чемоданы куда нужно

Я извиняюсь, а зачем нужно было заносить чемоданы, если всё равно ничего другого не было?

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

86. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (86), 14-Июл-23, 03:23 
Тут просто надо во времени рассматривать. Когда cuda появилась она во-первых работала так себе, во-вторых тогда было другое отношение к вычислениям, никто не хотел ввязываться в непонятную вендор-лочную технологию, многим вообще было странно считать что-то на видеокартах, "в конце концов если сильно надо, можно было и через opengl (не opencl, его тогда не было) считать матрицы как для игр". Собственно для этого и нужна была реклама, промоутинг, продвижение в основные продукты, вот это вот все. Потом появились более открытые продукты, тогда еще openCL, тут еще cuda не была таким вот прям стандартом, а была одним из конкурентов. Тоже нужны были деньги чтобы продвигать технологию в нужные продукты и задвигать конкурентов.
Ответить | Правка | Наверх | Cообщить модератору

38. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (39), 13-Июл-23, 14:59 
для индустрии натуралов. разве что. у нормальных людей задачи не ограничиваются тренеровкой модельки в один клик или игрулями
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

50. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним2 (?), 13-Июл-23, 15:39 
Всю жизнь слышу про нормальных людей. То им настройки в файрфокс не нужны, то наоборот им обязательно нужны свои собственные несистемные сертификаты в хроме, то им только винда с игрушками нужна и смартфоны, теперь вот наоборот только и нужно что супермодели тренировать.
Когда уже люди будут говорить за себя, а не искать негров, которым срочно нужно помочь?
Ответить | Правка | Наверх | Cообщить модератору

54. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (39), 13-Июл-23, 16:48 
спроси у сотрудника невидии выше
Ответить | Правка | Наверх | Cообщить модератору

24. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от frac (?), 13-Июл-23, 13:34 
мне одному кажется, что эти товарищи создадут дырень?
возможно даже не дырень, а отверстие с молнией, которая будет прямиком картинки с секретами, явками и паролями кому надо отправлять.
Ответить | Правка | Наверх | Cообщить модератору

27. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (27), 13-Июл-23, 13:54 
не больше, чем ethernet/IP.
Ответить | Правка | Наверх | Cообщить модератору

28. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (29), 13-Июл-23, 13:57 
*ata/ethernet и usb/ip.
Такие вещи в изолированных физически сетях включают. Сказали же - для кластера им нужно. У тебя есть кластер? Если есть, то и сеть выделенная для него есть. Если нет - то мимо. Так же, как и ata/ethernet делали для схд, а не для тебя.
Ответить | Правка | Наверх | Cообщить модератору

31. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от keydon (ok), 13-Июл-23, 14:19 
Ну мне как бы и Device Memory TCP не нужен. Очень уж узкоспециализированное решение получается. Будет ли кто-нибудь кроме гугла его использовать? Может и не место ему в апстриме, пусть у себя на свое ядро патчи и накатывают и сами его поддерживают.
Ответить | Правка | Наверх | Cообщить модератору

34. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (7), 13-Июл-23, 14:32 
> мне как бы и Device Memory TCP не нужен

Что ж ты раньше-то молчал? Пойду скажу пацанам из гугла, что могут закрывать свой RFC, что их усилия напрасны, так как Егорке из Саратова не нужно.

Ответить | Правка | Наверх | Cообщить модератору

47. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним2 (?), 13-Июл-23, 15:32 
Гугл забыл передо мной отчитаться, вот и молчал.
Ответить | Правка | Наверх | Cообщить модератору

45. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (45), 13-Июл-23, 15:18 
> Будет ли кто-нибудь кроме гугла его использовать?

Будет ограниченное число владельцев своего AI. Вот они будут использовать. И продавать сервис другим.

Покупка сервиса, вероятно, будет сродни современной покупке моб.связи.

Запрыгивай с перона в вагон, поехали. Хотя,... тебе ж не нужно.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

37. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (39), 13-Июл-23, 14:58 
как промышленный протокол ethernet/ip связан топиком и что через него должно утекать?
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

82. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (61), 13-Июл-23, 22:57 
Когда хотел выпендриться, но не смог. Индустриальный протокол, про который ты только что вычитал в википедии, правильно называется EtherNet/IP и ты его ни разу в жизни не видел.
Ответить | Правка | Наверх | Cообщить модератору

44. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от freehckemail (ok), 13-Июл-23, 15:14 
> мне одному кажется, что эти товарищи создадут дырень?

да, они как раз и ковыряют специальную дырень, чтобы проталкивать в неё большие объёмы данных
а сейчас у нас -- дырень слишком маленькая )

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

35. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Tron is Whistling (?), 13-Июл-23, 14:33 
Очередная иоурина?
Ответить | Правка | Наверх | Cообщить модератору

66. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от YetAnotherOnanym (ok), 13-Июл-23, 19:55 
Кстати, хорошая мысль. А ещё надо к этой штуке как-то прикрутить eBPF, для полноты счастья.
Ответить | Правка | Наверх | Cообщить модератору

55. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (55), 13-Июл-23, 16:55 
Я правильно понимаю, другими словами скорости передачи данных по самой сети уже ХВАТАЕТ, теперь узкое место это шина PCI?
Ответить | Правка | Наверх | Cообщить модератору

64. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (61), 13-Июл-23, 18:52 
Всё правильно понимаешь. Есть нюансы, но ты про них узнаешь когда-нибудь сам, не буду портить сюрприз.
Ответить | Правка | Наверх | Cообщить модератору

70. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 20:52 
Ну еще потому что много посредников, причем кастомных.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

57. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (57), 13-Июл-23, 17:49 
Облачная видяха. Интересно сколько за гиг для геймеров можно будет арендовать.
Ответить | Правка | Наверх | Cообщить модератору

75. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 20:59 
Скорее видюха с сетевым разьемом
Ответить | Правка | Наверх | Cообщить модератору

76. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (70), 13-Июл-23, 21:07 
Дополнение: И это под лозунгом. чтобы в игры в облаке играть, фильмы в супер качестве смотреть, свой комп обучать из облака. (
По факту - контроль за видео буфером и использование мощности gpu для обучения облачного ИИ.  
Ответить | Правка | Наверх | Cообщить модератору

62. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 18:46 
брандмауэры, контроль трафика. сетевые фильтры и прочее подобное идут лесом?
Ответить | Правка | Наверх | Cообщить модератору

65. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от Аноним (61), 13-Июл-23, 18:53 
Откуда в ML-кластере взялось всё это?
Ответить | Правка | Наверх | Cообщить модератору

68. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 20:46 
подразумевался случай, когда два таких чипа найдут друг друга в сети общего назначения (как IoT)
Ответить | Правка | Наверх | Cообщить модератору

87. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (61), 14-Июл-23, 03:56 
Чем это отличается от двух любых других сетевых устройств, находящихся в одной сети «общего назначения»?
Ответить | Правка | Наверх | Cообщить модератору

63. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 18:48 
В рамках _внутренней_сети_кластера это может иметь смысл.
Ответить | Правка | Наверх | Cообщить модератору

67. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от YetAnotherOnanym (ok), 13-Июл-23, 20:01 
Особый смысл будут иметь эксклюзивные компетенции Гугла по подготовке специально подготовленных наборов данных для ML.
Ответить | Правка | Наверх | Cообщить модератору

69. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 20:50 
Людей формируют по подготовленным паттернам в информационных технологиях. (
Ответить | Правка | Наверх | Cообщить модератору

77. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 21:22 
Подразумевалось не только ML, а что-то подобное _общая_память_кластера_
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

71. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Tron is Whistling (?), 13-Июл-23, 20:52 
Не пора ли для таких вещей таки взять специализированные асики, ы?
Ответить | Правка | Наверх | Cообщить модератору

73. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Аноним (70), 13-Июл-23, 20:55 
встроенные сетевухи есть везде. Остается открыть им прямой доступ к памяти. (
Ответить | Правка | Наверх | Cообщить модератору

74. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Аноним (70), 13-Июл-23, 20:57 
Дополнение: То есть убрать сетевой стэк.
Ответить | Правка | Наверх | Cообщить модератору

79. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Tron is Whistling (?), 13-Июл-23, 22:05 
Тут не о памяти речь, а вообще о третьих устройствах.
Коммуникация PCIe-PCIe в принципе возможна, почему бы для вот таких вот задач, которые нужны в 1.5 вырожденных случаях, не сваять простенький ASIC вместо тонны костылей в ядре.
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

92. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Аноним (22), 14-Июл-23, 11:44 
Она не в принципе возможна, а работает.
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. И которые можно заставить анализировать поток и раскидывать входящие пакеты куда надо.

Ответить | Правка | Наверх | Cообщить модератору

110. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Tron is Whistling (?), 15-Июл-23, 09:13 
Так-то так, но все эти дмабуфы всё равно требуют занятия root complex.
Я про PtP, применение редкое, но в спецификации есть.
Ответить | Правка | Наверх | Cообщить модератору

111. "Google предложил Device Memory TCP для сетевой передачи данных между устройствами"  +/
Сообщение от Tron is Whistling (?), 15-Июл-23, 09:14 
Ключевое слово тут было "мапит" - без root complex не обойтись. А оно в многослотовоых системах узкое место.
Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

72. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (70), 13-Июл-23, 20:53 
Вот работа гугл через добро.
Ответить | Правка | Наверх | Cообщить модератору

78. Скрыто модератором  +/
Сообщение от Аноним (78), 13-Июл-23, 21:25 
Ответить | Правка | Наверх | Cообщить модератору

80. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (81), 13-Июл-23, 22:06 
Ой, да это они лишь для своей Stadia хотят пропихнуть, не более.
Ответить | Правка | Наверх | Cообщить модератору

97. "Google предложил Device Memory TCP для сетевой передачи данн..."  +1 +/
Сообщение от чатжпт (?), 14-Июл-23, 13:32 
с разморозкой, стадия уже упокоилась в январе этого года
Ответить | Правка | Наверх | Cообщить модератору

100. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (100), 14-Июл-23, 15:17 
Гугл что-то последнее время ничего толкового не сделал. Багов в хроме столько детских, что даже не смешно уже. Ничего быстрого последнее время не делали, а только тормозное все. Вроде большая компания и сильные программеры, но в совокупности говно почему -то на выходе
Ответить | Правка | Наверх | Cообщить модератору

112. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от Аноним (112), 15-Июл-23, 23:11 
Что-то мне это напоминает очередной заход гугола к афедрону пользователя.
Уд гугла стоит, а афедрон пользователя уже смазан рекламой)))))
Ответить | Правка | Наверх | Cообщить модератору

119. "Google предложил Device Memory TCP для сетевой передачи данн..."  +/
Сообщение от bOOster (ok), 19-Июл-23, 06:11 
А обычный аппаратный DMA слабо гуглу использовать? Опять "велосипед" необходим?

Хотя гугл очередной раз изобретает... Но теперь уже PlayStation 3.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру