[mpls-linux-devel] Re: MPLS Linux

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

On Tue, 3 Feb 2004, James R. Leu wrote:

> That is fine.  I've been spending my time re-spinning RPMs.  I now
> have RPMs for all of the MPLS related software (except zebra-ldp).
>
> iproute2 +spec_nh
> iptables +spec_nh
> ppp +mpls
> mplsadm2
> kernel (+skas3 +mpls with your pending changes)

Nice :) I have commited my changes. Could you please make sure that I have
not fucked it up ? I leave you the task of reenabling IOCTLS and any
change that you may consider appropriate ;))


Another change I made yesterday:

mii and moi allocations are made with priority GFP_KERNEL This functions
_must_ be called from process context only, and it is safe if we sleep,
(the spinlock is held when we put them in the tree and after the
allocation succeeded). A couple of tests with spinlock debugging enabled
are required though..



What's next on my to do list.

* Set up netlink links. I want to be able to echo a number and that the
core replies the number + 1. I managed to do this once, but I used a whole
family for this, and I was frowned upon (with reason)

* Set up a per CPU incoming lookup cache and later a per CPU key->moi
lookup cache. this should be faaast and we can accept another cache if we
gain some performace. I'll also see if I can reuse the generic flow cache
with get_mii_by_label as the resolver.

* I don't like the mpls_label2key. It looks slow. Maybe, if we limit the
"labelspace" bitsize (lets say to 6, 2024 labelspaces. we can use some |
<< & voodoo magic to speed up this. Anyway, I'll do some tests to profile
this.

* Get some sleep.


If you enable IOCTLS, and we polish mplsadm (there was a little problem
with the syntax 'mpls -A -B -I ... -O' I would just use 'mpls -B' and
'mpls -U' only, but I thing it was my own fault) we are near pre series.


Cheers,
R.