mpls-linux-devel — Mailig list for discussing the development of MPLS on Linux

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

On Fri, 2004-02-13 at 09:39, James R. Leu wrote:

> > Given the above info, suggest a new name. Maybe NHid?
> 
> Much better then FECid ;-) (although it is just a name ...)

True, but has to map to the semantics;
Ok NHid for now until something with a better ring shows up.


> > 
> > Ok, that is useful. I have not tested multipath but it should
> > work with Linux routing ECMP at least. 
> > I wouldnt call it NHLFE indices rather these identifiers so far
> > called fecid;
> > Also i would think most of these lists would contain a single entry.
> > BTW, the ILM is not multihop ready. We should be able to add easily.
> > Also there is no controil on how the multihop selection is done with
> > the linux routing table - whatever Linux ECMP does goes.
> > We should be able to fix the ILM with an algorith selector.
> 
> After looking at the code I would agreed that whatever linux multiple does
> at the ingress LER, this code will follow.  The real question is how to
> go about supporting multipath as an LSR? (one ILM needs to load balance over
> multiple NHLFE).  Or dare I suggest p-mp LSPs?
> 

Ive actually done some background compute on this in my head at least.
Here are my thoughts on paper or electrons:
ILM table entry (struct ltable in the code) should have a new structure,
call it nh_choice, which has the following entries:

function selector();
struct nh_info nh_list; 

nh_list would look like:
struct gnet_stats	stats;		/* stats */
u32			lt_fecid;    /* change that to ilm_nhid */

Note the above two entries currently reside in struct ltable.

A packet coming in will have the usual lookup; the entries
nh_choice->selector() will be invoked. It will return the
nhid.
The idea behind the selector() is we can attach different algorithms
via policy and make them take care of things like paths being down etc.
I can think of two simple algorithms right away: random selection and
RR. The idea is to open these algorithms to innovation.

>From user space this would look like:

l2c mpls ilm add dev eth0 label 22 nhalg roundrobin nhid 2 nhid 3 nhid 4

etc.

Thoughts?
 
> 
> I know you mentioned it is "not an index" but to me it seems like it really
> _is_ an index for the NHLFE. Can multiple NHids correspond to the same NHLFE?
> If it is a 1 to 1 mapping for all intents an purposes it is an index :-)

Ok;->
how about NHkey ? maybe a prefix of mpls_ would also be good.

> > dsts are still managed from the MPLS code. There is some generic stuff
> > (create, destriy, gc etc) for which there is no point in recreating in
> > the MPLS code
> > The way it is right now works fine. What could probably have been a
> > better approach is to stack dsts. It would require some surgery and i am
> > not sure i have the patience for it. Mayeb we can ask Dave on his
> > thoughts on this.
> 
> Currently we use dst stacking.  The 'child' dst is actually a static member
> of the 'out going label info' (NHLFE).  So when the skb reaches the the exit
> of IPv4|6 a check for the child is done.  The skb->dst is replaced with the
> child dst and the child output funtion is called (which sends it into
> MPLS land).  The entrace to MPLS land use "container_of" macro to get the
> NHLFE to used to forward the packet.  How the stacked dst is created is
> similar to your scheme.  I was wondering is XFRM is a better scheme to use
> for all of this?

sorry i meant XFRM.
I am indifferent whether we change it to your scheme or leave it as is.
I will have to look at your code to make better judgement. My thinking
would be the end goal should be NOT to touch the IPV4/6 code with ifdefs
unless necessary. If theres not a huge difference in terms of eficiency
or code beautifaction i would rather stick to the current code.
BTW if you point me to the latest code i will print it and read offline
over the weekend if possible.

I may be a bit slow responding now since i am at work.

cheers,
jamal

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

On Fri, 13 Feb 2004, Jamal Hadi Salim wrote:

disclaimer:

from now on, all mails will be sent to mpl...@li... (
that is what I wa going to do, but then i received your email about the 
mailing list failing) 


 
> Essentially it is an identifier of a NHLFE entry. 
> So you are right naming it a FEC identifier may not be the best.

So the relationship is:

1 FEC F                         to      N available objects 
1 Incoming Label/Labelspace     to      N available objects


> I dont wanna call the so-far-called fecid lspid but it is close.

I see what you mean. Let us check what the RFC says:
   The "Incoming Label Map" (ILM) maps each incoming label to a set of
   NHLFEs. (...)


   If the ILM maps a particular label to a set of NHLFEs that contains
   more than one element, exactly one element of the set must be chosen
   before the packet is forwarded.  The procedures for choosing an
   element from the set are beyond the scope of this document.  Having
   the ILM map a label to a set containing more than one NHLFE may be
   useful if, e.g., it is desired to do load balancing over multiple
   equal-cost paths.

(RCAS: N.B. you don't need equal cost paths)...

> Given the above info, suggest a new name. Maybe NHid?

I would say something like a "fwd_id" from "Forward Id", or "out_id" it 
should not prelude one or other Next Hop.
 


> 
> Ok, that is useful. I have not tested multipath but it should


> Also i would think most of these lists would contain a single entry.

Yes, unicast MPLS with no load sharing enabled. However, you may need them 
when doing multicast and/or load sharing.



> BTW, the ILM is not multihop ready. We should be able to add easily.
Do you really need it to? Just hold a set of fwd_ids. The policy to select 
one should be configurable (discipline) & pluggable. A common impl. Is a 
hash table.

The RFC also defines the interaction with routing in this case. (although 
vaguely)


> The ability to select this value by policy allows us to be able to
> select the NHLFE entries from other subsystems; eg a u32 classifier
> on ingress could select all IP addresses from 10.1.1.1/24 to have a
> fecid of 10. The skb->fecid is then set to 10. When the packet gets to

I see, but as long as it is not called fec_id, it's fine :) call it 
fwd_id.


> 
> dsts are still managed from the MPLS code. There is some generic stuff
> (create, destriy, gc etc) for which there is no point in recreating in
> the MPLS code

I am not sure that you need to. This is what was done in James' impl.  
mpls_dst. The only thing you need is a means to allocate mpls_dsts and
hang the reference into the skb's dst. The advantage is that you don't add
another member to dst (I still don't like adding a mpls ptr to a generic
dst, but I assume you are far more knowledgeable than I am), but of 
course, you still have to modify the skb dst. (e.g. release it and hold a 
new reference).



> The way it is right now works fine. What could probably have been a
> better approach is to stack dsts. It would require some surgery and i am
> not sure i have the patience for it. 

Well, I though we agreed on doing it the right way :) I am not stating 
which one it is though.



In  mpls_unicast_forward

        lt = (struct ltable *)skb->dst;
        skb->dst = &lt->u.dst;

would not it be possible here to allocate a mpls_dst with a new dst_ops 
with the right size?




comment: I *do* think that mpls_tunnel.c from James impl can directly be 
used and it's very convenient. Just %s/moi/fwd_id/g

Ramon.

[mpls-linux-devel] XFRM (was Re: 2.6 Spec: Random comments.)

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

Last time CC'ing David.

I just wanted to get David's take on using XFRM for the Layer 3 to MPLS
mapping which would utilize dst stacking?

It XFRM capable of doing this, any pointers as to where to start?

