Re: [mpls-linux-devel] Merging into the kernel?

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

On Tue, Jan 31, 2006 at 05:44:14PM +0000, Steven Whitehouse wrote:
> Hi,
>=20
> Thanks for the info on the current situation. I'm sorry for the slow
> reply (this is a spare-time project for me at least at the moment so it h=
as to
> fill odd moments that I can find).

Understood.  Same here.

> I've started to take a more in depth look at the code. I'll send a
> patch or two once I get a chance to do a bit of testing. In the
> meantime, here are a few more questions/comments:
>=20
> On Mon, Jan 23, 2006 at 10:39:41AM -0600, James R. Leu wrote:
> > Before the holidays I had started down path to getting mpls-linux
> > into the kernel (again).  I emailed jamal.  My first goal is to get the
> > infrastructure that mpls-linux needs to interact with L3 protocols put
> > in place.  Im my implementation this is the 'shim' infrastructure (look
> > in the devel achieves for a patch I've posted).
> >
> This sounds like a good plan. Its always better to break things in to
> smaller units provided each is useful in its own right, when submitting
> to the kernel.
> =20
> > I sent two patches for jamal's review, davem's technique for
> > interacting with L3 and the mpls-linux technique.  They are very simila=
r,
> > if you ask me I think the mpls-linux method is more elegant and less
> > intrusive.
> >
> What is davem's technique in this context?

I'll send you two patches, one showing the shim technique the other
showing the equivalent code from DaveM's implementation.

> > That is where we stand.  I'm sure jamal forgot about it with the holida=
ys
> > and all.  I plan on picking up this task again soon.  I was trying to g=
et
> > 1.950 finished (quagga support is broken still), but there is not reason
> > this process can't be done at the same time.

I've talked with Jamal, and he is working on a way to help out in this
effort.

> > So how can others help?  Review the code.  Test the code.  In particular
> > the locking scheme (RCU) needs to be reviewed.  In addition there is
> > some known issues with the netdevice notification handler (the list of =
NHLFE
> > is not being maintained correctly with respect to instructions, add/del=
ete,
> > and device changes).  There was a bug report posted to general late last
> > summer that had some details.
> >
> Ok. I will take a look at those as soon as I can get properly familiar
> with the code. Can I presume that your perforce archive contains in
> the mpls-kernel-1.1 directory all your latest kernel code so that I can j=
ust
> do a sync from time to time to keep uptodate? Or are there any patches
> elsewhere I should know about?

Head of line from my perforce tree is the latest greatest.=20
If you use a view of:
   =20
    //depot/iproute2-mpls-1.1/... //client-name/iproute2/...
    //depot/mpls-kernel-1.1/... //client-name/kernel/...

You would get the minimum tools needed to setup basic MPLS LSPs
and map IPv4/6 traffic to them.
   =20
>=20
> Steve.
> =20

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