forum.opennet.ru - "Google предложил Device Memory TCP для сетевой передачи данных между устройствами" (113)

"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ообщить модератору

Оглавление

Разве rdma не этим занимается , Аноним (1), 12:11 , 13-Июл-23, (1)

А разве RDMA уже научили из видеопамяти GPU данные передавать Для RDMA нужно в, Аноним (3), 12:15 , 13-Июл-23, (3)

Эти две памяти в одном адресном пространстве Какая RDMA разница , Страдивариус (?), 12:38 , 13-Июл-23, (5)

А нынче память PCI устройств мапится прямиком в линейное адресное пространство , Аноним (8), 13:00 , 13-Июл-23, (8)

DMA этим и занимается , Unnamed Player (?), 13:11 , 13-Июл-23, (14) –1

для PCI нету DMA, зато есть bus mastering , Аноним (22), 13:25 , 13-Июл-23, (22) –1

Щито У PCI DMA есть и прекрасно работает как бы иначе им, например, сетевыми п, Аноним (51), 15:48 , 13-Июл-23, (51)
Вот те раз - кто это DMA у него с314дил А bus mastering это возможность со стор, Аноним (84), 01:35 , 14-Июл-23, (84) +1

напомню - что DMA controller - это был контроллер на материке подключенный к ISA, Анонним (?), 10:34 , 14-Июл-23, (90)

Напомню что многие PCI железки сейчас являют собой нефиговый программно аппаратн, Аноним (-), 15:12 , 14-Июл-23, (99)

В спецификациях - данных режим называется bus mastering Ибо доступом к памяти о, Аноним (22), 18:57 , 14-Июл-23, (103)

Не отменяет возможность устройств лезть в память Поэтому Согласно википедии, , Аноним (-), 01:31 , 16-Июл-23, (113)

если устройство экспортит память в BAR - то да, в линейное адресное пространство, Аноним (22), 13:24 , 13-Июл-23, (21)
Нынче Ну же лет как двадцать Бывали времена, когда на некоторых железках в адр, Страдивариус (?), 13:21 , 14-Июл-23, (95)

разница в деталях - для RDMA используются специальные сетевые протоколы и работа, ebanyrust (?), 11:32 , 14-Июл-23, (91) +1

Обычно специальные означает сложнее неудобнее, но эффективнее чем универсальн, An2 (?), 12:58 , 14-Июл-23, (94)

payload загружается через DMA, заголовок обрабатывается центральным процессором , ebanyrust (?), 13:28 , 14-Июл-23, (96) +1

не понятно все Никто кроме Mellanox такой финт ушами сделать не даст Для переда, Аноним (22), 14:52 , 14-Июл-23, (98)

гугли NIC with Header Data Split, подозреваю что с 10Gb все поддерживают, ebanyrust (?), 15:40 , 14-Июл-23, (102)

Нужен не просто Header Data Split, в том то и дело Split означает что ты ложишь , Аноним (22), 19:07 , 14-Июл-23, (104)

не надо усложнятьhttps lore kernel org lkml 20230710223304 1174642-1-almasrymi, ebanyrust (?), 19:53 , 14-Июл-23, (106)

да я и неусложняю Просто так получилось что в этой теме пришлось покопаться дос, Аноним (22), 23:11 , 14-Июл-23, (107)

то что гугловский патч использует стандартные ядерные интерфейсы вместо вендор-к, Аноним (115), 12:08 , 16-Июл-23, (115)

Nvidia дает нормальный POSIX API для работы с файлами из GPU программ что позво, Аноним (116), 12:29 , 16-Июл-23, (116)

они так же дают eglstream, только он никому не нуженобычный вендорлок, не удивит, Аноним (115), 12:38 , 16-Июл-23, (117)

pps я ниже кидал ссылки на работы Facebook по той же теме Там тоже завязка на , Аноним (22), 23:22 , 14-Июл-23, (109)

если глянуть в более ранную публикациюhttps netdevconf info 0x14 pub slides 62, Аноним (22), 19:09 , 14-Июл-23, (105)

Через центральные гугловские сервера , Аноним (2), 12:14 , 13-Июл-23, (2) +13

