Re: 64bit MARK

[Patrick McHardy <kaber@trash.net>]

Fran����������������������������������������������� wrote:
> On Thu, 2009-10-29 at 23:30 +0100, Patrick McHardy wrote:
>>> Would it be possible to have 64bit MARKs with 64bit architectures? 
>>>
>>> Apparently they are defined as "unsigned long" in linux headers, but
>>> iptables limits them to 32bit.
>> Thats from far far back. The unsigned long only exists in compatibility
>> structures, all new revisions use 32 bit. This is deliberate to make
>> sure they're same-sized on all architectures and rulesets don't behave
>> differently.
> 
> It might be an uncommon case, but many things I do need MARKs and 32bits
> is just not enough!
> 
> For example, for input traffic I do marking for:
> - ip rules (sometimes A LOT of rules)
> - tc filters (sometimes A LOT of filters)
> - gateway selection (ip rules for multipath)
> - marking input interface to use in IMQ
> 
> Any ideas then for someone needing more than 32bits MARK? I could use
> TOS bits (usable with ip rules and tc filters), but it's just so ugly,
> and would screw in any network using it...
> 
> Could the other 32 bits be used as a MARK "category" feature available
> only for 64bit arch?

No, as I said, rulesets are supposed to behave similar on all
architectures. Since neither routing rules nor TC classifiers
support more than 32 bit, it would be useless anyways. But you
can usually deal with this by organizing your marking rules
properly.

First, all of the above support using masks for mark values,
which might be helpful. For routing and gateway selection you
only need the mark values at PREROUTING and OUTPUT, so you
can reuse them afterwards. TC marking is best done in
POSTROUTING since that doesn't interfere with routing. If
for some reason you want to do TC classification earlier than
that, you can use the CLASSIFY target, which doesn't use
mark values but priority values.