Re:Linux Code for “Device Memory TCP” – Network to/from Acce...
by klabb3 on Sunday July 16, 2023 @06:37AM
(#36745410)
Tcp is also extremely battletested and performs well not just theoretically but in the face of other traffic (congestion) and in many different environments.
Beating TCP reliability and performance is an extremely ambitious endeavor in practice. Add wide interop to that list and it becomes next to impossible.
Re:Linux Code for “Device Memory TCP” – Network to/from Acce...
by rewmie on Sunday July 16, 2023 @08:20AM
(#36746151)
It's also important to have an idea what are the theoretical gains to be had with this work. It would make no sense to mess with infrastructure at this level of the tech stack if the ballpark estimates of potential gains are in the single-digit percent points. In this scenario it would be much more efficient to either go with horizontal scaling or look into the possibility of shaving off some requests.
Re:Linux Code for “Device Memory TCP” – Network to/from Acce...
by jeffbee on Sunday July 16, 2023 @12:27PM
(#36748729)
Sorry, no. At this scale, if google thought they could shave single digits off their cpu costs they would staff a team to do it. If they thought the digit was “9” they would put dozens of people on it.
- is supported everywhere
- allows massive reads and writes (whereas UDP often has quite small limits before packets are dropped)
- is reliable (you wont lose data, your data won't corrupt, etc)
So you could use this inside an existing datacenter, with existing hardware, and existing software to debug and monitor it.
If you send GB of memory, the TCP overhead is minimal.