[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Nov 2015 03:08:16 +0100
From: Florian Westphal <fw@...len.de>
To: Matt Bennett <Matt.Bennett@...iedtelesis.co.nz>
Cc: "fw@...len.de" <fw@...len.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Luuk Paulussen <Luuk.Paulussen@...iedtelesis.co.nz>,
Kyeong Yoo <Kyeong.Yoo@...iedtelesis.co.nz>
Subject: Re: Increasing skb->mark size
Matt Bennett <Matt.Bennett@...iedtelesis.co.nz> wrote:
> On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
> > Matt Bennett <Matt.Bennett@...iedtelesis.co.nz> wrote:
> > > I'm emailing this list for feedback on the feasibility of increasing
> > > skb->mark or adding a new field for marking. Perhaps this extension
> > > could be done under a new CONFIG option. Perhaps there are other ways we
> > > could achieve the desired behaviour?
> >
> > Well I pointed you towards connlabels which provide 128 bit of space
> > in the conntrack extension area but you did not tell me why you cannot
> > use it.
> Sorry, I moved the discussion to this list to hopefully gather some new
> ideas/opinions.
>
> While connlabels provide 128bits of space skb->mark is still only 32
> bits. Since we are using connection tracking to simply restore skb->mark
> the use of connlabels by itself doesn't solve the problem I outlined
> above. skb->mark would still needs to be increased in size.
We have ctnetlink which allows direct setting of ctmark/ctlabels.
Regarding ctlabels, they were originally designed to provide a bit-set
so that ctmark could be used as an 'enumeration' type while ctlabels
could be used to provide distinct, non-overlapping labels.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists