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

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

On Mon, 2004-03-29 at 09:43, James R. Leu wrote:

> > Good enough; my experiences are it is on the exception side however
> > if you guys say it aint then it aint.
> 
> I have never seen nor heard of a RFC or even a draft which describs
> a protocol which distributes more then one level of label.

True, but you can leave the handling of how the stacking is done to user
space and make the kernel portion simpler. I think this is a moot point
for now so lets move on. 
 
> > 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). 
> 
> The data stored with the FWD instruction would be a pointer the the
> next NHLFE.  Therefore no lookup is done.

I would have to wait and see the implementation piece. If i understood
correctly though:
- theres policy which chains together these little "commands" like
"goto"
- at policy creation time you will have a chaining of these commands;
maybe a linked list of what applies (your reference to a "pointer to
next NHLFE" above)
- each of these commands will i suppose have a refcount which will be
incremented for each policy that holds them
- each of these commands will be separately editable; hence changing one
changes multiple policies at the same time.

If i did understand correctly, then shouldnt the "commands" be a
separate table? And the NHLFE holds the policies of what connects to
what. No?
Similarly the ILM could reference this "commands" table.


> I have created a seperate branch off of 'mpls-kernel-davem' called
> 'mpls-kernel-merger'.  It is where we can submit changes.  Every once in a
> while we can look at the diff between 'mpls-kernel-davem' and
> 'mpls-kernel-merger' and decide what gets propogated to 'mpls-kernel-davem'.

Sounds like a plan

> This next week is going to be very busy for me, so I will not be able to
> do much development.  

Should give me opportunity to get started on setting up the environment.
Im officialy first time in sane state at the office, so i should at
least be able to set up the UML and the P4 setup

> Here is how I propose we start:
> 
> -I will submit the dst stacking code.
> -rename all structures to proper names
>     s/mpls_nhlfe_route/mpls_nhlfe/
>     s/ltable/mpls_ilm/
> -add instruction list to ILM and NHLFE
> -move NHLFE label and nexthop to instructions
> -move ILM -> NHLFE connection to instructions
> -modify netlink to better take advantage of the new structure

All above sound reasonable. If you want i could help with the last one
if you document the new structuring

> I was planning to take much of the code from our implementation and
> modify it to work in the DaveM code.

This is also acceptable.

cheers,
jamal