Re: [mpls-linux-general] Better to use nfmark vs tc_index?

[Olivier D. <Oli...@rd...>]

Hi Jim,

James R. Leu wrote:

> After looking at iptable a bit more I see that it can set a nfmark via
> the MARK rule.  Should I use this as oppsed to tc_index to influence the
> LSP and EXP? (note that DSCP will still be an options)
> 


Look at our patch. We have post a full and a small one. The small one 
use nfmark and is very close to the actual kernel. The only reason that 
we have developpe a similar approach with mpls_index is the ability to 
use both nfmark route and mpls_index iptable classification :

Our small patch which use nfmark as mpls key override all time the 
nfmark route selection. With iptable, you can mark packet ie. nfmark 
field in the skbuff and used this nfmark to enhance routing stuff. In 
the ip_route_input(net/ipv4/route.c) routine only @ip dst, @ip src, 
interface number (input or output) and tos field are used to compute the 
hash route table key. Look at the CONFIG_IP_ROUTE_FWMARK flag (line 1686 
to 1688) and you can saw that nfmark can be used to enhance this key 
calculation. We have mimic this for mpls_index mark. So with the full 
patch you can used both mpls_index and/or nfmark as enhancement for the 
hash key route table computation.


> I think I now understand what Olivier did, he created something similar
> to MARK but for MPLS.  If we are going to continue to use that I would
> like to change it alittle.  Instead of storing the mpls_index, I think it
> should build a dst and store it with the rule.  This dst will direct the
> skb to mpls_output() and will have the outgoung label info attached.
> When it gets to mpls_output() MPLS processing will occur like normal.
> The dst will be slapped on to any packet that matches the rule.
> 
> Do you think that by using nfmark we can accomplish the same thing?
> We would have to relay upon another mean of getting data to mpls_output()
> like a MPLS tunnel interface or a entry in the FIB that has been marked
> for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> the LSP or EXP.
> 
> Ofcourse maybe it's just safer to have both options availble :-)
> 
> Now to the matter of tc_index.  It seems that nfmark can be used by a
> scheduling classifier, but it looks like the classifier for tc_index is
> better.  So it might be that nfmark (or a MPLS mark) is used to influence
> LSP and EXP descisions (note that DSCP will still be option) and that
> tc_index is used to influence scheduling.


Actually for the TC part, we use mpls_index. My latest patch (not 
publish yet) use mpls_index when it has been configured in the 
kernel_config and directly the label in the other case. We can recopy 
this index into the tc_index. The TC mpls classifier has been written 
for this purpose. The original way we want code is to use u32 
classifier. But there is two pb.

1/ the label is not accessible by u32 classifier. They only start at the 
ip header not the shim header.

2/ Why classify again the packet (CPU power ....) if it has already been 
classified with iptable or another process ? The shim header (formely 
the label and/or the EXP fields of the shim header) can be used as a 
filter mark.


> 
> Does that make any sense?  It's late.  I'm going to sleep and think about
> it some more.
> 
> Jim
> 


Hope you this help.


Olivier
-- 
  FTR&D/DAC/CPN
  Technopole Anticipa     | mailto:Oli...@fr...
  2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
  F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52