Announcement

Collapse
No announcement yet.

Google Posts Experimental Linux Code For "Device Memory TCP" - Network To/From Accelerator RAM

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by gotar View Post
    I didn't say that the QUIC advantages gone, but the (human) "efforts" - in adopting and using it: "QUIC is used by 7.5% of all the websites", mostly (by numbers) low traffic.
    Rolling out new tech took a lot of time, AFAIK openssl does not fully support QUIC yet (wolfssl and rustls does), QUIC in nginx is still under development, though curl does support QUIC (through ngtcp2 and quiche).

    Originally posted by gotar View Post
    I don't think NIC-offloaded TCP is suitable for this - no CoDel, no BBR, no firewall (this at least could be done on the box in the middle), extremely hard diagnostics (timers, keepalives). Not to mention security issues (SYN cookies, DoS by sequence guessing, system uptime guessing etc). I personally wouldn't dare to use it outside of closed network. Even the basic offloads (TSO) are often being disabled, as it cause awkward problems.
    TCP is really complicated and depending on the firmware stack implementation demands vendor support, which suggests it's just another tool for hyperscalers.
    Thanks, then I have no idea why they would need this tech for.

    For compression/encryption, they could use fpga or design dedicated chips, given that they were able to design TPUs it should not be hard for them.

    Comment


    • #32
      Originally posted by NobodyXu View Post
      For compression/encryption, they could use fpga or design dedicated chips, given that they were able to design TPUs it should not be hard for them.
      They might use dedicated NICs then... After all, in huge scales, it's all about power consumption (dedicated chip always outbeats generic CPU) and physical space.

      Comment


      • #33
        Originally posted by gotar View Post

        They might use dedicated NICs then... After all, in huge scales, it's all about power consumption (dedicated chip always outbeats generic CPU) and physical space.
        Yeah, but then I don't understand why they are working on this "Device Memory TCP", if they could have some custom chip that supports RDMA.

        Comment


        • #34
          Apparently they also don't understand it all and took some invalid shortcut, supporting my "intern" theory. Worth noting is that they want the packet headers to be host processed, which basically would exclude TOE. Seems dead-end approach to me. This is indeed GPUDirect RDMA (by Mellanox).

          Comment


          • #35
            Originally posted by Sonadow View Post

            I damn well know what I am talking about.
            https://en.wikipedia.org/wiki/TCP_of...pport_in_Linux
            Besides what gotar said, have you checked the date from that citation?

            No? Let me paste it for you "networking/toe.txt ยท Last modified: 2016/07/19 01:22"

            Almost 7 years ago

            Comment

            Working...
            X