On Fri, Feb 13, 2004 at 09:09:08AM -0500, Jamal Hadi Salim wrote:
> 
> Maybe we can move this discussion to the list and leave
> Dave alone; we can ping him when we need to verify things from him.
> I am trying to cc the list as a test.
> 
> On Fri, 2004-02-13 at 06:26, Ramon Casellas wrote:
> > Some comments,
> > 
> > (I'm still reading the spec, and slowly looking at the main entry points
> > and hooks in the code, so please be patient and bear with me)
> > 
> > 
> > RCAS 20040213: I see the utility of FEC Id, but I am not fond of the name.
> > The name Fec Id implies that it is "a FEC identifier". 
> 
> Essentially it is an identifier of a NHLFE entry. 
> So you are right naming it a FEC identifier may not be the best.
>  
> > What worries me is
> > the mapping FECId -> NHLFE (for example, in LSP merging, two FECids could
> > be mapped to the same NHLFE index), and the fact that a FECId should be a
> > member of a NHLFE entry...
> 
> I dont wanna call the so-far-called fecid lspid but it is close.
> 
> > Moreover, core LSRs should be FEC agnostic. This was my main comment last
> > time. Basically, the FECid is the label itself. The label implicitely
> > identifies the FEC as is the "key" to use to forward the packet. Otherwise 
> > you have at the same time label mappings and fecid management (signalling 
> > protocols)
> 
> I wouldnt call it a label at all. It is the key used to search the
> NHLFE. Some implementations dont allow setting of such a parameter (one
> of the vendors i looked at did actually) - they will tell you what it
> is. Essentially it is an identifier of a NHLFE entry (not index). 
> A collection of these NHLFE entries could be used by the same LSP.
> There is a further entry that can be used to store extra LSP info
> (refer to parameter "index")
> 
> Given the above info, suggest a new name. Maybe NHid?
> 
> > 
> > 
> > "ILM and FTN derive a FECid from their respective lookups"
> > 
> > I would propose :  "ILM and FTN derive a [list of - multipath] NHLFE index
> > [es] from their respective lookups [...] These indexes and incoming
> > labelspaces are then used to lookup the NHLFE to determine how to forward
> > the packet."
> > 
> 
> Ok, that is useful. I have not tested multipath but it should
> work with Linux routing ECMP at least. 
> I wouldnt call it NHLFE indices rather these identifiers so far
> called fecid;
> Also i would think most of these lists would contain a single entry.
> BTW, the ILM is not multihop ready. We should be able to add easily.
> Also there is no controil on how the multihop selection is done with
> the linux routing table - whatever Linux ECMP does goes.
> We should be able to fix the ILM with an algorith selector.
> 
> > A standard structure for NHLFE contains:
> > - FEC id 
> > 
> > RCAS: Is this field really necessary)? a NHLFE entry could be shared by
> > several 'FECsId'...
> > 
> 
> Look at my description above.
> The ability to select this value by policy allows us to be able to
> select the NHLFE entries from other subsystems; eg a u32 classifier
> on ingress could select all IP addresses from 10.1.1.1/24 to have a
> fecid of 10. The skb->fecid is then set to 10. When the packet gets to
> the point of NHLFE entry selection this value is used to override/select
> the NHLFE entry.
> 
> 
> > And a couple of questions (please consider them as questions from someone
> > who has limited experience in kernel programming)
> > 
> > * I think that adding struct mpls_nhlfe_route *mpls to a dst_entry is a
> >   little intrusive, and somehow the "genericity" of the DST is being lost.
> >   Would not it be better to use :
> > 
> > struct mpls_dst 
> > {
> > 	union
> > 	{
> > 		struct dst_entry        dst;
> > 		struct mpls_dst        *md_next;
> > 	} u;
> > 	....
> > 
> > and manage MPLS dsts from the mpls subsystem? I understand that using your
> > approach it is easier to get MPLS information from skb->dst->mpls but I
> > don't know, it seems a too strong coupling between MPLS and generic dst
> > management. Well, just food for thoughts.
> 
> 
> dsts are still managed from the MPLS code. There is some generic stuff
> (create, destriy, gc etc) for which there is no point in recreating in
> the MPLS code
> The way it is right now works fine. What could probably have been a
> better approach is to stack dsts. It would require some surgery and i am
> not sure i have the patience for it. Mayeb we can ask Dave on his
> thoughts on this.
> 
> cheers,
> jamal

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

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

Comments in line

On Fri, Feb 13, 2004 at 09:09:08AM -0500, Jamal Hadi Salim wrote:
> 
> Maybe we can move this discussion to the list and leave
> Dave alone; we can ping him when we need to verify things from him.
> I am trying to cc the list as a test.
> 
> On Fri, 2004-02-13 at 06:26, Ramon Casellas wrote:
> > Some comments,
> > 
> > (I'm still reading the spec, and slowly looking at the main entry points
> > and hooks in the code, so please be patient and bear with me)
> > 
> > 
> > RCAS 20040213: I see the utility of FEC Id, but I am not fond of the name.
> > The name Fec Id implies that it is "a FEC identifier". 
> 
> Essentially it is an identifier of a NHLFE entry. 
> So you are right naming it a FEC identifier may not be the best.

Agreed.

>  
> > What worries me is
> > the mapping FECId -> NHLFE (for example, in LSP merging, two FECids could
> > be mapped to the same NHLFE index), and the fact that a FECId should be a
> > member of a NHLFE entry...
> 
> I dont wanna call the so-far-called fecid lspid but it is close.
> 
> > Moreover, core LSRs should be FEC agnostic. This was my main comment last
> > time. Basically, the FECid is the label itself. The label implicitely
> > identifies the FEC as is the "key" to use to forward the packet. Otherwise 
> > you have at the same time label mappings and fecid management (signalling 
> > protocols)
> 
> I wouldnt call it a label at all. It is the key used to search the
> NHLFE. Some implementations dont allow setting of such a parameter (one
> of the vendors i looked at did actually) - they will tell you what it
> is. Essentially it is an identifier of a NHLFE entry (not index). 
> A collection of these NHLFE entries could be used by the same LSP.
> There is a further entry that can be used to store extra LSP info
> (refer to parameter "index")

> Given the above info, suggest a new name. Maybe NHid?

Much better then FECid ;-) (although it is just a name ...)

> > "ILM and FTN derive a FECid from their respective lookups"
> > 
> > I would propose :  "ILM and FTN derive a [list of - multipath] NHLFE index
> > [es] from their respective lookups [...] These indexes and incoming
> > labelspaces are then used to lookup the NHLFE to determine how to forward
> > the packet."
> > 
> 
> Ok, that is useful. I have not tested multipath but it should
> work with Linux routing ECMP at least. 
> I wouldnt call it NHLFE indices rather these identifiers so far
> called fecid;
> Also i would think most of these lists would contain a single entry.
> BTW, the ILM is not multihop ready. We should be able to add easily.
> Also there is no controil on how the multihop selection is done with
> the linux routing table - whatever Linux ECMP does goes.
> We should be able to fix the ILM with an algorith selector.

After looking at the code I would agreed that whatever linux multiple does
at the ingress LER, this code will follow.  The real question is how to
go about supporting multipath as an LSR? (one ILM needs to load balance over
multiple NHLFE).  Or dare I suggest p-mp LSPs?

> > A standard structure for NHLFE contains:
> > - FEC id 
> > 
> > RCAS: Is this field really necessary)? a NHLFE entry could be shared by
> > several 'FECsId'...
> > 
> 
> Look at my description above.
> The ability to select this value by policy allows us to be able to
> select the NHLFE entries from other subsystems; eg a u32 classifier
> on ingress could select all IP addresses from 10.1.1.1/24 to have a
> fecid of 10. The skb->fecid is then set to 10. When the packet gets to
> the point of NHLFE entry selection this value is used to override/select
> the NHLFE entry.

I know you mentioned it is "not an index" but to me it seems like it really
_is_ an index for the NHLFE. Can multiple NHids correspond to the same NHLFE?
If it is a 1 to 1 mapping for all intents an purposes it is an index :-)

