netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: tgraf@suug.ch, challa@noironetworks.com, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nf-next v3 1/3] netfilter: nf_conntrack: push zone object into functions
Date: Wed, 5 Aug 2015 12:51:26 +0200	[thread overview]
Message-ID: <20150805105126.GA3996@salvia> (raw)
In-Reply-To: <55BF9023.3050505@iogearbox.net>

On Mon, Aug 03, 2015 at 06:00:35PM +0200, Daniel Borkmann wrote:
> On 08/03/2015 05:59 PM, Pablo Neira Ayuso wrote:
> >On Thu, Jul 30, 2015 at 06:34:48PM +0200, Daniel Borkmann wrote:
> >>CTA_ZONE_DIR seems better, sure. I don't have any other extensions at
> >>the moment, but it seems it makes sense to make this nested at this
> >>point in time, so we have CTA_ZONE and CTA_ZONE_INFO as a container
> >>for CTA_ZONE_DIR and whatever future might bring. I will look into it.
> >
> >thinking it well, this is part of the tuple, so I'd suggest you add
> >CTA_TUPLE_ZONE to enum ctattr_tuple. We will probably need later to
> >place each tuple in different zones.
> 
> That's fine with me, will do after your tree rebase.

Just pushed out a fresh copy with net-next into nf-next.

Daniel, a minor change that I came up with. With your patchset, the
configurations that we accept look like:

        zone original=Value     reply=0
        zone original=0         reply=Value

But thinking on Thomas' requirements to limit the number of conntracks
per zone, I think another valid configuration (and more generic) can
be:

        zone original=ValueX    reply=ValueY

So we don't assume that the original or reply zone is always zero.

The zone extension are that look like this:

struct nf_conntrack_zone {
        u16     id[IP_CT_DIR_MAX];
};

And we don't need to store the direction. To keep backward
compatibility we can set the id in both directions to the same value.

Can you see any problem with this approach? I think it should require
just a little adjustment to you patchset. Thanks.

  reply	other threads:[~2015-08-05 10:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 10:54 [PATCH nf-next v3 0/3] Netfilter zone directions Daniel Borkmann
2015-07-22 10:54 ` [PATCH nf-next v3 1/3] netfilter: nf_conntrack: push zone object into functions Daniel Borkmann
2015-07-30 16:07   ` Pablo Neira Ayuso
2015-07-30 16:34     ` Daniel Borkmann
2015-08-03 15:59       ` Pablo Neira Ayuso
2015-08-03 16:00         ` Daniel Borkmann
2015-08-05 10:51           ` Pablo Neira Ayuso [this message]
2015-08-05 14:00             ` Daniel Borkmann
2015-08-06 10:02               ` Pablo Neira Ayuso
2015-07-22 10:54 ` [PATCH nf-next v3 2/3] netfilter: nf_conntrack: add direction support for zones Daniel Borkmann
2015-07-22 10:54 ` [PATCH nf-next v3 3/3] netfilter: nf_conntrack: add efficient mark to zone mapping Daniel Borkmann

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=20150805105126.GA3996@salvia \
    --to=pablo@netfilter.org \
    --cc=challa@noironetworks.com \
    --cc=daniel@iogearbox.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=tgraf@suug.ch \
    /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).