netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miguel Angel Ajo Pelayo <majopela@redhat.com>
To: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Cc: Netfilter Development Mailing list <netfilter-devel@vger.kernel.org>
Subject: Re: conntrack-tool question for contribution.
Date: Mon, 21 Mar 2016 08:51:33 +0100	[thread overview]
Message-ID: <CAC3B9fno2rFjdoddHWF83AbdKyoYZ_g22qyGPYO5SyO68MEBGA@mail.gmail.com> (raw)
In-Reply-To: <CAOkSjBidYJPMAcvnSUShTU1oq5ABUvXKhqaiK7OsWEC6rBOpag@mail.gmail.com>

On Fri, Mar 18, 2016 at 12:59 PM, Arturo Borrero Gonzalez
<arturo.borrero.glez@gmail.com> wrote:
> On 16 March 2016 at 12:16, Miguel Angel Ajo Pelayo <majopela@redhat.com> wrote:
>> I was considering the possibility of making an small contribution to
>> conntrack-tool
>> to allow the batching of commands in a single conntrack-tool call.
>>
>> Specifically I'm interested in batching delete commands.
>>
>> In some of the neutron reference implementations we make use of conntrack-tool
>> to target and kill any active connection when security group rules are removed.
>>
>> That sometimes expands in thousands of calls due to combinations (worst
>> scenario is n_port^2 calls for a very common type of rule we have).
>>
>>
>> So I was considering two options:
>>
>> 1) Adding a mode to accept conntrack-tool actions via stdin
>> 2) Accepting the cmdline notation of separating multiple command lines
>> with "--" in a single call to conntrack tool.
>>
>>
>> Any thoughts or recommendations in this regard?
>>
>
> Hi Miguel Angel,
>
> I wonder if the kernel support batching of messages in ctnetlink. You
> may want to check the sources [0][1].
>
> Perhaps you want the conntrack utility to simply chain a lot of calls
> to the kernel rather than a proper batch of messages. In this case, I
> don't know exactly why but I like more your 2) option.
>
> [0] http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_netlink.c#L3260
> [1] http://lxr.free-electrons.com/source/net/netfilter/nfnetlink.c#L282
>

Hmm, I will have a look into [0][1], I guess the gain of chaining calls
is  saving overhead, right?.

I put 2 up for discussion as 2nd option because of the cmdline limit which
(I guess) is going to be more than enough generally, and because the
ipset cmdline tools accept stdin batches too.

I guess 1 makes chaining (if possible) more complicated, but it could
still be done (less straight forward) in smaller chains, by chaining whatever
you can read without blocking.

      reply	other threads:[~2016-03-21  7:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 11:16 conntrack-tool question for contribution Miguel Angel Ajo Pelayo
2016-03-18 11:59 ` Arturo Borrero Gonzalez
2016-03-21  7:51   ` Miguel Angel Ajo Pelayo [this message]

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=CAC3B9fno2rFjdoddHWF83AbdKyoYZ_g22qyGPYO5SyO68MEBGA@mail.gmail.com \
    --to=majopela@redhat.com \
    --cc=arturo.borrero.glez@gmail.com \
    --cc=netfilter-devel@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).