Through uranus, pal, Аноним (6), 12:39 , 13-Июл-23, (6) +4
Через хост device-memory-tcp googleapis com все будет передаваться, Аноним (88), 07:22 , 14-Июл-23, (88) +1

очень круто например можно сделать сетевую карту GPU Если у вас два компа и но, Аноним (4), 12:37 , 13-Июл-23, (4) +1

Очень круто, можно напрямую брать поток из памяти твоей видеокарты, больще не на, Аноним (18), 13:21 , 13-Июл-23, (18) –1

давай я тебя удивлю - для этого не нужно ничего кроме мелкого модуля подгрузить , Аноним (22), 13:24 , 13-Июл-23, (20)
Господа и товарищи майоры всего мира аплодируют стоя , Аноним (48), 15:34 , 13-Июл-23, (48) –1
Зачем ты смотришь цэпэ на кластере и распределённой системе машинного обучения , Аноним (61), 18:42 , 13-Июл-23, (61)

Это не для смотришь, это набор данных для машинного обучения , Аноним (83), 22:57 , 13-Июл-23, (83) +2

Еще круче трахнуть тебя по сети через DMA, запатчив сетевым пакетом сразу кернел, Аноним (-), 13:52 , 13-Июл-23, (26) +2
Только не говорите мне что это Штадия 2 0Хотя идея интересна, позволит окончател, Kuromi (ok), 15:28 , 13-Июл-23, (46) +2

И Android будет из себя представлять лишь frontend к железу в ангаре гугла через, Аноним (81), 22:10 , 13-Июл-23, (81) +1

Полоса пропускания памяти Radeon RX 7900 XTX - 960 Гигабайт в секунду Желаю уда, boo (??), 10:33 , 14-Июл-23, (89) +2

Скрыто модератором, Аноним (7), 12:48 , 13-Июл-23, (7) +6

Скрыто модератором, Аноним (10), 13:05 , 13-Июл-23, (10) +3

Скрыто модератором, Аноним (58), 17:56 , 13-Июл-23, (58) +1

Скрыто модератором, Аноним (15), 13:12 , 13-Июл-23, (15)
Скрыто модератором, Пряник (?), 14:54 , 13-Июл-23, (36)
Скрыто модератором, freehck (ok), 15:12 , 13-Июл-23, (43) +1

Ну т е обычных дыр недостаточно Проще уж напрямую Понимаемо, чо , Аноним (9), 13:04 , 13-Июл-23, (9) +7

а с учетем нейроинтерфейса, будет коллективная память, под кураторством корпорац, Аноним (58), 18:04 , 13-Июл-23, (59) +1

Правильно, сначала передать бинарник извне, а потом за счёт уязвимостей добиться, Аноним (11), 13:06 , 13-Июл-23, (11)
протобаф на максималках, хорошо, ZVVZ (?), 13:10 , 13-Июл-23, (13) –2

по сути да там пакеты и тут пакеты там по сети и тут тоже, Аноним (39), 15:00 , 13-Июл-23, (39) +2

Гугл очередной раз изобретает свой велосипед RDMA от Гугл, Unnamed Player (?), 13:13 , 13-Июл-23, (16) +1

пытается спереть код идеи FB https lore kernel org netdev 6376CA34-BC6F-45DE-, Аноним (22), 13:27 , 13-Июл-23, (23) +2

Скрыто модератором, Аноним (-), 13:15 , 13-Июл-23, (17) +2
Решили спереть идеи Facebook не взлетит Будет работать только на железе от NVi, Аноним (22), 13:22 , 13-Июл-23, (19) +2

Напоминаю, что AMD - это видюха исключительно для игр Погамать крузис после уро, Аноним (25), 13:49 , 13-Июл-23, (25) –10

nvidia 8212 не стандарт, а vendor lockin , Аноним (29), 13:58 , 13-Июл-23, (29) +9

Про вендорлок будешь рассказывать, когда у нвидии появится хоть какой-нибудь кон, Аноним (7), 14:27 , 13-Июл-23, (32) –6

