Re:Intel's make-or-break 18A process node debuts for data ce...
by jeffbee on Tuesday March 03, 2026 @03:36PM
(#47238594)
There definitely are bottlenecks. The one I always think of is the kernel's networking stack. There's no sense in using the kernel TCP stack when you have hundreds of independent workloads. That doesn't make any more sense than it would have made 20 years ago to have an external TCP appliance at the top of your rack. Userspace protocol stacks win.
[ Parent
| on HN ]
Re:Intel's make-or-break 18A process node debuts for data ce...
by rishabhaiover on Tuesday March 03, 2026 @04:35PM
(#47239372)
io_uring?
Re:Intel's make-or-break 18A process node debuts for data ce...
by jeffbee on Tuesday March 03, 2026 @04:58PM
(#47239637)
If anything, uring makes the problem much worse by reducing the cost of one process flooding kernel internals in a single syscall.
Re:Intel's make-or-break 18A process node debuts for data ce...
by fc417fc802 on Tuesday March 03, 2026 @06:34PM
(#47240696)
Do the partitioned stacks of network namespaces share a single underlying global stack or are they fully independent instances? (And if not, could they be made so?)
Re:Intel's make-or-break 18A process node debuts for data ce...
by wmf on Tuesday March 03, 2026 @06:58PM
(#47240975)
Usually network namespaces are linked together with a single bridge so you can get lock contention there.
If you have a separate physical NIC for each namespace you probably won't have any contention.
Re:Intel's make-or-break 18A process node debuts for data ce...
by jeffbee on Tuesday March 03, 2026 @07:19PM
(#47241191)
I think you could get much of the way there by isolating a single NIC's receive queues, so the kernel doesn't decide to run off and service softirqs for random foreign tasks just because your task called tcp_sendmsg.
Re:Intel's make-or-break 18A process node debuts for data ce...
by otabdeveloper4 on Wednesday March 04, 2026 @12:12AM
(#47243364)
> Userspace protocol stacks win.
No they don't. They are horribly wasteful and inefficient compared to kernel TCP. Also they are useless because they sit on top of a kernel network interface anyways.
Unless you're doing specific tricks to minimize latency (HFT, I guess?) then there is no point.