Re: Increasing skb->mark size

[Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz>]

On 11/30/2015 05:49 PM, David Miller wrote:
> From: Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz>
> Date: Mon, 30 Nov 2015 04:10:43 +0000
>
>> On 11/30/2015 02:58 PM, David Miller wrote:
>>> If you guys, really anyone, can find a way to remove some other 32-bit
>>> item from sk_buff, you can expand skb->mark to 64-bits. But otherwise,
>>> I'm going to be strongly against it. sk_buff is already enormous and
>>> larger than it should be. So I'm going to resist any change that makes
>>> it even larger. Thanks.
>> Would the level of objection be the same if this was done as an
>> "extended mark" field under a configurable off-by-default option?
> Every distribtion will turn the option on.
>
> Config options hiding "cost" is never an argument to bloat
> a critical core datstructure up, sorry.
>
Fair enough, although if most distributions would turn it on, it does 
suggest that it is interesting...

I have been looking at the tc_index field in the skb, and I think that 
this might fit our current purposes with some modifications.
The extra bits we are currently looking for are actually for traffic 
control.

We would need a marking target for tc_index in nf/ip tables and a way to 
save/restore it into the connmark.
This would become an additional method of setting tc_index alongside 
dsmark, and the existing tcindex tc classifier can then be used to 
classify the packets.

The only data structure change needed for this would be to add a u16 
tc_index to the nf_conn structure, as we would still
want to reduce the number of rules processed for each individual packet 
by restoring the mark from the connection for all
but the first packet in each flow.

Would this be an acceptable alternative, or is the nf_conn structure 
size restricted in the same way as the sk_buff?