From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 2/3] netfilter: nf_tables: limit maximum number of elements
Date: Sun, 5 Jan 2014 22:25:25 +0000 [thread overview]
Message-ID: <20140105222525.GB19052@macbook.localnet> (raw)
In-Reply-To: <20140105221404.GA4466@localhost>
On Sun, Jan 05, 2014 at 11:14:04PM +0100, Pablo Neira Ayuso wrote:
> On Sun, Jan 05, 2014 at 09:51:02PM +0000, Patrick McHardy wrote:
> > On Sun, Jan 05, 2014 at 10:18:47PM +0100, Pablo Neira Ayuso wrote:
> > > This patch adds a limit to the maximum number of elements that
> > > belong to a set. It also adds a new field to count the current
> > > number of elements, so in case that limit is reached, we hit
> > > -ENOSPC.
> > >
> > > This patch also adds two new attributes: NFTA_SET_MAXELEMS to
> > > set and to indicate the current limit and NFTA_SET_NUMELEMS
> > > to export the current number of set elements.
> >
> > This affects the API, I'm really opposed to make any temporary
> > fixes, but any temporary fix affecting the API is a complete
> > no go IMO.
>
> We need to limit elements in a set. I think it's not good that you can
> add an unlimited number of sets, right?
>
> This patch is independent of 1/3, which can be discarded. But 3/3
> relies on it.
In that case we should add rehashing. But adding arbitrary limits and
even encoding them in the API is wrong on so many levels. We really
need to abstract this stuff. Constant sets can't grow. If we're using
a hash that's not constant, we can easily either make a resizeable
hash or add a second implementation that's resizable and improve
selection. But the point is, this should be (apart from being constant)
transparent to userspace. The kernel is to provide the implementation,
not the policy.
next prev parent reply other threads:[~2014-01-05 22:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-05 21:18 [PATCH 0/3 nftables RFC] set infrastructure updates Pablo Neira Ayuso
2014-01-05 21:18 ` [PATCH 1/3] netfilter: nf_tables: fix suboptimal set selection Pablo Neira Ayuso
2014-01-05 21:28 ` Patrick McHardy
2014-01-05 21:34 ` Pablo Neira Ayuso
2014-01-05 21:45 ` Patrick McHardy
2014-01-05 22:11 ` Pablo Neira Ayuso
2014-01-05 22:21 ` Patrick McHardy
2014-01-05 21:18 ` [PATCH 2/3] netfilter: nf_tables: limit maximum number of elements Pablo Neira Ayuso
2014-01-05 21:51 ` Patrick McHardy
2014-01-05 22:14 ` Pablo Neira Ayuso
2014-01-05 22:15 ` Pablo Neira Ayuso
2014-01-05 22:25 ` Patrick McHardy [this message]
2014-01-05 21:18 ` [PATCH 3/3] netfilter: nft_hash: use set->maxelems to calculate number of buckets Pablo Neira Ayuso
2014-01-05 21:47 ` Patrick McHardy
2014-01-05 22:12 ` Pablo Neira Ayuso
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=20140105222525.GB19052@macbook.localnet \
--to=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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.