Re: Bridge netfilter defered hooks

[Simon Lodal <simonl@parknet.dk>]

On Thursday 08 June 2006 22:47, Martijn Lievaart wrote:
> Patrick McHardy wrote:
> >Carl-Daniel Hailfinger wrote:
> >>IIRC the mark has only 32 bits. Not so long ago, I was using 30 bits
> >>of that in my firewalling rules on a bridge-router. I might have
> >>squeezed the physdev match in the remaining 2 bits, but I'm not
> >>sure. I do admit the setup was fairly uncommon (bridging and
> >>double nat with only one machine).
> >
> >Yes, its getting a bit tight in there, but so far in all setups I've
> >seen it was possible to get along with the 32 bits using masks or
> >reusing bits after they are no longer needed. I guess we'll have to
> >wait and see ..
>
> Something I've been thinking about. Currently it is impossible to write
> any kind of generic tool that uses the mark and plays nice with other
> generic tools. Maybe we need some kind of API that allocates bits in the
> mark. Something like "give me two bits", that returns some handle to the
> bits. That handle could then be used for identifying the bits in the mark.
>
> As an added benefit, this encapsulates the operations on the mark,
> making it trivial to switch to say 64 bits for the mark.
>
> What do others think?
>
> M4

Sounds nice. If the handles are names it becomes a sort of runtime-defined bit 
struct. Would be nice to have across the tools, instead of doing the black 
bit magic directly (and in parallel) in each place.

Why not define the mark size at compile time, in case you need more bits?


Greetings

Simon