> > And a couple of questions (please consider them as questions from someone
> > who has limited experience in kernel programming)
> > 
> > * I think that adding struct mpls_nhlfe_route *mpls to a dst_entry is a
> >   little intrusive, and somehow the "genericity" of the DST is being lost.
> >   Would not it be better to use :
> > 
> > struct mpls_dst 
> > {
> > 	union
> > 	{
> > 		struct dst_entry        dst;
> > 		struct mpls_dst        *md_next;
> > 	} u;
> > 	....
> > 
> > and manage MPLS dsts from the mpls subsystem? I understand that using your
> > approach it is easier to get MPLS information from skb->dst->mpls but I
> > don't know, it seems a too strong coupling between MPLS and generic dst
> > management. Well, just food for thoughts.
> 
> 
> dsts are still managed from the MPLS code. There is some generic stuff
> (create, destriy, gc etc) for which there is no point in recreating in
> the MPLS code
> The way it is right now works fine. What could probably have been a
> better approach is to stack dsts. It would require some surgery and i am
> not sure i have the patience for it. Mayeb we can ask Dave on his
> thoughts on this.

Currently we use dst stacking.  The 'child' dst is actually a static member
of the 'out going label info' (NHLFE).  So when the skb reaches the the exit
of IPv4|6 a check for the child is done.  The skb->dst is replaced with the
child dst and the child output funtion is called (which sends it into
MPLS land).  The entrace to MPLS land use "container_of" macro to get the
NHLFE to used to forward the packet.  How the stacked dst is created is
similar to your scheme.  I was wondering is XFRM is a better scheme to use
for all of this?

> cheers,
> jamal
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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

[mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

Maybe we can move this discussion to the list and leave
Dave alone; we can ping him when we need to verify things from him.
I am trying to cc the list as a test.

On Fri, 2004-02-13 at 06:26, Ramon Casellas wrote:
> Some comments,
> 
> (I'm still reading the spec, and slowly looking at the main entry points
> and hooks in the code, so please be patient and bear with me)
> 
> 
> RCAS 20040213: I see the utility of FEC Id, but I am not fond of the name.
> The name Fec Id implies that it is "a FEC identifier". 

Essentially it is an identifier of a NHLFE entry. 
So you are right naming it a FEC identifier may not be the best.
 
> What worries me is
> the mapping FECId -> NHLFE (for example, in LSP merging, two FECids could
> be mapped to the same NHLFE index), and the fact that a FECId should be a
> member of a NHLFE entry...

I dont wanna call the so-far-called fecid lspid but it is close.

> Moreover, core LSRs should be FEC agnostic. This was my main comment last
> time. Basically, the FECid is the label itself. The label implicitely
> identifies the FEC as is the "key" to use to forward the packet. Otherwise 
> you have at the same time label mappings and fecid management (signalling 
> protocols)

I wouldnt call it a label at all. It is the key used to search the
NHLFE. Some implementations dont allow setting of such a parameter (one
of the vendors i looked at did actually) - they will tell you what it
is. Essentially it is an identifier of a NHLFE entry (not index). 
A collection of these NHLFE entries could be used by the same LSP.
There is a further entry that can be used to store extra LSP info
(refer to parameter "index")

Given the above info, suggest a new name. Maybe NHid?

> 
> 
> "ILM and FTN derive a FECid from their respective lookups"
> 
> I would propose :  "ILM and FTN derive a [list of - multipath] NHLFE index
> [es] from their respective lookups [...] These indexes and incoming
> labelspaces are then used to lookup the NHLFE to determine how to forward
> the packet."
> 

Ok, that is useful. I have not tested multipath but it should
work with Linux routing ECMP at least. 
I wouldnt call it NHLFE indices rather these identifiers so far
called fecid;
Also i would think most of these lists would contain a single entry.
BTW, the ILM is not multihop ready. We should be able to add easily.
Also there is no controil on how the multihop selection is done with
the linux routing table - whatever Linux ECMP does goes.
We should be able to fix the ILM with an algorith selector.

> A standard structure for NHLFE contains:
> - FEC id 
> 
> RCAS: Is this field really necessary)? a NHLFE entry could be shared by
> several 'FECsId'...
> 

Look at my description above.
The ability to select this value by policy allows us to be able to
select the NHLFE entries from other subsystems; eg a u32 classifier
on ingress could select all IP addresses from 10.1.1.1/24 to have a
fecid of 10. The skb->fecid is then set to 10. When the packet gets to
the point of NHLFE entry selection this value is used to override/select
the NHLFE entry.


> And a couple of questions (please consider them as questions from someone
> who has limited experience in kernel programming)
> 
> * I think that adding struct mpls_nhlfe_route *mpls to a dst_entry is a
>   little intrusive, and somehow the "genericity" of the DST is being lost.
>   Would not it be better to use :
> 
> struct mpls_dst 
> {
> 	union
> 	{
> 		struct dst_entry        dst;
> 		struct mpls_dst        *md_next;
> 	} u;
> 	....
> 
> and manage MPLS dsts from the mpls subsystem? I understand that using your
> approach it is easier to get MPLS information from skb->dst->mpls but I
> don't know, it seems a too strong coupling between MPLS and generic dst
> management. Well, just food for thoughts.


dsts are still managed from the MPLS code. There is some generic stuff
(create, destriy, gc etc) for which there is no point in recreating in
the MPLS code
The way it is right now works fine. What could probably have been a
better approach is to stack dsts. It would require some surgery and i am
not sure i have the patience for it. Mayeb we can ask Dave on his
thoughts on this.

cheers,
jamal

Re: [mpls-linux-devel] Question: Why do we need mpls_tunnel_list ?

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

On Mon, 9 Feb 2004, James R. Leu wrote:

> mpls_tunnel_list was used to keep a small list of MPLS tunnels, so
> removes and lookups would be faster.  With the new "support for large
> number of interfaces" code being added to 2.6.3, I think the value of
> keeping this small list is minimal.

In that case, I have submitted a new version for mpls_tunnel:

* Removes mpls_tunnel_list
* Removes unneded functions.
* Fixes improper use of dev->mtu (call dev_set_mtu, so the notifications
are sent)
* Adds the SETMOI netlink link
* Cleanups
* Added __mpls_tunnel_create & __mpls_tunnel_destroy
that can be called from a IOCTL callback a netlink callback, etc.

I have tested them quite well (we are in feature freeze :P) but maybe you
could take a look at it...


the important part is that now we recognize a tunnel with
dev->type == ARPHRD_MPLS_TUNNEL


Regards,
Ramon

Re: [mpls-linux-devel] Question: Why do we need mpls_tunnel_list ?

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

mpls_tunnel_list was used to keep a small list of MPLS tunnels, so
removes and lookups would be faster.  With the new "support for large
number of interfaces" code being added to 2.6.3, I think the value of
keeping this small list is minimal.

On Sun, Feb 08, 2004 at 09:04:06AM +0100, Ramon Casellas wrote:
> 
> 
> Hi,
> 
> I've been thinking about this, and I don't see why do we need to
> keep a separate list of mpls tunnels. Assume we remove it
> 
> Disadvantages:
> 
> * To identify the list of mpls tunnels we need to check private flags
> and/or if (dev->type == ARPHRD_MPLS_TUNNEL). We only need to do this from
> process context, and, unless the user has hundreds of network devices,
> overhead is small.
> 
> 
> Advantages:
> 
> * The functions: mpls-tunnel_init mpls_tunnel_link mpls_tunnel_unlink
> can be removed.
> 
> * We avoid synchronization issues with rtnl_lock and list lock, and we
> avoid incoherences between the main dev_base list and our private list.
> 
> * Avoid race conditions when removing the module.
> 
> * Code is cleaner and easier to understand.
> 
> Comments? I am all for a removal...
> 
> R.
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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

[mpls-linux-devel] Question: Why do we need mpls_tunnel_list ?

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

Hi,

I've been thinking about this, and I don't see why do we need to
keep a separate list of mpls tunnels. Assume we remove it

Disadvantages:

* To identify the list of mpls tunnels we need to check private flags
and/or if (dev->type == ARPHRD_MPLS_TUNNEL). We only need to do this from
process context, and, unless the user has hundreds of network devices,
overhead is small.


Advantages:

* The functions: mpls-tunnel_init mpls_tunnel_link mpls_tunnel_unlink
can be removed.

* We avoid synchronization issues with rtnl_lock and list lock, and we
avoid incoherences between the main dev_base list and our private list.

* Avoid race conditions when removing the module.

* Code is cleaner and easier to understand.

Comments? I am all for a removal...

R.

[mpls-linux-devel] MPLS Tunnel fixes and netlink links.

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

All,

Although we keep them for the moment for practical reasons, the
mpls_tunnel file no longer requires IOCTLs from the main mpls subsystem,
(James: the issue we were having to make mpls_tunnel a true module). This
was the last step to modularize mpls-tunnel. Nevertheless, as stated
before, backwards compat. still prevents this. I have p4submitted the new
approach, which is the following:

* When loaded, the mpls-tunnel module obtains the netlink table for
AF_MPLS. If it is not NULL, the module sets two new "netlink" links up,
defining two new "doit" functions. When the tunnel is unloaded, the
pointers are reset to NULL.

Of course, this assumes that the mpls-tunnel depends on the main module
having set up the netlink table (which is logical). We should find a
programmatic way to enforce this (e.g. something like
'require_module(mpls-base))



+       /*
+        * Setup netlink links
+        */
+       MPLS_DEBUG("Checking rtnetlink_links\n");
+        if (rtnetlink_links[PF_MPLS]) {
+               MPLS_DEBUG("Setting\n");
+               rtnetlink_links[PF_MPLS][MPLS_RTM_TUNNEL_ADD].doit =
+                       mpls_tunnel_add_doit;
+               rtnetlink_links[PF_MPLS][MPLS_RTM_TUNNEL_DEL].doit =
+                       mpls_tunnel_del_doit;
+               rtnetlink_links[PF_MPLS][MPLS_RTM_TUNNEL_ADD].dumpit =
NULL;
+               rtnetlink_links[PF_MPLS][MPLS_RTM_TUNNEL_DEL].dumpit =
NULL;
+       }


+/*****************************************************************************
+       NETLINK INTERFACE
+
*****************************************************************************/
+int
+mpls_tunnel_add_doit (struct sk_buff *skb, struct nlmsghdr* msghdr, void
*attr)
+{
+       struct sk_buff *new_skb;
+       int res;
+       int size = NLMSG_GOODSIZE;
+       MPLS_DEBUG("User requested to add a tunnel\n");
+       new_skb = alloc_skb(size, GFP_KERNEL);
+       if (!new_skb) {
+               netlink_set_err(rtnl, 0, 0, ENOBUFS);
+               return -EINVAL;
+       }
+       NETLINK_CB(new_skb).dst_groups = 0;
+       res = netlink_unicast (rtnl, new_skb, msghdr->nlmsg_pid,
MSG_DONTWAIT);
+       MPLS_DEBUG("%d\n",res);
+       return 0;
+}


Preliminary tests work fine.


I will be cleaning up the userspace app, but it is useless until we define
the MSG names, formats, return values, etc. (on paper first! :P)

James: what else is on the 'must-fix' list? if our firsts tests work fine,
we should ask netdev@ for a peer review.

Have a nice w.e.

R.




ps: yeah, yeah... I know I said I would not be hacking for some days, but
the main meeting has been postponed, and I'm having fun :P


// -------------------------------------------------------------------
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...

Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

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

I agree that the current use of the neighbour table without holding
some sort of refcount is "a bad thing" and should be fixed.  I will look
into this tonight.

On Fri, Feb 06, 2004 at 05:17:30PM +0100, Ramon Casellas wrote:
> On Fri, 6 Feb 2004, James R. Leu wrote:
> 
> > 
> > The current use of IPv[4|6] neighbour tables already caches the DA, SA, and
> > MPLS ethertype. Look at the debug output for mpls_send().  It shows
> > that it is using the hh cache, and the resulting packet has the correct
> > ethertype.
> 
> 
> Right, right, I know, the hh_type is set when the neighbour is being 
> initialized, and from the type in the dst ops protocol (which is MPLS).
> (and since we override the dst, thinks work fine).
> 
> This is not necessarily wrong, but my point is that we do not have an 
> homogeneous neighbour-hh_object with a single address family (and I 
> don't know if we should)... I was just thinking vaguely about the 
> possibility of doing like in DECnet of IPv6, where they do manage their 
> own set of neighbours and a neighbour table. 
> 
> Maybe we should, if later we want to transport other payloads, we should
> have a uniform view of *neighbour LSRs* for AF_MPLS (within the scope of a
> well defined Layer 2 technology, agnostic to the layer 3 protocol). The L3 
> details are left for mpls_dsts.
> 
> Well, that's just Food for thoughts for MPLs-Linux 3.0 :), but my issue 
> about not increasing the refcount of the neighbour table (although a rare 
> event) applies
> 
> thanks for reading...
> 

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

Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

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

On Fri, 6 Feb 2004, James R. Leu wrote:

> 
> The current use of IPv[4|6] neighbour tables already caches the DA, SA, and
> MPLS ethertype. Look at the debug output for mpls_send().  It shows
> that it is using the hh cache, and the resulting packet has the correct
> ethertype.


Right, right, I know, the hh_type is set when the neighbour is being 
initialized, and from the type in the dst ops protocol (which is MPLS).
(and since we override the dst, thinks work fine).

This is not necessarily wrong, but my point is that we do not have an 
homogeneous neighbour-hh_object with a single address family (and I 
don't know if we should)... I was just thinking vaguely about the 
possibility of doing like in DECnet of IPv6, where they do manage their 
own set of neighbours and a neighbour table. 

Maybe we should, if later we want to transport other payloads, we should
have a uniform view of *neighbour LSRs* for AF_MPLS (within the scope of a
well defined Layer 2 technology, agnostic to the layer 3 protocol). The L3 
details are left for mpls_dsts.

Well, that's just Food for thoughts for MPLs-Linux 3.0 :), but my issue 
about not increasing the refcount of the neighbour table (although a rare 
event) applies

thanks for reading...

Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

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

On Fri, Feb 06, 2004 at 03:16:47PM +0100, Ramon Casellas wrote:
> On Friday 06 February 2004 15:04, James R. Leu wrote:
> 
> > I implemented neigh_table_find.  True their is no refcnting of anything
> 
> Ouups :*) my mistake ....
> 
> 
> 
> > it was a quick hack.  There is no easy way to implement a MPLS neighbour
> > table without completly duplicating the IPv4 or IPv6 neighbours.  A
> 
> I am not sure... not a priority, but I'll take a look.
> 
> > hh_cache will never work because the contents of the MPLS header is not the
> 
> IMHO, I thing you are wrong. No L3 info is stored on a hh_cache (only the 
> ETH_P type), and in this case the shim header "acts" like a L3. the hh_cache 
> object should only cache MAC DA, SA, and Ethertype (ETH_P_MPLS_UC) no more. 
> It is the Ethernet header only.

The current use of IPv[4|6] neighbour tables already caches the DA, SA, and
MPLS ethertype. Look at the debug output for mpls_send().  It shows
that it is using the hh cache, and the resulting packet has the correct
ethertype.

> TTL and EXP are analogous to the IPv4 header, which also changes. I *do* think 
> that we should manage hh objects.
> 
> 
> > neighbour table.  I think the correct path is to add refcnting to
> > neigh_table.
> 
> I'm not sure... I'll think about it, but for me, the correct will be to have 
> an AF_MPLS neighbour table, with mpls neighbours held by mpls dsts, with mpls 
> hh caches (sorta like decnet). True, the control plane is IPv4/ IPv6, and 
> this may mean having to code much more, but it makes sense. 
> 
> Still, justs some random thoughts...
> 
> R.

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

Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

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

On Friday 06 February 2004 15:04, James R. Leu wrote:

> I implemented neigh_table_find.  True their is no refcnting of anything

Ouups :*) my mistake ....



> it was a quick hack.  There is no easy way to implement a MPLS neighbour
> table without completly duplicating the IPv4 or IPv6 neighbours.  A

I am not sure... not a priority, but I'll take a look.

> hh_cache will never work because the contents of the MPLS header is not the

IMHO, I thing you are wrong. No L3 info is stored on a hh_cache (only the 
ETH_P type), and in this case the shim header "acts" like a L3. the hh_cache 
object should only cache MAC DA, SA, and Ethertype (ETH_P_MPLS_UC) no more. 
It is the Ethernet header only.

TTL and EXP are analogous to the IPv4 header, which also changes. I *do* think 
that we should manage hh objects.


> neighbour table.  I think the correct path is to add refcnting to
> neigh_table.

I'm not sure... I'll think about it, but for me, the correct will be to have 
an AF_MPLS neighbour table, with mpls neighbours held by mpls dsts, with mpls 
hh caches (sorta like decnet). True, the control plane is IPv4/ IPv6, and 
this may mean having to code much more, but it makes sense. 

Still, justs some random thoughts...

R.

Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

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

I implemented neigh_table_find.  True their is no refcnting of anything
it was a quick hack.  There is no easy way to implement a MPLS neighbour
table without completly duplicating the IPv4 or IPv6 neighbours.  A hh_cache
will never work because the contents of the MPLS header is not the
same for every packet that traverses an LSP (TLL and EXP), so the only
info we would get from MPLS neighbour table is the exact information that
we get from the IPv[4|6] tables.  I see nothing to gain by implementing
a MPLS neighbour table.  I think the correct path is to add refcnting
to neigh_table.

Won't other protocols needs this as well?  Think of IPv6 routes that point
to IPv4 nexthops or vice versa.

On Fri, Feb 06, 2004 at 02:46:16PM +0100, Ramon Casellas wrote:
> 
> 
> Hi,
> 
> Little question here: neigh_table_find has been removed in 2.6.2
> 
> The original goal was to manage mpls_dsts but reusing the AF_INET
> AF_INET6 neighbour tables (lookup a neighbour and hold it in the mpls_dst)
> 
> The problem is that now I don't see how we can do this... We should not 
> access the neigh_tables list & lock directly. Maybe we should manage our 
> own neighbours and a AF_MPLS neighbour table... I'm starting to think that 
> this is the best approach, since we can even cache hh objects with 
> ETH_P_MPLS_UC....
> 
> Thoughts? Maybe we should start bugging ne...@os... for comments. 
> 
> Regards,
> R.
> 
> 
> 
> RFC: 
>         /* Set next hop MPLS attr */
>         memcpy(&md->md_nh,nh,sizeof(struct sockaddr));
> 
>         /*
>          * Lookup for the next hop (neighbour) in the AF_INET/AF_INET6
>          * neighbour table. (neigh_table_find removed in 2.6.2)
>          */
> 
> 	tbl = neigh_table_find (....)
> 
>         /*
>          * AF_INET neighbour keys are their addr.
>          * Look for the neighbour (create if needed)
>          * (neigh_lookup & neigh_create hold a ref)
>          */
>         md->u.dst.neighbour = __neigh_lookup(tbl, data, dev, 1);
> 
> 
> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> // Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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

[mpls-linux-devel] neigh_table_find removed in 2.6.2

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

Hi,

Little question here: neigh_table_find has been removed in 2.6.2

The original goal was to manage mpls_dsts but reusing the AF_INET
AF_INET6 neighbour tables (lookup a neighbour and hold it in the mpls_dst)

The problem is that now I don't see how we can do this... We should not 
access the neigh_tables list & lock directly. Maybe we should manage our 
own neighbours and a AF_MPLS neighbour table... I'm starting to think that 
this is the best approach, since we can even cache hh objects with 
ETH_P_MPLS_UC....

Thoughts? Maybe we should start bugging ne...@os... for comments. 

Regards,
R.



RFC: 
        /* Set next hop MPLS attr */
        memcpy(&md->md_nh,nh,sizeof(struct sockaddr));

        /*
         * Lookup for the next hop (neighbour) in the AF_INET/AF_INET6
         * neighbour table. (neigh_table_find removed in 2.6.2)
         */

	tbl = neigh_table_find (....)

        /*
         * AF_INET neighbour keys are their addr.
         * Look for the neighbour (create if needed)
         * (neigh_lookup & neigh_create hold a ref)
         */
        md->u.dst.neighbour = __neigh_lookup(tbl, data, dev, 1);


// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...

[mpls-linux-devel] [RFC] Patch: Use generic internet flow cache for incoming label lookup

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

James, All,


do you think this is worth the hassle and that there is indeed a
performance gain ? (I am not even sure if this is a good approach...)



#define MPLS_ENABLE_FLOW_CACHE


#ifdef MPLS_ENABLE_FLOW_CACHE

static void
mpls_mii_resolver (struct flowi *key, u16 family, u8 dir,
                void **objp, atomic_t **obj_refp)
{
        /* Look up the mii object */
        struct mpls_in_info* mii;

        read_lock   (&mpls_mii_lock);
        mii = radix_tree_lookup (&mpls_mii_tree, key->fl6_flowlabel);
        read_unlock (&mpls_mii_lock);

        /* Give the object address and its refcount. */
        *objp     =  mii;
        *obj_refp = (mii)? &mii->kobj.refcount : NULL;
}
#endif



struct mpls_in_info*
mpls_get_mii_by_label (
        struct mpls_push_data *mpr,
        mpls_label_t *label,
        int labelspace)
{
        struct mpls_in_info *mii = NULL;

#ifdef MPLS_ENABLE_FLOW_CACHE
        struct flowi in_flow;

        /* RCAS: We use fl6_flowlabel as the MII key */
        in_flow.fl6_flowlabel = mpls_label2key (labelspace,label);

        /* RCAS: Lookup flow in percpu flow cache  */
        mii = flow_cache_lookup(&in_flow, AF_MPLS, MPLS_IN,
mpls_mii_resolver);
        if (likely(mii)) {
                mpls_in_info_hold(mii);
                return mii;
        }

        /* If !mii it is either reserved or a bug. */
#endif
   /* handle the reserved label range */
        if (label->ml_type == MPLS_
.....



comments welcome

regards,
Ramon


// -------------------------------------------------------------------
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...

Re: [mpls-linux-devel] MPLS Linux Netlink Support

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

On Wed, 4 Feb 2004, James R. Leu wrote:

> Good stuff!
>
> I'll probably post them to SF sometime over the weekend.  DO you have any
> release notes you'd like to add?


I'm afraid I'll be quite busy until tuesday. You may add this link to the
release notes:

http://perso.enst.fr/~casellas/mpls-linux/index.html

but it is not "up to date", there are some issues, like

1/
mplsadm -B -I gen:34:0 -O <key>
mplsadm -U -I gen:34:0 -O <key>

but In other docs (mpls-linux-1.1/README) I had read
"mplsadm -A -B and mplsadm -D -B"

I personally think that syntax in 1/ is clearer and better. Moreover, -A
should be reserved for adding new MII/MOI objects only.

The problem is that I don't think I will be able to update it for
friday....


Thanks,
R.

Re: [mpls-linux-devel] MPLS Linux Netlink Support

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

Good stuff!

I should have RPMs for all of the MPLS related packages ready for
download by friday.  

I'll probably post them to SF sometime over the weekend.  DO you have any
release notes you'd like to add?

On Wed, Feb 04, 2004 at 08:48:08PM +0100, Ramon Casellas wrote:
> 
> James, all,
> 
> I have just added basic support for netlink in p4. The 'link' is up :) and
> more or less working (Thanks to DaveM for suggesting the use of AF_MPLS
> and not a whole family. Although conceptually, mpls tables *are not*
> routing tables, I was duplicating functionnality and code from rtlink)
> 
> 
> There are basically three things to do:
> 
> * Multiplexing: do we just have one .doit and one .dumpit and we multiplex
> using the packet header or we set up several virtual links using a full
> table?
> 
> * Define the protocol between kernel/userspace, paquet format, etc.
> (which could be the existing mpls_foo_bar_req)
> 
> * Implement the .doit and .dumpit functions
> (which could just call the existing ones).
> 
> In preference, we should work the "doit" functions. The dumpit have less
> priority, since we already have ro sysfs/procfs.
> 
> 
> Some tests.
> 
> MPLSNETLINK mplsnl.h:272:open: Socket descriptor 3
> MPLSNETLINK mplsnl.h:273:open: Local Addr 0 (len 12)
> MPLSNETLINK mplsnl.h:308:tx_msg: Size nlmsg_len 144
> MPLSNETLINK mplsnl.h:373:tx_msg:Reponse Type 16 (Error is 2)
> 
> dmesg:
> MPLS DEBUG net/core/rtnetlink.c:352:rtnetlink_rcv_msg: Type: 16
> MPLS DEBUG net/core/rtnetlink.c:368:rtnetlink_rcv_msg: Message Len: 144
> MPLS DEBUG net/core/rtnetlink.c:370:rtnetlink_rcv_msg: Family: 30/32
> MPLS DEBUG net/core/rtnetlink.c:381:rtnetlink_rcv_msg: Link: c0422280
> MPLS DEBUG net/core/rtnetlink.c:385:rtnetlink_rcv_msg: Kind: 0
> MPLS DEBUG net/core/rtnetlink.c:423:rtnetlink_rcv_msg: min_len: 32
> MPLS DEBUG net/core/rtnetlink.c:431:rtnetlink_rcv_msg: attrlen: 112
> MPLS DEBUG net/mpls/mpls_netlink.c:92:mpls_nl_doit: enter
> MPLS DEBUG net/mpls/mpls_netlink.c:68:mpls_say_hello: enter
> MPLS DEBUG net/mpls/mpls_netlink.c:81:mpls_say_hello: 20<7>MPLS DEBUG
> net/mpls/mpls_netlink.c:83:mpls_say_hello: exit
> MPLS DEBUG net/mpls/mpls_netlink.c:94:mpls_nl_doit: Done
> MPLS DEBUG net/mpls/mpls_netlink.c:95:mpls_nl_doit: exit
> 
> 
> 
> 
> I wont be able to hack for some days, so this is why I prefer to submit as
> is....
> 
> 
> Regards,
> Ramon
> 
> // -------------------------------------------------------------------
> // Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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

[mpls-linux-devel] MPLS Linux Netlink Support

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

James, all,

I have just added basic support for netlink in p4. The 'link' is up :) and
more or less working (Thanks to DaveM for suggesting the use of AF_MPLS
and not a whole family. Although conceptually, mpls tables *are not*
routing tables, I was duplicating functionnality and code from rtlink)


There are basically three things to do:

* Multiplexing: do we just have one .doit and one .dumpit and we multiplex
using the packet header or we set up several virtual links using a full
table?

* Define the protocol between kernel/userspace, paquet format, etc.
(which could be the existing mpls_foo_bar_req)

* Implement the .doit and .dumpit functions
(which could just call the existing ones).

In preference, we should work the "doit" functions. The dumpit have less
priority, since we already have ro sysfs/procfs.


Some tests.

MPLSNETLINK mplsnl.h:272:open: Socket descriptor 3
MPLSNETLINK mplsnl.h:273:open: Local Addr 0 (len 12)
MPLSNETLINK mplsnl.h:308:tx_msg: Size nlmsg_len 144
MPLSNETLINK mplsnl.h:373:tx_msg:Reponse Type 16 (Error is 2)

dmesg:
MPLS DEBUG net/core/rtnetlink.c:352:rtnetlink_rcv_msg: Type: 16
MPLS DEBUG net/core/rtnetlink.c:368:rtnetlink_rcv_msg: Message Len: 144
MPLS DEBUG net/core/rtnetlink.c:370:rtnetlink_rcv_msg: Family: 30/32
MPLS DEBUG net/core/rtnetlink.c:381:rtnetlink_rcv_msg: Link: c0422280
MPLS DEBUG net/core/rtnetlink.c:385:rtnetlink_rcv_msg: Kind: 0
MPLS DEBUG net/core/rtnetlink.c:423:rtnetlink_rcv_msg: min_len: 32
MPLS DEBUG net/core/rtnetlink.c:431:rtnetlink_rcv_msg: attrlen: 112
MPLS DEBUG net/mpls/mpls_netlink.c:92:mpls_nl_doit: enter
MPLS DEBUG net/mpls/mpls_netlink.c:68:mpls_say_hello: enter
MPLS DEBUG net/mpls/mpls_netlink.c:81:mpls_say_hello: 20<7>MPLS DEBUG
net/mpls/mpls_netlink.c:83:mpls_say_hello: exit
MPLS DEBUG net/mpls/mpls_netlink.c:94:mpls_nl_doit: Done
MPLS DEBUG net/mpls/mpls_netlink.c:95:mpls_nl_doit: exit




I wont be able to hack for some days, so this is why I prefer to submit as
is....


Regards,
Ramon

// -------------------------------------------------------------------
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...

[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.

[mpls-linux-devel] Re: Here it comes... big patch for 2.6.1-mpls-1.910 pre series

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

I'm looking forward to testing this one.  Lots of good stuff.

Just a couple of notes:
-I'm cool with the name change (mpls_instruction -> mpls_instr :-)
 I think the reason I used mpls_instruction versus mpls_instr is that at
 one time I had a structure member called mpls_instr, so I was trying
 to minimize confusion.  I think this is no longer the case.
-I agree locking is an issue.  Mitigating access to the tree is not enough,
 we need to guard against multiple 'threads' changing the same MOI/MII, but
 per MOI/MII locking seems overkill.  What about just enforcing a write lock
 on the tree when a 'thread' wants to modify a MOI/MII?
-I'm still not sure about the linked list of instructions ..
   -We can already 'share' instructions via indirection with the FWD
    operation (multiple MOIs/MIIs with a FWD to a common MOI) and it
    already maintains the notion of 'parenthood'
   -size, each instruction now has an extra pointer compared to just
    one int holding the size of the array
   -if the elements of the link list are not in the same memory locality
    we will get cache misses which will ultimatly cause poor performace in
    the fast path.  Although the data for the instructions might be in a
    different locality, so cache misses are inevitable. But a couple of
    cache misses versus potential cache flailing is better.  In the end
    I'm not sure if any of this matters, but it is just my gut feeling that
    a dynamically allocated array is better then a linked list in this case.
    Let's test what you got in the patch and maybe down the road we can to
    some profiling and see if it matters.

On Thu, Jan 29, 2004 at 04:01:54PM +0100, Ramon Casellas wrote:
> 
> 
> Hi James, all
> (I don't know if others read the list though, and I cannot
> see the list of subscribers)
> 
> Well, here it comes :) let the serious testing for the 2.6_pre series
> begin! (I am still interested in UML for 2.6). This patch aplies to you r
> head as of today, it may be 'bug prone' and it is not well tested enough,
> but w.f.m (works for me).Remark: I have removed support for some legacy
> ioctls (debug, labelspaces, mii proto) use sysfs.
> 
> your comments are of course, welcome.
> 
> Other than testing, we need now to focus on locking schemes. I *think*
> that current locking is not enough, and we may need to keep 'per MII/MOI
> object locking' and not only the tree with a read/write lock.
> 
> Scenarios:
> 1. softirq (bh) forwarding data path reader grabs tree lock and
> gets a ref to a MII object, releases lock. If, in any case, a writer
> (process context) maybe in another CPU locks the tree, gets a ref to the
> same MII object and releases the lock (in other words the lock just
> protected tree access) Can data corruption occur?
> 
> 
> 2. Two writers in different CPUs (or in same CPU) both in process context
> grab a ref to the same MII object for updating. lock serializes access to
> the tree, but once they both have a reference, data corruption/races may
> occur. (Maybe I am braindead, but this one looks clear to me....)
> Solution: add a per MII/MOI object readers (softirq) writers
> (ioctls/process context) lock. This locking granularity should be enough.
> 
> Not sure, I still need to think about all this.
> 
> 
> Cheers,
> Ramon
> 
> 
> 
> 
> Notes:
> ===================
> * mpls_instruction was to long for me ... :) I hope you dont mind saying
> mpls_instr.
> 
> * Instructions are now reference counted objects that use kobj. As any ref
> counted object, and in special kobjects, we need to provide a 'release'
> method (mpls_instr_release), so, given a kobj, we obtain the container and
> all cleanup is done (and memory is freed) there. That's why I had to add
> the 'parent' and 'direction' attributes.
> 
> * Instruction sets for MII/MOI objects are linked lists, and IMHO, the
> advantage of dynamic arrays is simplicity in error paths, but linked lists
> will allow us later to do intruction sharing (see below)
> 
> * Since they are now refcounted objects and instruction sets are
> implemented as linked lists, a nice idea for the future (for post 2.6) is
> to _share_ opcodes: there exists a single MPLS_OP_SET that forwards the
> labelled packet to the next hop and can be referenced by several MOI
> objects (LSP merging, for example). Opcodes form a directed graph, each
> MOI/MII object follows a path, and graph nodes are refcounted.
> We willneed to solve some 'parenthood' issues, though, but it is something we
> should beep in mind (and, fortunately, sysfs has the notion of symlink
> !)))
> 
> 
> 
> example: usage
> 
> # mplsadm3 -A -I gen:40:0
> /sys/mpls/
> |-- debug
> |-- fullname
> |-- labelspace
> |-- mpls_instr
> |-- mpls_mii
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-PEEK
> |       |   `-- data
> |       |-- age
> |       |-- bytes
> |       |-- drops
> |       |-- key
> |       |-- labelspace
> |       |-- packets
> |       |-- proto
> |       `-- refcnt
> |-- mpls_moi
> |-- mpls_tunnel
> `-- version
> 
> # mplsadm3 -A -O 0
> /sys/mpls/
> |-- debug
> |-- fullname
> |-- labelspace
> |-- mpls_instr
> |-- mpls_mii
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-PEEK
> |       |   `-- data
> |       |-- age
> |       |-- bytes
> |       |-- drops
> |       |-- key
> |       |-- labelspace
> |       |-- packets
> |       |-- proto
> |       `-- refcnt
> |-- mpls_moi
> |   `-- moi-2
> |       |-- age
> |       |-- bytes
> |       |-- drops
> |       |-- key
> |       |-- mtu
> |       |-- mtu_limit
> |       |-- packets
> |       |-- propagate_ttl
> |       `-- refcnt
> |-- mpls_tunnel
> `-- version
> 
> 
> # echo "ath0:0" > /sys/mpls/labelspace
> # cat /proc/net/mpls/labelspaces
> Iface   LSpc    Refcnt
>     lo    -1    12
>   eth0    -1     3
>   ath0     0    12
> 
> # mplsadm3 -A -T mpls0
> 
> |-- mpls_tunnel
> |   `-- mtp-mpls0
> |       |-- dev
> |       `-- moi
> 
> 
> 
> # mplsadm3 -O 2 -o push:gen:666:set:ath0:ipv4:192.168.0.1
> /sys/mpls/
> |-- debug
> |-- fullname
> |-- labelspace
> |-- mpls_instr
> |-- mpls_mii
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-PEEK
> |       |   `-- data
> |       |-- age
> |       |-- bytes
> |       |-- drops
> |       |-- key
> |       |-- labelspace
> |       |-- packets
> |       |-- proto
> |       `-- refcnt
> |-- mpls_moi
> |   `-- moi-2
> |       |-- OP-00-PUSH
> |       |   `-- data
> |       |-- OP-01-SET
> |       |   `-- data
> |       |-- age
> |       |-- bytes
> |       |-- drops
> |       |-- key
> |       |-- mtu
> |       |-- mtu_limit
> |       |-- packets
> |       |-- propagate_ttl
> |       `-- refcnt
> |-- mpls_tunnel
> |   `-- mtp-mpls0
> |       |-- dev
> |       `-- moi
> `-- version
> 
> ATTRIBUTES
> ================================
> # echo "2" > /sys/mpls/mpls_tunnel/mtp-mpls0/moi
> # cat /sys/mpls/mpls_tunnel/mtp-mpls0/moi
> moi: 2(0x00000002) 0/0/0 5
> 
> # echo "0x0800" > /sys/mpls/mpls_mii/mii-gen\:40\:0-163841/proto
> # cat /sys/mpls/mpls_mii/mii-gen\:40\:0-163841/proto
> 0x0800
> 
> CROSSCONNECTS
> =================================
> # tree /sys/mpls
> (cut)
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-PEEK
> |       |   `-- data
> 
> # mplsadm3  -B -I gen:40:0 -O 2
> 
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-FWD
> |       |   `-- data
> 
> # mplsadm3  -U -I gen:40:0 -O 2
> |-- mpls_mii
> |   `-- mii-gen:40:0-163841
> |       |-- OP-00-POP
> |       |   `-- data
> |       |-- OP-01-PEEK
> 
> 
> 



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

[mpls-linux-devel] Re: Here it comes... big patch for 2.6.1-mpls-1.910 pre series

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

Re,

What I meant is to do somthing similar to neighbour management, where A.K.
uses a tbl lock and then a per neighbour lock:

"Neighbour hash table buckets are protected with rwlock tbl->lock.
....
   Neighbour entries are protected:
   - with reference count.
   - with rwlock neigh->lock

   Reference count prevents destruction.

   neigh->lock mainly serializes ll address data and its validity state.
   However, the same lock is used to protect another entry fields:
    - timer
    - resolution queue
"


but well, maybe you are right...

R.

[mpls-linux-devel] Re: Here it comes... big patch for 2.6.1-mpls-1.910 pre series

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

On Thu, 29 Jan 2004, James R. Leu wrote:

> -I agree locking is an issue.  Mitigating access to the tree is not enough,
>  we need to guard against multiple 'threads' changing the same MOI/MII, but
>  per MOI/MII locking seems overkill.  What about just enforcing a write lock
>  on the tree when a 'thread' wants to modify a MOI/MII?

I am not sure if per MII/MOI would be overkill or not. If you want to
enforce a write lock when a thread wants to modify, (where writes are
mostly done in process context, we should lock everything between a
get_obj and a put_obj). This has problems:

- We should not only mitigate against multiple threads changing. Wha
about readers ? Also readers should be protected.

- It is difficult to identify who when where someone holds a reference.
Right now, anyone who holds a ref can do whatever he wants: a tunnel keeps
a pointer to a MOI. at any moment after a IOCTL it may corrupt data.

- From process context we should disable bottom halves, maybe for the
duration of the update. Since BH also access data (ro), we should use a
spinlock, and we cannot sleep while holding a spinlock. One of the bad
things we need to solve is that all allocations now are atomic, precisely
because we work exclusively with spinlocks even from process
context/ioctls.

- We should lock the data in the MII MOI, not all the code paths that
update thigs.

RCU ?  I have just started reading about quiescent states, RCU techniques
and so on, but it looks like a good candidate here: rare writes from
process context, lots of reads from SoftIRQ/BH with per CPU softnet data?


I don't know, I always seem to have problems with locking, contexts and
bottom halves :P I'll take a look at other kernel parts to see how they
manage this issue.

Some netdev@ hacker should comment on this :)

Here's what I propose: leave things the way they are now regarding locking
and I'll try to get the whole picture. Most probably I am missing
something here.



Other things:

* [For post 2.6] there is a lot of duplicate code between MII/MOI. With
this patch I have tried to move instruction ops, but later we should try
to abstract a little more.


Thanks,

R.

[mpls-linux-devel] Here it comes... big patch for 2.6.1-mpls-1.910 pre series

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

Hi James, all
(I don't know if others read the list though, and I cannot
see the list of subscribers)

Well, here it comes :) let the serious testing for the 2.6_pre series
begin! (I am still interested in UML for 2.6). This patch aplies to you r
head as of today, it may be 'bug prone' and it is not well tested enough,
but w.f.m (works for me).Remark: I have removed support for some legacy
ioctls (debug, labelspaces, mii proto) use sysfs.

your comments are of course, welcome.

Other than testing, we need now to focus on locking schemes. I *think*
that current locking is not enough, and we may need to keep 'per MII/MOI
object locking' and not only the tree with a read/write lock.

Scenarios:
1. softirq (bh) forwarding data path reader grabs tree lock and
gets a ref to a MII object, releases lock. If, in any case, a writer
(process context) maybe in another CPU locks the tree, gets a ref to the
same MII object and releases the lock (in other words the lock just
protected tree access) Can data corruption occur?


2. Two writers in different CPUs (or in same CPU) both in process context
grab a ref to the same MII object for updating. lock serializes access to
the tree, but once they both have a reference, data corruption/races may
occur. (Maybe I am braindead, but this one looks clear to me....)
Solution: add a per MII/MOI object readers (softirq) writers
(ioctls/process context) lock. This locking granularity should be enough.

Not sure, I still need to think about all this.


Cheers,
Ramon




Notes:
===================
* mpls_instruction was to long for me ... :) I hope you dont mind saying
mpls_instr.

* Instructions are now reference counted objects that use kobj. As any ref
counted object, and in special kobjects, we need to provide a 'release'
method (mpls_instr_release), so, given a kobj, we obtain the container and
all cleanup is done (and memory is freed) there. That's why I had to add
the 'parent' and 'direction' attributes.

* Instruction sets for MII/MOI objects are linked lists, and IMHO, the
advantage of dynamic arrays is simplicity in error paths, but linked lists
will allow us later to do intruction sharing (see below)

* Since they are now refcounted objects and instruction sets are
implemented as linked lists, a nice idea for the future (for post 2.6) is
to _share_ opcodes: there exists a single MPLS_OP_SET that forwards the
labelled packet to the next hop and can be referenced by several MOI
objects (LSP merging, for example). Opcodes form a directed graph, each
MOI/MII object follows a path, and graph nodes are refcounted.
We willneed to solve some 'parenthood' issues, though, but it is something we
should beep in mind (and, fortunately, sysfs has the notion of symlink
!)))



example: usage

# mplsadm3 -A -I gen:40:0
/sys/mpls/
|-- debug
|-- fullname
|-- labelspace
|-- mpls_instr
|-- mpls_mii
|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-PEEK
|       |   `-- data
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- labelspace
|       |-- packets
|       |-- proto
|       `-- refcnt
|-- mpls_moi
|-- mpls_tunnel
`-- version

