On Thu, 2015-11-19 at 22:32 +0100, Florian Westphal wrote:
> Matt Bennett <Matt.Bennett@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Thu, 2015-11-19 at 04:00 +0100, Florian Westphal wrote:
> > > Matt Bennett <Matt.Bennett@xxxxxxxxxxxxxxxxxxx> 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.
��.n��������+%������w��{.n����z�����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
