[RFC]: xfrm by mark

[RFC]: xfrm by mark

[jamal]

Hi,

While catching up with old netdev threads I noticed this one:
http://marc.info/?l=linux-netdev&m=125621829709171&w=2
I had a chat with Timo and he is too busy on other things at
the moment. I have some cycles to burn and would like to pursue
this unless there is objection to the general idea. I am interested
because I would like to see most of the net stack capable of 
reference by mark. I am posting this so i can get a general
pulse before i go off coding.

Approach:
- introduce attribute XFRMA_MARK
- both SPD and SAD will have new entries ->mark
- by default mark is 0, so backward compat for 
control add/get/del as well as fast path lookup continues.
I dont plan to touch pfkey i.e anything injected by pfkey
will use default mark of 0.
- a sysctl to turn off this feature doesnt seem necessary
since the cycles added by the fast path lookup dont seem
to be much more..

Timo, please chime in with anything i may have missed.


cheers,
jamal

Re: [RFC]: xfrm by mark

[Patrick McHardy]

jamal wrote:
> Hi,
> 
> While catching up with old netdev threads I noticed this one:
> http://marc.info/?l=linux-netdev&m=125621829709171&w=2
> I had a chat with Timo and he is too busy on other things at
> the moment. I have some cycles to burn and would like to pursue
> this unless there is objection to the general idea. I am interested
> because I would like to see most of the net stack capable of 
> reference by mark. I am posting this so i can get a general
> pulse before i go off coding.
> 
> Approach:
> - introduce attribute XFRMA_MARK
> - both SPD and SAD will have new entries ->mark
> - by default mark is 0, so backward compat for 
> control add/get/del as well as fast path lookup continues.

If you simply add the mark to the lookup key, it will break
existing setups already using marks. I'd suggest to also add
a mask which is initialized to 0 when no mark attribute is
present.

Re: [RFC]: xfrm by mark

[jamal]

On Mon, 2010-02-08 at 14:30 +0100, Patrick McHardy wrote:

> If you simply add the mark to the lookup key, it will break
> existing setups already using marks. I'd suggest to also add
> a mask which is initialized to 0 when no mark attribute is
> present.

Good point - better safe than sorry (especially after the havoc
that ingress mark caused;->)

Would it be easier to just add a global sysctl with default being
"dont use marks"? It will be less memory use than a 32-bit mask per
mark..

cheers,
jamal

Re: [RFC]: xfrm by mark

[Patrick McHardy]

jamal wrote:
> On Mon, 2010-02-08 at 14:30 +0100, Patrick McHardy wrote:
> 
>> If you simply add the mark to the lookup key, it will break
>> existing setups already using marks. I'd suggest to also add
>> a mask which is initialized to 0 when no mark attribute is
>> present.
> 
> Good point - better safe than sorry (especially after the havoc
> that ingress mark caused;->)
> 
> Would it be easier to just add a global sysctl with default being
> "dont use marks"? It will be less memory use than a 32-bit mask per
> mark..

I'd prefer masks since the mark size is pretty small and its already
quite complicated to fit everything in 32 bit in complex setups.
We also support masks everywhere else (I believe) for mark values
nowadays.

Re: [RFC]: xfrm by mark

[jamal]

On Mon, 2010-02-08 at 16:00 +0100, Patrick McHardy wrote:

> I'd prefer masks since the mark size is pretty small and its already
> quite complicated to fit everything in 32 bit in complex setups.
> We also support masks everywhere else (I believe) for mark values
> nowadays.

I could still use the mask also as it is consistently 
being used today i.e (mark & x->mask) == x->mark
the only challenge i can think of is operational. How
do you see me activating the use of these marks? The setups
i see:

-By default if i use pfkey or old iproute2 i can have both
mask and val as 0. no problem there..
-If i was to insert table entries with say mark val 4 and mask 
of 0, that would continue to work since mark is ignored.
-if at some later point i want to use this mark 4, do i just change
the mask? That may not scale well if you have a gazillion entries.
If i used a sysctl all i would do is just turn on the
syctl and the check becomes:
syctl_use_mark && ((mark & x->mask) == x->mark)

Thoughts?

cheers,
jamal

Re: [RFC]: xfrm by mark

[Patrick McHardy]

jamal wrote:
> On Mon, 2010-02-08 at 16:00 +0100, Patrick McHardy wrote:
> 
>> I'd prefer masks since the mark size is pretty small and its already
>> quite complicated to fit everything in 32 bit in complex setups.
>> We also support masks everywhere else (I believe) for mark values
>> nowadays.
> 
> I could still use the mask also as it is consistently 
> being used today i.e (mark & x->mask) == x->mark
> the only challenge i can think of is operational. How
> do you see me activating the use of these marks? The setups
> i see:
> 
> -By default if i use pfkey or old iproute2 i can have both
> mask and val as 0. no problem there..
> -If i was to insert table entries with say mark val 4 and mask 
> of 0, that would continue to work since mark is ignored.
> -if at some later point i want to use this mark 4, do i just change
> the mask? That may not scale well if you have a gazillion entries.
> If i used a sysctl all i would do is just turn on the
> syctl and the check becomes:
> syctl_use_mark && ((mark & x->mask) == x->mark)

Why would you want to insert entries with a mark and not use
them immediately? We don't support this anywhere without
replacing entries.

Re: [RFC]: xfrm by mark

[jamal]

On Mon, 2010-02-08 at 16:35 +0100, Patrick McHardy wrote:

> Why would you want to insert entries with a mark and not use
> them immediately? We don't support this anywhere without
> replacing entries.

Ok, fair enough then.

cheers,
jamal