# mplsadm3 -A -O 0
/sys/mpls/
|-- debug
|-- fullname
|-- labelspace
|-- mpls_instr
|-- mpls_mii
|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-PEEK
|       |   `-- data
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- labelspace
|       |-- packets
|       |-- proto
|       `-- refcnt
|-- mpls_moi
|   `-- moi-2
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- mtu
|       |-- mtu_limit
|       |-- packets
|       |-- propagate_ttl
|       `-- refcnt
|-- mpls_tunnel
`-- version


# echo "ath0:0" > /sys/mpls/labelspace
# cat /proc/net/mpls/labelspaces
Iface   LSpc    Refcnt
    lo    -1    12
  eth0    -1     3
  ath0     0    12

# mplsadm3 -A -T mpls0

|-- mpls_tunnel
|   `-- mtp-mpls0
|       |-- dev
|       `-- moi



# mplsadm3 -O 2 -o push:gen:666:set:ath0:ipv4:192.168.0.1
/sys/mpls/
|-- debug
|-- fullname
|-- labelspace
|-- mpls_instr
|-- mpls_mii
|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-PEEK
|       |   `-- data
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- labelspace
|       |-- packets
|       |-- proto
|       `-- refcnt
|-- mpls_moi
|   `-- moi-2
|       |-- OP-00-PUSH
|       |   `-- data
|       |-- OP-01-SET
|       |   `-- data
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- mtu
|       |-- mtu_limit
|       |-- packets
|       |-- propagate_ttl
|       `-- refcnt
|-- mpls_tunnel
|   `-- mtp-mpls0
|       |-- dev
|       `-- moi
`-- version

