Late last year I was invited to present a keynote at the Euro P4 Workshop, and I took the opportunity to revisit a topic that has held my attention for much of my career: the appropriate partitioning of functionality in networked computing systems. This talk was both an opportunity to reflect on what has (and hasn’t) changed since I was accidentally building SmartNICs in the 1990s, and to build on some of the themes in our recent post on Infrastructure Processing Units and Data Processing Units (IPUs/DPUs).
So by IPU are you thinking about Pensando on top of Aruba as a programmable switch? Or are you thinking with Cumulus now owned by NVIDIA will we see a full blown networking engine on a DPU? The same way ESXi and NSX will run on a DPU I think this could be an opportunity to introduce cloud services closer to the guest than at the first hop network device. My only concern is managing all these nodes efficiently with patches, updates, configurations, this needs to be an automated first design. Very exciting times!!
Idea is that there would be two K8s clusters in the site. One K8s cluster across host CPU nodes and another K8s cluster across IPUs of servers. Since it is K8s cluster, any management workloads & offloaded infrastructure workloads will be looked at in the same way as any other workloads. Patching, upgrades/updates, configuration systems can be used almost ASIS.
Nicely written. In the project-emco community, few discussions happened on this. Mainly, the discussions revolved around the IPU/DPU role in edge-computing. Since IPU and CPU take workloads (infrastructure and guest workloads respectively), it was felt that common entities need to be shared among them. That requires automation of IPU infrastructure when guest workloads come up. Due to isolation requirements, one likes to go with an agentless model (that is no agent in the host). Hence, the need for higher level orchestration systems to program IPU (such as networkpolicy, DDOS policies, service mesh etc..) for guests' workloads.
In regards to P4: I would imagine that this interface is used within IPU between normal-path component in ARM cores and networking hardware IP. As far as the programming/configuring the IPU from external orchestration is concerned, I think it will continue to be K8s custom resources realized via K8s operator. P4 is good in the sense for portability of infrastructure software across multiple IPUs/DPUs. And portability is important and I hope that Industry keeps adding more extern features (to realize stateful packet processing, IPSEC, traffic shaping, RAN DU, UPF).
So by IPU are you thinking about Pensando on top of Aruba as a programmable switch? Or are you thinking with Cumulus now owned by NVIDIA will we see a full blown networking engine on a DPU? The same way ESXi and NSX will run on a DPU I think this could be an opportunity to introduce cloud services closer to the guest than at the first hop network device. My only concern is managing all these nodes efficiently with patches, updates, configurations, this needs to be an automated first design. Very exciting times!!
We're mostly taking the definition of IPU from Intel, and I like the discussion on terminology here https://www.servethehome.com/intel-ipu-exotic-answer-to-industry-dpu/. I would consider Pensando an IPU as well in this taxonomy.
You wrote "My only concern is managing all these nodes efficiently with patches, updates, configurations, this needs to be an automated first design."
Yes, that is exactly the discussion that is happening in the project-emco community. Please see the link I posted in the previous comment: https://www.linkedin.com/pulse/cpu-ipu-why-multi-cluster-orchestration-becomes-super-addepalli/
Idea is that there would be two K8s clusters in the site. One K8s cluster across host CPU nodes and another K8s cluster across IPUs of servers. Since it is K8s cluster, any management workloads & offloaded infrastructure workloads will be looked at in the same way as any other workloads. Patching, upgrades/updates, configuration systems can be used almost ASIS.
Nicely written. In the project-emco community, few discussions happened on this. Mainly, the discussions revolved around the IPU/DPU role in edge-computing. Since IPU and CPU take workloads (infrastructure and guest workloads respectively), it was felt that common entities need to be shared among them. That requires automation of IPU infrastructure when guest workloads come up. Due to isolation requirements, one likes to go with an agentless model (that is no agent in the host). Hence, the need for higher level orchestration systems to program IPU (such as networkpolicy, DDOS policies, service mesh etc..) for guests' workloads.
Good to know what you think. Created an article based on project-emco community discussions here: https://www.linkedin.com/pulse/cpu-ipu-why-multi-cluster-orchestration-becomes-super-addepalli/
In regards to P4: I would imagine that this interface is used within IPU between normal-path component in ARM cores and networking hardware IP. As far as the programming/configuring the IPU from external orchestration is concerned, I think it will continue to be K8s custom resources realized via K8s operator. P4 is good in the sense for portability of infrastructure software across multiple IPUs/DPUs. And portability is important and I hope that Industry keeps adding more extern features (to realize stateful packet processing, IPSEC, traffic shaping, RAN DU, UPF).