> > A downside for the iSCSI approach is that I don't think the packet > > processing for VSWITCH traffic gets offloaded to the I/O > > processors, so > > you'd use up more CPU to drive tape operations. Of course, I've been > > lobbying for a specialized network processor engine for a while; this > > would be an ideal reason to implement it, IMHO. > How about if IBM allowed a zIIP or zAAP to do this?
Well, with Cisco making noises about open-sourcing IOS, it might be interesting to try it (finally, a way to euthanize MPROUTE for the good of humanity, or at least Miguel's continued sanity...), but I'd be more inclined to have it as a new processor type in that networking workloads tend to be optimized for real-time, and neither of those two existing processors are. I think that a plug-in auxiliary processor like the CEXP2 crypto engines might be an easier way to implement this rather than re-microcoding a GP CPU. Using an embedded Cell engine might be another interesting way.