ATTRIBUTES
================================
# echo "2" > /sys/mpls/mpls_tunnel/mtp-mpls0/moi
# cat /sys/mpls/mpls_tunnel/mtp-mpls0/moi
moi: 2(0x00000002) 0/0/0 5

# echo "0x0800" > /sys/mpls/mpls_mii/mii-gen\:40\:0-163841/proto
# cat /sys/mpls/mpls_mii/mii-gen\:40\:0-163841/proto
0x0800

CROSSCONNECTS
=================================
# tree /sys/mpls
(cut)
|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-PEEK
|       |   `-- data

# mplsadm3  -B -I gen:40:0 -O 2

|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-FWD
|       |   `-- data

# mplsadm3  -U -I gen:40:0 -O 2
|-- mpls_mii
|   `-- mii-gen:40:0-163841
|       |-- OP-00-POP
|       |   `-- data
|       |-- OP-01-PEEK

[mpls-linux-devel] [PATCH] Port MII management to kobject/sysfs

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

Hi James/all,


This patch has been obtained from the current head as of the time of
writting (which, I think does not yet include yesterday's patch, you may
drop it, this one supersedes it). This is not a trivial patch, and I
wonder if you could also try it on your side. I think that it clarifies a
little MII management, and reuses the kobject api (details follow).


