And it's not even the first time Intel has shipped an ARM for this use case; see "Intel StrongARM".

You must be using odd definitions for "properly" and "recently". Intel started volume shipments of 10nm-family parts for laptops in 2019, servers in 2021, and desktops in 2022. They've since moved most of their products off of the 10nm family and onto EUV-based processes: two generations of laptop parts, one generation of desktop parts, and the CPU chiplets of last year's server parts (which still use "Intel 7" for the IO chiplets).

Additionally, the second and third round of desktop parts released on 10nm (aka "Intel 7") are now known to have pushed clocks and voltages somewhat beyond the limits of the process, leading to embarrassing reliability problems and microcode updates that hurt performance. Intel has squeezed everything they can out of their 10nm and have mostly put it behind them, so talking about it like they only recently ramped production is totally wrong about where they are in the lifecycle.

What? Intel has been doing large scale production runs of their 10nm node for years now. If you're talking about Raptor Lake failures, that was one generation of products on that note, there has also never been any indication AFAIK that e.g. Emerald Rapids suffered the same oxidization/voltage failures the consumer line did despite being on the same process node. They're already moving on from all this, really.

Missteps happen but I have a feeling Intel's fab is going to be forced to be near the leading edge one way or another. The US government has plenty of levers to pull to manipulate the global semiconductor market.

This is some quite outdated/interesting hot takes.

it was a good chip. overclocked pretty well.

How, though? Does the TPU team (literally or logically) map to owning IPU h/w successfully?

(I miss having these kinds of convos on twitter as networkservice ;)

The primary customer for this would be infrastructure providers that want to give the host full control of the hardware (bare metal, no hypervisor) while still maintaining control of the IO (network attached storage and network isolation).

Conventionally this is done in software with a hypervisor which emulates network devices for VMs (virio/vmxnet3, etc...) and does some sort of network encapsulation (vlan, vxlan, etc...). Similar things are done for virtual block storage (virtio blk, nvme, etc..) to attach to remote drives.

If the IaaS clients are high bandwidth or running their own virtualization stack, the infrastructure provider has nowhere to put this software. You can do the infrastructure network and storage isolation on the network switches with extra work but then the termination of the networking and storage has to be done in cooperation with the clients (and you can't trust them to do it right).

Here, the host just sees PCI attached network interfaces and directly attached NVMe devices which pop up as defined by the infrastructure. These cards are the compromise where you let everyone have baremetal but keep your software defined network and storage. In advanced cases you could even dynamically traffic shape bandwidth between network and storage prioritization.

Here are some examples: https://ipdk.io/documentation/Recipes/ (keep in mind IPU = E2200 when you read this)

Presumably first hire a few developers to program it.