Re: Extending connmark to 64 bits

[Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>]

On Thu, 2015-11-19 at 22:32 +0100, Florian Westphal wrote:
> Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> wrote:
> > On Thu, 2015-11-19 at 04:00 +0100, Florian Westphal wrote:
> > > Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> wrote:
> > > > Currently we have a number of router features making use of connection
> > > > tracking. As such we now require more than the 32 bits connmark
> > > > currently has. Our first inclination is to extend this field to 64 bits
> > > > and update related areas of code appropriately.
> > > > 
> > > > The major question we have is whether there is a reason this field is 32
> > > > bits (performance reasons or other)?
> > > 
> > > Its meant to align with skb->mark.
> > 
> > I thought that could be the case. Probably the wrong mailing-list to be
> > asking this on but is increasing the number of bits for the skb->mark
> > then a possibility?
> 
> Increase sk_buff size?  Doubtful.
> 
> > The number of bits available for marking becomes the
> > limiting factor when you have a number of applications needing to mark
> > packets.
> 
> Now I am confused.  You mentioned connmark.
> 
> Are you marking packets or connections?
Both, the first packet in a flow traverses through ip-tables and
multiple applications set rules to mark the packet. Each application
gets a certain area of the 32 bit mark (i.e. one application has bits
0-7, next has 8-15, next has 16-31). Then we store the mark into
connmark. Then as each packet in the flow comes through the first rule
in ip-tables simply restores the connmark and the packet goes to egress.
> 
> Why are 2**32 marks not sufficient?
As I mentioned above each application gets a certain bits of the 32 bit
mark. This allows multiple applications to mark the flow and implement
their desired behaviour.