From: Stefano Brivio <sbrivio@redhat.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH,nf-next RFC 0/2] add NFTA_SET_ELEM_KEY_END
Date: Mon, 2 Dec 2019 17:19:52 +0100 [thread overview]
Message-ID: <20191202171952.2e577345@elisabeth> (raw)
In-Reply-To: <20191202131407.500999-1-pablo@netfilter.org>
Hi Pablo,
On Mon, 2 Dec 2019 14:14:05 +0100
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi Stefano,
>
> This patchset extends the netlink API to allow to express an interval
> with one single element.
>
> This simplifies this interface since userspace does not need to send two
> independent elements anymore, one of the including the
> NFT_SET_ELEM_INTERVAL_END flag.
>
> The idea is to use the _DESC to specify that userspace speaks the kernel
> that new API representation. In your case, the new description attribute
> that tells that this set contains interval + concatenation implicitly
> tells the kernel that userspace supports for this new API.
Thanks! I just had a quick look, I think the new set implementation
would indeed look more elegant this way. As to design choices, I'm
afraid I'm not familiar enough with the big picture to comment on the
general idea, but my uninformed opinion agrees with this approach. :)
For what it's worth, I'd review this in deeper detail next.
> If you're fine with this, I can scratch a bit of time to finish the
> libnftnl part. The nft code will need a small update too. You will not
> need to use the nft_set_pipapo object as scratchpad area anymore.
On my side, I'm almost done with nft/libnftnl/kernel changes for the
NFT_SET_DESC_CONCAT thing. How should we proceed? Do you want me to
share those patches so that you can add this bit on top, or should this
come first, or in a separate series?
I could also just share the new nft/libnftnl patches (I should have them
ready between today and tomorrow), and proceed adapting the kernel part
according to your changes.
Related question: to avoid copying data around, I'm now dynamically
allocating a struct nft_data_desc in nf_tables_newset() with a
reference from struct nft_set: desc->dlen, desc->klen, desc->size would
all live there, together with the "subkey" stuff.
Is it a bad idea? I can undo it easily, I just don't know if there's a
specific reason why those fields are repeated in struct nft_set.
--
Stefano
next prev parent reply other threads:[~2019-12-02 16:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 13:14 [PATCH,nf-next RFC 0/2] add NFTA_SET_ELEM_KEY_END Pablo Neira Ayuso
2019-12-02 13:14 ` [PATCH,nf-next RFC 1/2] netfilter: nf_tables: add nft_setelem_parse_key() Pablo Neira Ayuso
2019-12-05 22:43 ` Stefano Brivio
2019-12-06 19:45 ` Pablo Neira Ayuso
2019-12-07 22:51 ` Stefano Brivio
2019-12-09 20:44 ` Pablo Neira Ayuso
2019-12-02 13:14 ` [PATCH,nf-next RFC 2/2] netfilter: nf_tables: add NFTA_SET_ELEM_KEY_END attribute Pablo Neira Ayuso
2019-12-05 22:44 ` Stefano Brivio
2019-12-06 19:52 ` Pablo Neira Ayuso
2019-12-07 22:52 ` Stefano Brivio
2019-12-02 16:19 ` Stefano Brivio [this message]
2019-12-03 11:02 ` [PATCH,nf-next RFC 0/2] add NFTA_SET_ELEM_KEY_END Pablo Neira Ayuso
2019-12-03 15:56 ` Stefano Brivio
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=20191202171952.2e577345@elisabeth \
--to=sbrivio@redhat.com \
--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.