The OpenNET Project / Index page

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



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

Оглавление

Google предложил Device Memory TCP для сетевой передачи данных между устройствами, opennews (??), 13-Июл-23, (0) [смотреть все]

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


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

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

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




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

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