netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft] datatype, meta: add new ifname_type for iifname/oifname
Date: Tue, 1 Mar 2016 11:11:14 +0100	[thread overview]
Message-ID: <20160301101114.GA2654@salvia> (raw)
In-Reply-To: <20160229131923.GB7277@breakpoint.cc>

On Mon, Feb 29, 2016 at 02:19:23PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > The problem is that unqualified types cannot be currently used because
> > the have no specific length.
> 
> Yes.
>
> > Carlos has been submitting patches for a while (he's on Cc) that it
> > would be great to see in the tree at some point this week. Basically,
> > he's introducing a TLV infrastructure to store metainformation in the
> > USERDATA area.
> > 
> > The idea is to use these new TLVs to include the length of this
> > datatype. This allows us to interpret the data when dumping it from
> > the kernel and transform it to object via set_delinearize().
> 
> Ok, but how do you plan to handle the key length?

Right, in concatenations we can infer this from the lhs, but in set
definitions there is not way.

> Currently the kernel will -EINVAL in nf_tables_newset() because the
> key length is 0 for unqualified types.
> 
> Since nft has no information on the element keys (yet) I don't see
> how the TLV infrastructure helps in this case.

With the introduction of TLV infrastructure, the idea is to add a
length field to the TLV, so we have that type is "string" and the
corresponding length.

Similar thing for other meta matching such as cpu and any header field
that we should potentially support.

What I would suggest is to recover a patch that Patrick submitted that
introduces typeof(X) so we can use this from set definitions. We can
store in the TLV the original subtype X as a string. Thus, when
listing back to userspace we can use this information to display back
the typeof(X).

We have to potentially support every meta and packet selector,
including crazy ones as 48 bits fields, and last time we discussed
this, we agreed that adding one type per field size is not the way to
go.

I also like the typeof(X) so I don't have to remember myself all
available datatypes when using this.

Let me know your opinion on this, thanks!

  reply	other threads:[~2016-03-01 10:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 19:19 [PATCH nft] datatype, meta: add new ifname_type for iifname/oifname Florian Westphal
2016-02-29 13:12 ` Pablo Neira Ayuso
2016-02-29 13:19   ` Florian Westphal
2016-03-01 10:11     ` Pablo Neira Ayuso [this message]
2016-03-01 11:00       ` Florian Westphal
2016-03-01 13:15         ` 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=20160301101114.GA2654@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --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).