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

[James R. L. <jl...@mi...>]

Just an FYI, for some reason my P4 server is not reachable.  I
may head home at lunchtime (CST) and check it out.

On Mon, Mar 29, 2004 at 10:06:08AM -0500, Jamal Hadi Salim wrote:
> 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
> 

-- 
James R. Leu
jl...@mi...