Верхушка TOP500 суперкомпьютеров готова с этим нехило поспорить Кто там, грите,, Аноним (85), 01:38 , 14-Июл-23, (85) +1

пока в top500 царствует NVidia Благодаря тому что пропихнула gdrcopy в MPICH-AV, Аноним (22), 11:50 , 14-Июл-23, (93) +1

Царствовала Когда-то Понятно что легаси с этого царствия еще осталось Ну да, , Аноним (101), 15:18 , 14-Июл-23, (101)

И сейчас царствует 2 из 10 - против 6 из 10 у Nvidia - это царствует При том ч, Аноним (22), 23:19 , 14-Июл-23, (108)

Новые дизайны чего-то идут на AMD Она уже достаточно поотвечала Очень интересна, Аноним (-), 01:43 , 16-Июл-23, (114)

Не-вендорлок AMD сделали ROCm для RDNA3 только спустя почти год после выхода Хуж, Аноним (41), 15:08 , 13-Июл-23, (41)

Стандарты индустрии это видимо cuda и nvenc И то и другое отстой и стало стан, keydon (ok), 14:17 , 13-Июл-23, (30)

Покажи мне инструментарий на базе Vulkan Compute, да такой же богатый как на CUD, Аноним (41), 15:09 , 13-Июл-23, (42) +1

Как только покажешь мне инструментарий на базе CUDA без вендорлока и с нормальны, Аноним2 (?), 15:36 , 13-Июл-23, (49) +1

А чо это отстой, если качество и того и другого на порядки превосходит конкурент, Аноним (53), 16:21 , 13-Июл-23, (53) –1
Я извиняюсь, а зачем нужно было заносить чемоданы, если всё равно ничего другого, Аноним (56), 17:41 , 13-Июл-23, (56) +1

Тут просто надо во времени рассматривать Когда cuda появилась она во-первых раб, Аноним (86), 03:23 , 14-Июл-23, (86)

для индустрии натуралов разве что у нормальных людей задачи не ограничиваются , Аноним (39), 14:59 , 13-Июл-23, (38)

Всю жизнь слышу про нормальных людей То им настройки в файрфокс не нужны, то на, Аноним2 (?), 15:39 , 13-Июл-23, (50) +1

спроси у сотрудника невидии выше, Аноним (39), 16:48 , 13-Июл-23, (54)

мне одному кажется, что эти товарищи создадут дырень возможно даже не дырень, а , frac (?), 13:34 , 13-Июл-23, (24) +1

не больше, чем ethernet IP , Аноним (27), 13:54 , 13-Июл-23, (27)

ata ethernet и usb ip Такие вещи в изолированных физически сетях включают Сказ, Аноним (29), 13:57 , 13-Июл-23, (28)

Ну мне как бы и Device Memory TCP не нужен Очень уж узкоспециализированное реше, keydon (ok), 14:19 , 13-Июл-23, (31)

Что ж ты раньше-то молчал Пойду скажу пацанам из гугла, что могут закрывать сво, Аноним (7), 14:32 , 13-Июл-23, (34) +1

Гугл забыл передо мной отчитаться, вот и молчал , Аноним2 (?), 15:32 , 13-Июл-23, (47)

Будет ограниченное число владельцев своего AI Вот они будут использовать И про, Аноним (45), 15:18 , 13-Июл-23, (45)

как промышленный протокол ethernet ip связан топиком и что через него должно уте, Аноним (39), 14:58 , 13-Июл-23, (37)

Когда хотел выпендриться, но не смог Индустриальный протокол, про который ты то, Аноним (61), 22:57 , 13-Июл-23, (82)

да, они как раз и ковыряют специальную дырень, чтобы проталкивать в неё большие , freehck (ok), 15:14 , 13-Июл-23, (44) +1

Очередная иоурина , Tron is Whistling (?), 14:33 , 13-Июл-23, (35) +1

Кстати, хорошая мысль А ещё надо к этой штуке как-то прикрутить eBPF, для полно, YetAnotherOnanym (ok), 19:55 , 13-Июл-23, (66) +1

Я правильно понимаю, другими словами скорости передачи данных по самой сети уже , Аноним (55), 16:55 , 13-Июл-23, (55) +1