I'll work on the same thing for MOI objects. I plan to port MOI management
to kobject api, get rid of the global moi_list, and clean up flush/delete
of outgoing labels.

Comments Welcome!

Regards,
R.

Remarks:

* Destroy methods for af_mpls.c are still missing. I don't know if you
want to complete those or not, and how we are going to netlink (I have a
mpls_netlink.c somewhere, which I used to test basic netlink
functionality, let me know if you want to take a look at it).



Features
-------------------------

* Added 2004 (c) in files.

* Added EXPORT_SYMBOL for spec_nh. There are known issues (see below)

* mpls_init has more robust error checking.

* Bumped version to #define MPLS_LINUX_VERSION     0x01090002


* Changed
RADIX_TREE(mii_tree, GFP_ATOMIC)
RADIX_TREE(moi_tree, GFP_ATOMIC)

Otherwise, we were getting the sleeping while atomic bug (write_lock for
the Incoming Outgoing Radix Tree + allocating a node in the tree with
GFP_KERNEL which may sleep) e.g.:

Debug: sleeping function called from invalid context at mm/slab.c:1856
in_atomic():1, irqs_disabled():0
Call Trace:
[<c012974c>] __might_sleep+0xac/0xe0
[<c0160e9a>] kmem_cache_alloc+0x1da/0x1e0
[<c022d9a0>] radix_tree_node_alloc+0x20/0x60
[<c022db8b>] radix_tree_insert+0x9b/0xe0
[<c039a7f0>] mpls_insert_mii+0x30/0xc0
[<c039abdc>] mpls_add_in_label+0x17c/0x2d0
[<c039c93b>] mpls_ioctl+0x79b/0x9e0

