6 ms·

The Linux network stack needs to get its shit in order. Kernel bypass libraries like EVFI transmit UDP in 250ns whereas the kernel typically takes several usec

The Linux network stack needs to get its shit in order. Kernel bypass libraries like EVFI transmit UDP in 250ns whereas the kernel typically takes several usec. Transitioning into kernel space shouldn’t take that long so a lot of needless instructions must be getting executed.

baybal2 8y ago
Linux net stack is tooo fat, and have to support a gazillion features that are only needed by less than 10 companies in the world each. That's lack of leadership for you... Kernel people should be pushing back more on such features
- syn0byte 8y ago
  Why would they stop companies from contributing optional code to Linux for their products when you can just (not) compile what you want of it? The linux eco-system does not begin and end with a RHEL/Ubuntu binary distribution built to run on every crappy PC in the last decade.
  - baybal2 8y ago
    1. not all minority feature commits are config disableable 2. focus - kernel keeps accumulating abandonware code for gimmick features/drivers
ignoramous 8y ago
For any meaningful elastic deployment at scale, Linux's (or rather any OS) TCP/IP stack will have to be bypassed through user-space programs: It has all of the upsides and few of the downsides. Ref: https://opennetworking.org https://opennetworking.org Not just the datacenters, but even 5G deployments, which would be exclusively IPv6 based, would sport user-space processing of packets and flows. Ref: https://opencord.org https://opencord.org
- CoolGuySteve 8y ago
  Exactly my point, the kernel shouldn’t have to be bypassed. It should just be fast.
  - ignoramous 8y ago
    (not an expert, just someone keeping abreast with development in the networking world) There are inherent problems with relying on the OS in an elastic environment. Kernel's TCP/IP stack could be made to expose very specific APIs to help with NetworkFunctionVirtualization (NFV) and Software-defined Networking (SDN), but the advantages are not clear: 1. Vendors to rely on Kernel devs to do the their biding for their NFV/SDN deployments, and wrestle with various other priorities Kernel might already have. 2. Build/deploy the updated Kernel fleet wide, with those changes (which now include other Kernel changes vendor may or may not want). 3. Cater to strict Kernel community guidelines and expect to be driven by the established processes governed by designated gatekeepers, costing vendors time and speed to market. With a userspace solution, esp since it allows vendors to be performant by simply interfacing with NICs, the vendors have a measure of control on their own destiny: 1. Deploy at will, at pace. 2. Ability to do custom packet/flow (virtualization), on-the-fly (SDN) even, without requiring any assistance from any other part of the system not in their control. 3. Reduce external factors that might influence their timelines or priorities. The generic problem, however, with the Kernel's TCP/IP stack needing improvement is orthogonal to this. That effort will have little to no bearing on the direction the Networking industry is moving, imo. --- Google Maglev (network load balancer): https://ai.google/research/pubs/pub44824 https://ai.google/research/pubs/pub44824 Dropbox MagicPocket (bypassing OS' VirtualFileSystem for storage at scale): https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/ https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pock... Facebook Haystack (an example of problems working with VFS at scale and a solution to it): https://code.fb.com/core-data/needle-in-a-haystack-efficient-storage-of-billions-of-photos/ https://code.fb.com/core-data/needle-in-a-haystack-efficient... NFV: https://www.electronics-notes.com/articles/connectivity/nfv-network-functions-virtualisation/what-is-nfv-basics.php https://www.electronics-notes.com/articles/connectivity/nfv-... VNF: https://www.electronics-notes.com/articles/connectivity/nfv-network-functions-virtualisation/virtualized-network-functions-vnf.php https://www.electronics-notes.com/articles/connectivity/nfv-...

baybal2 8y ago

Linux net stack is tooo fat, and have to support a gazillion features that are only needed by less than 10 companies in the world each. That's lack of leadership for you... Kernel people should be pushing back more on such features

syn0byte 8y ago
Why would they stop companies from contributing optional code to Linux for their products when you can just (not) compile what you want of it? The linux eco-system does not begin and end with a RHEL/Ubuntu binary distribution built to run on every crappy PC in the last decade.
- baybal2 8y ago
  1. not all minority feature commits are config disableable 2. focus - kernel keeps accumulating abandonware code for gimmick features/drivers

ignoramous 8y ago

For any meaningful elastic deployment at scale, Linux's (or rather any OS) TCP/IP stack will have to be bypassed through user-space programs: It has all of the upsides and few of the downsides. Ref: https://opennetworking.org https://opennetworking.org Not just the datacenters, but even 5G deployments, which would be exclusively IPv6 based, would sport user-space processing of packets and flows. Ref: https://opencord.org https://opencord.org

CoolGuySteve 8y ago
Exactly my point, the kernel shouldn’t have to be bypassed. It should just be fast.
- ignoramous 8y ago
  (not an expert, just someone keeping abreast with development in the networking world) There are inherent problems with relying on the OS in an elastic environment. Kernel's TCP/IP stack could be made to expose very specific APIs to help with NetworkFunctionVirtualization (NFV) and Software-defined Networking (SDN), but the advantages are not clear: 1. Vendors to rely on Kernel devs to do the their biding for their NFV/SDN deployments, and wrestle with various other priorities Kernel might already have. 2. Build/deploy the updated Kernel fleet wide, with those changes (which now include other Kernel changes vendor may or may not want). 3. Cater to strict Kernel community guidelines and expect to be driven by the established processes governed by designated gatekeepers, costing vendors time and speed to market. With a userspace solution, esp since it allows vendors to be performant by simply interfacing with NICs, the vendors have a measure of control on their own destiny: 1. Deploy at will, at pace. 2. Ability to do custom packet/flow (virtualization), on-the-fly (SDN) even, without requiring any assistance from any other part of the system not in their control. 3. Reduce external factors that might influence their timelines or priorities. The generic problem, however, with the Kernel's TCP/IP stack needing improvement is orthogonal to this. That effort will have little to no bearing on the direction the Networking industry is moving, imo. --- Google Maglev (network load balancer): https://ai.google/research/pubs/pub44824 https://ai.google/research/pubs/pub44824 Dropbox MagicPocket (bypassing OS' VirtualFileSystem for storage at scale): https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/ https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pock... Facebook Haystack (an example of problems working with VFS at scale and a solution to it): https://code.fb.com/core-data/needle-in-a-haystack-efficient-storage-of-billions-of-photos/ https://code.fb.com/core-data/needle-in-a-haystack-efficient... NFV: https://www.electronics-notes.com/articles/connectivity/nfv-network-functions-virtualisation/what-is-nfv-basics.php https://www.electronics-notes.com/articles/connectivity/nfv-... VNF: https://www.electronics-notes.com/articles/connectivity/nfv-network-functions-virtualisation/virtualized-network-functions-vnf.php https://www.electronics-notes.com/articles/connectivity/nfv-...