Extending connmark to 64 bits

Extending connmark to 64 bits

[Matt Bennett]

Hello,

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)?

If it is not possible to extend this field then perhaps there are other
options (beyond disabling some features making use of connection
tracking)?

Thanks,
Matt

Re: Extending connmark to 64 bits

[Florian Westphal]

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.

> If it is not possible to extend this field then perhaps there are other
> options (beyond disabling some features making use of connection
> tracking)?

Have you looked at using conntrack labels?

Its a 128bit storage area.

Re: Extending connmark to 64 bits

[Matt Bennett]

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? The number of bits available for marking becomes the
limiting factor when you have a number of applications needing to mark
packets.
> 
> > If it is not possible to extend this field then perhaps there are other
> > options (beyond disabling some features making use of connection
> > tracking)?
> 
> Have you looked at using conntrack labels?
> 
> Its a 128bit storage area.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending connmark to 64 bits

[Florian Westphal]

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?

Why are 2**32 marks not sufficient?

Re: Extending connmark to 64 bits

[Matt Bennett]

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.