Re: [mpls-linux-devel] Current state of dst stacking on davem implementation

[Jamal H. S. <ha...@zn...>]

Hi guys,

I am gonna stop apologizing for not responding on timely fashion. 
Currently, this is beyond my control with the new baby.

On Fri, 2004-03-26 at 09:10, Ramon Casellas wrote:

> On Fri, 26 Mar 2004, Jamal Hadi Salim wrote:
> 
> > 
> > Is this _always_ the case or mostly the exception?
> 
> To the best of my knowledge, it happens quite often,

Good enough; my experiences are it is on the exception side however
if you guys say it aint then it aint.

> > 
> > > 3) The layer of indirection cause by the 'stacked' NHLFE allows
> > > for fast fail-over by modifying only the bottom most NHLFE.
> > 
> > Isnt editing that NHLFE entry sufficient?
> 
> I have always thought that being able to specify the last instruction 
> of a NHLFE 'a' to be "and now go follow NHLFE 'c'" provides a great amount 
> of flexibility. I vote for being able to "chain" opcodes. In two cases:
> 
> - In instructions are chained to a NHLFE instructions
> 
> - NHLFEntries may refer to another NHLFE
> 
> NHLFE a:
>  push 10
>  goto c
> 
> NHLFE b:
>  push 11
>  goto c
> 
> NHLFE c:
>  push 40
>  fwd
> 
> by changing c I can engineer at the same time a and b. As James stated: 
> path protection, LSP modification, even if it is not *strictly* required I 
> think it may be good design and does not impact (noticiably) performance.
> 

This is fine for fast failover; challenge is it may end up being an
expensive thing when trying to scale (2 lookups instead of 1 for one
that says "goto c" - the cost could really add up at high speeds).
Also, from a semantic view - doesnt the view of what a nhlfe change now
with "goto c" syntax.
We should still strive to have the MIB modelling as example apply
(NHLFE table, ILM table etc). 


> > Ok, generally i understand what you are proposing (i think) - to
> > reiterate 
> > 1) both the ILM and NHLFE should have opcodes in them 
> 
> yes. In instructions and out instructions.
> 

For the sake of progress i would say lets move on and have this in.
So where do we go next?
I am going ot setup the uml thing on my laptop. Actually i need
to install Fedora on a PC at home and use that as the real environment
for this.

> 
> > 2) a tunnel device
> 
> nice to have.
> 
> So DaveM code + In/Out instructions + tunnels + stacking entries = JLeu 
> code + DaveM improvements. I agree that some parts are indeed not required 
> (procfs, sysfs) but they are there for historical reasons and in the 
> process of getting migrated.

Lets leave sysfs and profs last; i think we need to iron out the issue
listed. We should really shoot to integrate something soon into the
2.6.x kernel. Lets make small releases - any suggestions?
Ramon, do you wanna list all outstanding issues discussed so far - so we
can see which one we attack incrementally?
I dont think Davem will have any issues with the dst stacking code so
that could be one of the first things that goes in;

cheers,
jamal