Всё правильно понимаешь Есть нюансы, но ты про них узнаешь когда-нибудь сам, не, Аноним (61), 18:52 , 13-Июл-23, (64) +1
Ну еще потому что много посредников, причем кастомных , Аноним (70), 20:52 , 13-Июл-23, (70)

Облачная видяха Интересно сколько за гиг для геймеров можно будет арендовать , Аноним (57), 17:49 , 13-Июл-23, (57)

Скорее видюха с сетевым разьемом, Аноним (70), 20:59 , 13-Июл-23, (75)

Дополнение И это под лозунгом чтобы в игры в облаке играть, фильмы в супер кач, Аноним (70), 21:07 , 13-Июл-23, (76) +1

брандмауэры, контроль трафика сетевые фильтры и прочее подобное идут лесом , Аноним (70), 18:46 , 13-Июл-23, (62)

Откуда в ML-кластере взялось всё это , Аноним (61), 18:53 , 13-Июл-23, (65) +1

подразумевался случай, когда два таких чипа найдут друг друга в сети общего назн, Аноним (70), 20:46 , 13-Июл-23, (68)

Чем это отличается от двух любых других сетевых устройств, находящихся в одной с, Аноним (61), 03:56 , 14-Июл-23, (87)

В рамках _внутренней_сети_кластера это может иметь смысл , Аноним (70), 18:48 , 13-Июл-23, (63)

Особый смысл будут иметь эксклюзивные компетенции Гугла по подготовке специально, YetAnotherOnanym (ok), 20:01 , 13-Июл-23, (67)

Людей формируют по подготовленным паттернам в информационных технологиях , Аноним (70), 20:50 , 13-Июл-23, (69)
Подразумевалось не только ML, а что-то подобное _общая_память_кластера_ , Аноним (70), 21:22 , 13-Июл-23, (77)

Не пора ли для таких вещей таки взять специализированные асики, ы , Tron is Whistling (?), 20:52 , 13-Июл-23, (71)

встроенные сетевухи есть везде Остается открыть им прямой доступ к памяти , Аноним (70), 20:55 , 13-Июл-23, (73)

Дополнение То есть убрать сетевой стэк , Аноним (70), 20:57 , 13-Июл-23, (74)
Тут не о памяти речь, а вообще о третьих устройствах Коммуникация PCIe-PCIe в пр, Tron is Whistling (?), 22:05 , 13-Июл-23, (79)

Она не в принципе возможна, а работает man gdrcopy man gds и man dma-buf и ку, Аноним (22), 11:44 , 14-Июл-23, (92)

Так-то так, но все эти дмабуфы всё равно требуют занятия root complex Я про PtP,, Tron is Whistling (?), 09:13 , 15-Июл-23, (110)
Ключевое слово тут было мапит - без root complex не обойтись А оно в многосло, Tron is Whistling (?), 09:14 , 15-Июл-23, (111)

Вот работа гугл через добро , Аноним (70), 20:53 , 13-Июл-23, (72)
Скрыто модератором, Аноним (78), 21:25 , 13-Июл-23, (78)
Ой, да это они лишь для своей Stadia хотят пропихнуть, не более , Аноним (81), 22:06 , 13-Июл-23, (80)

с разморозкой, стадия уже упокоилась в январе этого года, чатжпт (?), 13:32 , 14-Июл-23, (97) +1

Гугл что-то последнее время ничего толкового не сделал Багов в хроме столько де, Аноним (100), 15:17 , 14-Июл-23, (100)
Что-то мне это напоминает очередной заход гугола к афедрону пользователя Уд гугл, Аноним (112), 23:11 , 15-Июл-23, (112)
А обычный аппаратный DMA слабо гуглу использовать Опять велосипед необходим Х, bOOster (ok), 06:11 , 19-Июл-23, (119)

Сообщения [Сортировка по времени | 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 +/–

Сообщение от freehck (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 +/–

Сообщение от ZVVZ (?), 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 +/–

Сообщение от freehck (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

И содержимое вашей памяти будет течь... прямо в google
xD

Ответить | Правка | Наверх | 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору