|
|
Subscribe / Log in / New account

Checksum offloads and protocol ossification

Checksum offloads and protocol ossification

Posted Dec 13, 2015 7:02 UTC (Sun) by drag (guest, #31333)
Parent article: Checksum offloads and protocol ossification

This was posted a while ago to a lwn comments. Sorry I forget who posted it, but it's a good one:

http://highscalability.com/blog/2013/5/13/the-secret-to-1...

Basically:

If you want to 'really scale' then the best thing you can do is ignore the kernel and perform as much networking as possible in your application. Other people have mentioned some of the userspace network drivers that by-pass the kernel implementation in the comments in this article already.

Seems to me that if people really want the 'bestest fastest lowest latencinest performance' from their TCP stack for specialized application then going about it by a hardware-based offload of TCP/IP seems to be the wrong approach. The right approach is to use a application-level network driver and let the application due the calculations. If you want to throw hardware acceleration at the problem then have it be something that applications can use to help accelerate the calculations they need to do rather then something that hides in a nic card.

Then if the kernel is involved at all then all it should do is provide a reasonable method for those applications to access the 'acceleration hardware' via some sort of mechanism like DRM drivers do.

As far as tunneling goes.. as much as I love things like vxlan they really seem to be mostly used to work around IPv4 addressing limits. A much better approach seems to be things like let your virtualmachines/containers/etc get their own ipv6 address automatically and then rely on level 3 routing to deliver packets to everything. Any tunneling going on should just be IPv6 over IPv4 udp as a stop gap solution to deal with shitty 'cloud' networks. Otherwise you can just end up with tunnels in tunnels in tunnels and nobody wants that. Anything 'container/virt' infrastructure that doesn't integrate service discovery (and/or 'VIPS' or whatever) to help services and clients find things automatically is just a half-assed solution anyways, which means that it makes the difficulty of dealing with 'static' ipv6 addresses and dhcp mute. If done correctly there is no reason at all that end users should be aware that they are using ipv6 or ipv4.

oh well. Never had good luck with 'offload engines' anyways.


to post comments

Checksum offloads and protocol ossification

Posted Jan 14, 2016 6:53 UTC (Thu) by marcH (subscriber, #57642) [Link]

> If you want to 'really scale' then the best thing you can do is ignore the kernel and perform as much networking as possible in your application. Other people have mentioned some of the userspace network drivers that by-pass the kernel implementation in the comments in this article already.

Another (closed source) example: http://ats.aeroflex.com/virtualized-ip-test-solutions/pro...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds