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

[Ramon C. <cas...@in...>]

On Mon, 19 Apr 2004, Jamal Hadi Salim wrote:

> On Mon, 2004-04-19 at 02:22, Ramon Casellas wrote:
> 
> Ok, so we are on the same track then. I wasnt sure if that plan was
> still on. 
> BTW, can you extract this patch and send it to me?

Sure, attached.


> I think we need to show some progress and just the dst stacking maybe
> insufficient. Probably the easiest one is for me to submit the L2C patch
> sans the MPLS bits to it since the bridging guys need to use that too. 
> Thoughts?

(side question:Are you using p4 finally? sorry, I recall your stating the
'I will give it a try' but I don't know if you decided to. James is quite
a pro managing p4 patches)

Nevertheless, regarding your question: I would say that separating the L2C 
patch is an interesting approach decoupling concepts. I'd go for it.

OTOH, with the new extensions for L2SC/PWE3 control in (G)MPLS we may need
to work more closely with the bridging people (although most things belong
clearly to userspace). I know that James has been working in this area,
but I don't know the details or whether he has been working with other
people.

And finally, regarding the mpls stuff itself. I am not sure of
understanding what do you mean with 'we need to show some progress'. There
are other things discussed in previous mails that are there, but I don't
recall having had an agreement. We were discussing about MPLS tunnels,
NHLFE stacking, new opcodes, etc. The ideas are there, the only thing we
need to define is how these ideas (if adequate) are going to be
integrated. 

Some questions: are we free to go and change Dave's core? Should we first
submit mainly Dave's core and then and only then work with incremental and
small changes? Or should we keep it quite a little more and extend Dave's
code with some work before submitting? In this later case: what? if you 
ask myself or James (although I let him speak by himself) NHLFE stacking. 
You rised the concern of performance. I don't think it really is an issue.

In other words: how do we port features that are in our version to Dave's 
core? and finally, there is one important question that I have not dared 
to ask until now: there is a notable user base (in research labs) that use 
James implementation *and* userspace applications that work with it. The 
most notable example (for me and some people I know) is RSVP-TE daemon. If 
the drop some exisiting features like procfs and/or ioctl support, this 
means a step back from the user point of view (although I tend to think 
that we should ask what's best for the kernel and let the userspace apps 
drag behind).


Action Points (just my opinion):

* I would say that l2c stuff could (you are the expert) be separated from 
the mpls core. Submit this before the MPLS core and let it become stable 
in the netdev tree.

* I would start by submitting Dave's core + James Dst stacking.

* Keep on working from that focusing on porting some features present in 
James impl. (if we manage to convince you ;)) )

* At some point we should converge...


(btw, I appreciate your offer regarding the inclusion of James and myself
as co-authors)



regards,
R.