netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz>
To: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>,
	"fw@strlen.de" <fw@strlen.de>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Kyeong Yoo <Kyeong.Yoo@alliedtelesis.co.nz>
Subject: Re: Increasing skb->mark size
Date: Thu, 26 Nov 2015 04:44:41 +0000	[thread overview]
Message-ID: <56568E33.4090707@alliedtelesis.co.nz> (raw)
In-Reply-To: <1448398614.14854.39.camel@mattb-dl>



On 11/25/2015 09:56 AM, Matt Bennett wrote:
> On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
>> Matt Bennett <Matt.Bennett@alliedtelesis.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.
I've been looking into this further and it does look like something like 
connlabels could be useful in certain cases.  For example, netfilter 
could be used to classify a packet based on its label, rather than 
saving the mark and then classifying/filtering based on the mark in the 
tc subsystem.  However, it looks like currently connlabels is set up 
around setting/clearing individual bits, rather than using masks, so 
while there are 128 bits, it doesn't actually give us that many more 
distinct marks.

  reply	other threads:[~2015-11-26  4:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 20:32 Increasing skb->mark size Matt Bennett
2015-11-24 20:36 ` Florian Westphal
2015-11-24 20:56   ` Matt Bennett
2015-11-26  4:44     ` Luuk Paulussen [this message]
2015-11-30  2:08     ` Florian Westphal
2015-11-30  2:10       ` Lorenzo Colitti
2015-11-30  2:24         ` Florian Westphal
2015-11-29  8:37 ` Lorenzo Colitti
2015-11-30  1:58   ` David Miller
2015-11-30  4:10     ` Luuk Paulussen
2015-11-30  4:49       ` David Miller
2015-12-01  0:12         ` Luuk Paulussen
2015-12-01  3:55           ` David Miller
2015-12-01  4:57             ` Luuk Paulussen
2015-12-01 19:13   ` Andi Kleen
2015-12-01 22:09     ` Daniel Borkmann
2015-12-02  2:58       ` Andi Kleen
2015-12-02  5:42         ` David Ahern
2015-12-02 17:29           ` David Miller
2015-12-02  3:57     ` Lorenzo Colitti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56568E33.4090707@alliedtelesis.co.nz \
    --to=luuk.paulussen@alliedtelesis.co.nz \
    --cc=Kyeong.Yoo@alliedtelesis.co.nz \
    --cc=Matt.Bennett@alliedtelesis.co.nz \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).