[j-nsp] Limit on interfaces in bundle

[Jesper Skriver]

On Mon, Nov 02, 2015 at 06:30:00PM +0000, Adam Vitkovsky wrote:
> -----Original Message-----
> > From: Jesper Skriver [mailto:jesper at skriver.dk]
> > Sent: Monday, November 02, 2015 5:14 PM
> >
> >
> > Right, on those types of platforms it can be done - assuming there are spare
> > bits in the meta data that goes with the packet, enough free instruction
> > space etc - but it will come at a performance impact as it will require more
> > cycles per packet, unless on the particular platform there is still headroom for
> > adding more cycles without affecting the ability to be linerate ...
>
> Talking about lookup performance isn't the number of cycles negligible compared to memory access times please?

Different architectures behave differently, but if you can arrange
the new data such that it will fit the same cache line as data you
are already reading, the additional read of the new data will come
from the CPU data cache, and is typically very fast. You are right
an uncached read is often 100's of instructions.

> Even the high-end platforms of all vendors will cripple performance when features are enabled.

Some more than others ...

> > Which is why I in my original reply said that it would not be practical. For it to
> > be useful all routers in the path needs to support it, otherwise as soon as it
> > hits one that doesn't all the various MPLS sub-types will get mixed together
> > again.
> > Features which require network wide support are quite hard to get off the
> > ground.
>
> Maybe this could get shoehorned along with segment routing.

Doubt it, SR specifications are very far along, and several
vendors have working implementations.

/Jesper