3 ms·

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

by ufo 12y ago

ori_b 12y ago
For a number of reasons: - It used to be impossible to implement securely. Until very recently, there was no hardware support for virtualizing the network buffers, which would mean emulating the network hardware in userspace. This would be very slow. - Because even today, many devices don't have the required hardware virtualization support. For example, many (most?) ARM devices. If you give direct DMA access, you might be allowing anyone to splatter whatever code they want across whatever memory they want. - Without kernel arbitration of some sort, there's no way to do load balancing across services, throttle, or firewall effectively. - The kernel is designed to provide a uniform interface for all programs to the hardware. Putting networking in userspace gets rid of this abstraction, and means that every program has to be aware of the network hardware; software that works with file descriptors directly can't use the same abstraction for files and network. - Because there are no hardware limitations on the amount of multiplexing. I don't remember how much muxing various hardware supports, but hardware has limits for this sort of thing. If you want more than N processes using the virtual network, you might be SOL with a virtualized userspace network stack.
- vidarh 12y ago
  These are valid objections to in-process access to the networking hardware. Not to running the networking stack in user space, in a privileged process. For the latter, performance concerns would be a bigger issue.
justincormack 12y ago
To multiplex multiple users and applications. Which is less necessary in these days of virtual network devices etc, eg SR-IOV can make a PCI device appear as say 64 network devices so every application can have its own.
thehajime 12y ago
I like the following interview. "One could start arguing about it from the historical viewpoint where network packet creation was a holy operation." https://fosdem.org/2015/interviews/2015-antti-kantee/ https://fosdem.org/2015/interviews/2015-antti-kantee/
yitzhakbg 12y ago
Not a stupid question at all. It's kind of like the question why did we have to program computers in Assembler (which was great fun, BTW) and not in high level languages. It wasn't feasible. Assembly coding did continue for quite some time in the interest of performance but once the proverbial turn is taken, there is no looking back. That's where networking is now. What we still call (rigid) "protocols" should and indeed can become freestanding application code See my paper "Tearing Down the Protocol Wall" at https://www.linkedin.com/in/yitzhakbg#background-publications-container https://www.linkedin.com/in/yitzhakbg#background-publication...

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

by ufo 12y ago

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

ori_b 12y ago

For a number of reasons: - It used to be impossible to implement securely. Until very recently, there was no hardware support for virtualizing the network buffers, which would mean emulating the network hardware in userspace. This would be very slow. - Because even today, many devices don't have the required hardware virtualization support. For example, many (most?) ARM devices. If you give direct DMA access, you might be allowing anyone to splatter whatever code they want across whatever memory they want. - Without kernel arbitration of some sort, there's no way to do load balancing across services, throttle, or firewall effectively. - The kernel is designed to provide a uniform interface for all programs to the hardware. Putting networking in userspace gets rid of this abstraction, and means that every program has to be aware of the network hardware; software that works with file descriptors directly can't use the same abstraction for files and network. - Because there are no hardware limitations on the amount of multiplexing. I don't remember how much muxing various hardware supports, but hardware has limits for this sort of thing. If you want more than N processes using the virtual network, you might be SOL with a virtualized userspace network stack.

vidarh 12y ago
These are valid objections to in-process access to the networking hardware. Not to running the networking stack in user space, in a privileged process. For the latter, performance concerns would be a bigger issue.

justincormack 12y ago

To multiplex multiple users and applications. Which is less necessary in these days of virtual network devices etc, eg SR-IOV can make a PCI device appear as say 64 network devices so every application can have its own.

thehajime 12y ago

I like the following interview. "One could start arguing about it from the historical viewpoint where network packet creation was a holy operation." https://fosdem.org/2015/interviews/2015-antti-kantee/ https://fosdem.org/2015/interviews/2015-antti-kantee/

yitzhakbg 12y ago

Not a stupid question at all. It's kind of like the question why did we have to program computers in Assembler (which was great fun, BTW) and not in high level languages. It wasn't feasible. Assembly coding did continue for quite some time in the interest of performance but once the proverbial turn is taken, there is no looking back. That's where networking is now. What we still call (rigid) "protocols" should and indeed can become freestanding application code See my paper "Tearing Down the Protocol Wall" at https://www.linkedin.com/in/yitzhakbg#background-publications-container https://www.linkedin.com/in/yitzhakbg#background-publication...