400 Gbps is 50 GBps, or 50 bytes per ns. A 100-byte packet comes every 2ns. The bottleneck is not cache bandwidth, it is the number of instructions you have time to execute per unit of I/O: in 6 cycles you will not get to run 24 instructions, especially if you have to wait 3 cycles for your L1 cache.

But you aren't waiting on L1, except in the sense that you're waiting on line fills from main memory. If the problem is that you don't have enough time to do something with the data you're getting, how is that solvable by architectural changes external to the CPU?

In the real world, if you need to deal with 400 Gb/s, you aren't going to send it to a single general-purpose CPU using any type of bus or channel. The CPU won't see it until another ASIC (or FPGA, I suppose) crunches it first.

Yes, that may impose a limit on the speed of an external network that a CPU can deal with, but that's the way it goes. MCA was never going to save us at this end of the Moore's Law curve.

It is only solvable by architectural changes external to the CPU. Even at 40Gbps, which we live with now, that's 20 ns per packet, or 80 ns at a pokey 10Gbps, certainly not enough time to do a system call per packet.

So you need the hardware to divvy traffic up to multiple queues -- rings, really -- and a core for each ring. The packets just show up in memory, and the cores had just better keep up. If that looks to you like the same old POSIX architecture, I don't know what to say.

It was around 2010 that the network pipes got faster than the SAN file servers, and suddenly file output capacity had to be incorporated into network flow control.