[c-nsp] Cisco 8000

[Saku Ytti]

On Fri, 20 Dec 2019 at 09:42, Mark Tinka <mark.tinka at seacom.mu> wrote:

> When Broadcom design their chips, they aren't doing it from the
> perspective of what the vendors are going to incorporate with their
> hardware, software and service roadmaps. Similarly, when the equipment
> vendors are building software for platforms that are going to be based
> on Broadcom chips, they aren't necessarily building them for whatever
> future Broacdom have in mind.

This is making huge assumptions. This is assuming that when Leaba
designed the chips they decided their exit will be vendor acquiring
them and that decision impacted how the chip is being designed. To me
this sounds ridiculous notion.

> This is why we come across strange issues on boxes that we think can be
> solved with a software fix, only for the vendor to come back and say,
> "Ummh, it's actually a chip limitation with Broadcom. We expect that
> limitation to be fixed in the next chip release". Meanwhile, you've
> blown millions of $$ on deployment of the hardware, and can't quite swap
> it out with the boxes that present the new merchant chip.

Pretty sure what you are actually doing is comparing run-to-completion
to pipelines, you hear this 'not possible by the chip' all the time
for vendor own pipelines as well, the only problem is, not many
vendors have pipeline chips. But run PTX/paradise and you'll run into
the same thing. It's fundamental that pipelines are less flexible.

I mean you rock Cisco, ASR9k is merchant up until lightspeed, yet you
don't hear a lot about these complaints about ASR9k.

-- 
  ++ytti