Graphics and network stacks are very different. It sounds like macOS is going to have the entire network stack in the kernel except for extensions; this could be the worst of all worlds for performance.
Gotta get rid of all my Mac OS network switches....
I think they value the security and reliability from evicting those kernel extensions and nobody dreams of using this in some high performance production switch so I think it’s ok.
Just to clarify, this would only be a problem if the user had network extensions installed (and potentially lots of them, depending on implementation)? It could have negligible impact if the video editing workstation didn't have these installed, if I'm reading this right?
I'm just saying there's a lot of use cases where people actually saturate their network connections on workstations, and you shouldn't discount them just because 'I'm not running mac as a switch'.
But yes, network perf is needed only for workflows that involve large remote resources, and not to all video editing use cases out there.
You can still saturate your network connection. Just takes a bit of context switching to user land. So if you have a crazy core hyperthreaded cpu your 1 gig network connection will easily get filled without a blink. This is like the ssl argument at the beginning of encrypting everything. The world was going to end and then it didn’t
In certain machines with very weak CPUs and/or many very powerful connections. For a workstation, assuming mild levels of competence, there's no issue.
No, on workstations and servers, particularly in a post spectre world, putting your network drivers into user space will absolutely destroy your perf because of the added context switches.
You'd maybe have a point if it were an L4, but mach ports are used as an example now of how not to do microkernel IPC because of how much overhead they use.
A few thousand context switches per second is minor enough even with spectre mitigations, and if you need more than that you failed the "mild levels of competence" test.
..no, you fundamentally have a 1 to 1 relationship with a core/port with DPDK. And a lot of the use case is very much normal server style work loads, it's not just people running network switches with it.
According to https://blog.selectel.com/introduction-dpdk-architecture-pri... they are largely trying to avoid bottlenecks that exist inside the Linux kernel itself, bottlenecks that happen even with zero context switches. That's a totally different problem. Also to avoid having a system call per packet, which falls under "mild levels of competence" for an API designed this decade. Userspace networking also exists to eke out absolute minimum latency, which you don't need just to saturate a port.
When your only goal is to avoid throughput bottlenecks, you don't need anything fancy. Avoid having a context switch per packet and you're most of the way there. A context switch every millisecond, or something in that order of magnitude, is completely harmless to throughput. If it causes your core to process 10% fewer packets than if it had zero context switches, then use 1.5 cores. Context switches take nothing anywhere near a millisecond each.
> Another factor that negatively affects performance is context switching. When an application in the user space needs to send or receive a packet, it executes a system call. The context is switched to kernel mode and then back to user mode. This consumes a significant amount of system resources.
And they're talking about the socket API, so when they say "a packet" they really mean "any number of packets".
The rest is mainly about metadata that needs to be maintained specifically because kernel and user are in different address spaces and can't directly share in memory data structures, and is additionally exasperated by splitting the device driver away from the network stack like macos is doing.
The only part that isn't ultimately about the user/kernel split and it's costs is the general protocol stuff in the network stack, and that was always the most specious of the claims of DPDK anyway.
Just so you know, you're talking to someone who used to write NAS drivers.
> And they're talking about the socket API, so when they say "a packet" they really mean "any number of packets".
It's completely different if you have one switch per packet vs. one switch per thousand packets.
You're taking things to a ridiculous extreme to imply that any amount of context switching is a deal-breaker. There is a specific number of context switches before you reach 1%, 10%, 50% overhead. There are many reasons to avoid context switches besides overhead, but they are all either based on the underlying implementation or simply not critical to throughput. You're oversimplifying, despite your credentials. The implementation can be changed/fixed without completely purging context switches. There are many tradeoffs, and doing pure user-space is a viable way to approach things, but it's not the only approach.
Memory sharing and metadata slowness is an easy bottleneck to have, but the way you avoid it, by changing data structures and how you talk to different layers of code and the device, can be done whether you put it in the kernel, in pure user space, or split it between the two.
This is the only public place: http://newosxbook.com/bonus/vol1ch16.html. Skywalk is an asynchronous networking interface designed to be adaptable to a number of different needs. I'm not really a networking person so I don't know a lot about it, but mostly the kernel gets out of your way and writes out a bunch of data in a ring buffer of some kind asynchronously or something. The goal is to be able to have different use cases customized to their own needs, so the HTTP stack can write its own custom stuff to be optimized for that use case and the same for the IDS stuff or bluetooth stuff etc. Most people quoted a 30-50% reduction in overall cpu usage for a wide range of scenarios.
Doesn't the network stack end with sending everything to userspace (user applications) in the end anyway? As long as it doesn't take multiple round trips...
Multiple round trips is exactly what I'm concerned about. Imagine a connection going from, say, Safari to the kernel to Little Snitch to the kernel to the NIC. It may not work this way though.
Anything tun-based tends to have the same problem.
All GPU consumers in Windows (AFAIK even OS itself besides the bootloader) are userspace programs calling APIs hence userspace driver isn't a big problem.
The network stack in Windows is a part of the kernel and I haven't heard of userspace implementations of it like DPDK or PF_RING in Linux. GP is wrong about the performance of them though, as you can actually enhance it in a userspace mode (good article from Cloudflare [0]).
