All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Luuk Paulussen <Luuk.Paulussen@alliedtelesis.co.nz>
Subject: Increasing skb->mark size
Date: Tue, 24 Nov 2015 20:32:24 +0000	[thread overview]
Message-ID: <1448397144.14854.27.camel@mattb-dl> (raw)

Hello,

Currently we have a number of router features (firewall, QoS, etc)
making use of ip tables and connection tracking. We do this by giving
each feature a certain area of skb->mark (say 8 bits each). This allows
us to simply restore skb->mark (using connection tracking) for packets
in a flow using the logic below.

Our software logic is:

1. The first packet in a flow traverses through ip-tables where
each feature has set rules to mark their section of skb->mark. 

2. We then store the mark into connmark. 

3. Then as each packet in the flow hits ip tables the first rule in
ip-tables simply restores the connmark and the packet goes to egress.

Up until now this has worked very well for us. However since skb->mark
is only 32 bits we have quickly run out of bits for marking. 

This leaves us with two options:
 - Don't allow all features to be enabled at once (i.e. multiple
features share the same area of skb->mark). This is not ideal.

 - Increase the size of skb->mark (or another solution such as adding an
additional field into sk_buff for marking).

Hopefully what I have explained above is a strong example of where
skb->mark is no longer large enough on routers using connection tracking
to achieve superior performance. 

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?

Thanks,
Matt

             reply	other threads:[~2015-11-24 20:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 20:32 Matt Bennett [this message]
2015-11-24 20:36 ` Increasing skb->mark size Florian Westphal
2015-11-24 20:56   ` Matt Bennett
2015-11-26  4:44     ` Luuk Paulussen
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=1448397144.14854.27.camel@mattb-dl \
    --to=matt.bennett@alliedtelesis.co.nz \
    --cc=Luuk.Paulussen@alliedtelesis.co.nz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.