This happens, for example in:

int mpls_insert_mii (unsigned int key, struct mpls_in_info *mii)
{
...
	write_lock(&mpls_mii_lock);
	retval = radix_tree_insert(&mii_tree,key,mii);
	write_unlock(&mpls_mii_lock);
	return retval;
}



* Added a new kobject/sysfs subsystem, "mpls", that appears under /sys.
This subsystem exports in read only two attributes fullname and version.
For now, it is redundant with proc. In the future, the MPLS procfs may
become obsolete and favor either a mplsfs or do everything in sysfs with
attributes.


gandalf sys# ls
block  bus  cdev  class  devices  firmware  mpls  power
gandalf sys# tree mpls/
mpls/
|-- fullname
|-- mpls_mii
`-- version




* Added a new kset "mpls_mii" to hold all mii objects (still pending for
moi management, tunnel and labelspace management). This means that all
struct mpls_in_info (MII/mii) objects are now full kobjects, and struct
members are exposed (readonly for now) as attributes.

IMPLICATIONS

- Field __refcnt has been removed. refcount is now based on kobjects.

- Field global_entry has been removed. We can now get all the MII objects
from the MPLS MII kset (using the semaphore). See mpls_in_info flush tree
or mpls_proc for details. There is no need to manage a parallel list (although this is done by the kobject API anyway).

- Global mii_list has been deleted.

- mpls_mii_kobject_release (struct kobject *kobj) has been added. This one
replaces __mpls_del_label.... This is the "very latest function", where we
free the object. See documentation/{filesystems/sysfs,kobject}.txt for
details.


- mpls_in_info_hold is something like:
{
 struct kobject *kobj = NULL;
 kobj = kobject_get(&mii->kobj);
 return container_of(kobj,struct mpls_in_info,kobj);
}


- The name of the kobject MII is either

kobject_set_name(&mii->kobj,"mii-gen-%u:%u-%u",
kobject_set_name(&mii->kobj,"mii-atm-%u:%u/%u-%u",
kobject_set_name(&mii->kobj,"mii-fr-%u:%u-%u",

that is labelspace:labelvalue-key (decimal)




Tests:
---------------------------------------


1a.- Add generic 30,31,32,33, 34, 35 Incoming labels to ILM, using
mplsadm.

1b.- Check with procfs
gandalf casellas# cat /proc/net/mpls/*
Debug: 1

Printing Info for MII
Key:0x0001e001 0/0/0
gen 30
MII 0 2
POP PEEK


Printing Info for MII
Key:0x0001f001 0/0/0
gen 31
MII 0 2
POP PEEK


Printing Info for MII
Key:0x00020001 0/0/0
gen 32
MII 0 2
POP PEEK


Printing Info for MII
Key:0x00021001 0/0/0
gen 33
MII 0 2
POP PEEK


Printing Info for MII
Key:0x00022001 0/0/0
gen 34
MII 0 2
POP PEEK


Printing Info for MII
Key:0x00023001 0/0/0
gen 35
MII 0 2
POP PEEK


gandalf sys# ls
block  bus  cdev  class  devices  firmware  mpls  power
gandalf casellas# tree /sys/mpls/
/sys/mpls/
|-- fullname
|-- mpls_mii
|   |-- mii-gen-0:31-126977
|   |   |-- age
|   |   |-- bytes
|   |   |-- drops
|   |   |-- key
|   |   |-- labelspace
|   |   |-- packets
|   |   `-- proto
|   |-- mii-gen-0:32-131073
|   |   |-- age
|   |   |-- bytes
|   |   |-- drops
|   |   |-- key
|   |   |-- labelspace
|   |   |-- packets
|   |   `-- proto
|   |-- mii-gen-0:33-135169
|   |   |-- age
|   |   |-- bytes
|   |   |-- drops
|   |   |-- key
|   |   |-- labelspace
|   |   |-- packets
|   |   `-- proto
|   `-- mii-gen-0:34-139265
|       |-- age
|       |-- bytes
|       |-- drops
|       |-- key
|       |-- labelspace
|       |-- packets
|       `-- proto
`-- version


 gandalf mii-gen-0:31-126977# cat *
 257622
 0
 0
 1f001
 0
 0
 8


Flush trees
gandalf mplsadm# ./mplsadm -F
MPLS DEBUG net/mpls/mpls_ioctls.c:39:mpls_ioctl: IOCTL 35858
MPLS DEBUG net/mpls/mpls_in_info.c:784:mpls_flush_in_tree: enter
MPLS DEBUG net/mpls/mpls_in_info.c:798:mpls_flush_in_tree: # mii-gen-0:31-126977
MPLS DEBUG net/mpls/mpls_in_info.c:621:mpls_mii_kobject_release: enter
MPLS DEBUG net/mpls/mpls_utils.c:482:mpls_instruction_clear: enter
MPLS DEBUG net/mpls/mpls_utils.c:491:mpls_instruction_clear: exit
MPLS DEBUG net/mpls/mpls_in_info.c:637:mpls_mii_kobject_release: exit
MPLS DEBUG net/mpls/mpls_in_info.c:798:mpls_flush_in_tree: # mii-gen-0:32-131073
MPLS DEBUG net/mpls/mpls_in_info.c:621:mpls_mii_kobject_release: enter
MPLS DEBUG net/mpls/mpls_utils.c:482:mpls_instruction_clear: enter
MPLS DEBUG net/mpls/mpls_utils.c:491:mpls_instruction_clear: exit
MPLS DEBUG net/mpls/mpls_in_info.c:637:mpls_mii_kobject_release: exit
MPLS DEBUG net/mpls/mpls_in_info.c:798:mpls_flush_in_tree: # mii-gen-0:33-135169
MPLS DEBUG net/mpls/mpls_in_info.c:621:mpls_mii_kobject_release: enter
MPLS DEBUG net/mpls/mpls_utils.c:482:mpls_instruction_clear: enter
MPLS DEBUG net/mpls/mpls_utils.c:491:mpls_instruction_clear: exit
MPLS DEBUG net/mpls/mpls_in_info.c:637:mpls_mii_kobject_release: exit
MPLS DEBUG net/mpls/mpls_in_info.c:798:mpls_flush_in_tree: # mii-gen-0:34-139265
MPLS DEBUG net/mpls/mpls_in_info.c:621:mpls_mii_kobject_release: enter
MPLS DEBUG net/mpls/mpls_utils.c:482:mpls_instruction_clear: enter
MPLS DEBUG net/mpls/mpls_utils.c:491:mpls_instruction_clear: exit
MPLS DEBUG net/mpls/mpls_in_info.c:637:mpls_mii_kobject_release: exit
MPLS DEBUG net/mpls/mpls_in_info.c:806:mpls_flush_in_tree: exit
MPLS DEBUG net/mpls/mpls_ioctls.c:39:mpls_ioctl: IOCTL 35859
MPLS DEBUG net/mpls/mpls_out_info.c:545:mpls_flush_out_tree: enter
MPLS DEBUG net/mpls/mpls_out_info.c:558:mpls_flush_out_tree: exit





Known Bugs
------------------------
* Spec NH management is buggy.

ipv6: Unknown symbol spec_nh_find
request_module: failed /sbin/modprobe -- net-pf-10. error = 256



* It is impossible to add out operations. dst moi is null. Could you take
a look at that? We should try to release a working test version soon...

MPLS DEBUG net/mpls/mpls_ioctls.c:39:mpls_ioctl: IOCTL 35847
MPLS DEBUG net/mpls/mpls_ioctls.c:39:mpls_ioctl: IOCTL 35864
MPLS DEBUG net/mpls/mpls_out_info.c:255:mpls_set_out_label_instructions: enter
MPLS DEBUG net/mpls/mpls_utils.c:411:mpls_instruction_build: enter
MPLS DEBUG net/mpls/mpls_utils.c:138:mpls_make_dst: enter
Unable to handle kernel NULL pointer dereference at virtual address 00000060
 printing eip:
 c015c822
 *pde = 00000000
 Oops: 0000 [#2]
 CPU:    0
 EIP:    0060:[<c015c822>]    Not tainted
 EFLAGS: 00010246
 EIP is at kmem_flagcheck+0x22/0x40
 eax: 00000000   ebx: eb36b7a8   ecx: 00000001   edx: c039d360
 esi: 00000000   edi: 00000020   ebp: f5b694e4   esp: f5b694e4
 ds: 007b   es: 007b   ss: 0068
 Process mplsadm (pid: 11467, threadinfo=f5b68000 task=e889e9c0)
 Stack: f5b69508 c015d8d5 00000000 00000020 dabaa498 f5b6951c eb36b7a8 c04576c0
 00000020 f5b69528 c03278ff 00000000 00000020 dabaa498 eb36b7a8 00000000
 c1bda074 f5b69554 c039d3d9 c04576c0 c03fb2b2 0000008a c03c5183 f5b69554
 Call Trace:
 [<c015d8d5>] kmem_cache_alloc+0x25/0x1e0
 [<c03278ff>] dst_alloc+0x2f/0xa0
 [<c039d3d9>] mpls_make_dst+0x69/0x2d0
 [<c039b02e>] mpls_build_opcode_set+0x5e/0x1e0
 [<c039db09>] mpls_instruction_build+0x209/0x2f0
 [<c039c189>] mpls_set_out_label_instructions+0x79/0x210


// -------------------------------------------------------------------
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...