All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Liping Zhang <zlpnobody@gmail.com>
Cc: "Anders K. Pedersen | Cohaesio" <akp@cohaesio.com>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family
Date: Fri, 21 Oct 2016 18:58:30 +0200	[thread overview]
Message-ID: <20161021165830.GA1556@salvia> (raw)
In-Reply-To: <CAML_gOfecSTOHk-qSGhSwO4pFY9MW5FcBiFyZkqKZM4RAgL2NQ@mail.gmail.com>

On Fri, Oct 21, 2016 at 09:22:09PM +0800, Liping Zhang wrote:
> Hi Pablo,
> 
> 2016-10-21 17:21 GMT+08:00 Pablo Neira Ayuso <pablo@netfilter.org>:
> [...]
> >> In init ctx->afi->family is available, a example code is in nft_ct_get_init(),
> >> you can take a look at this.
> >
> > ctx->afi->family indicates NFPROTO_INET in this case, so we have no
> > way to know if the user is requesting rt IPv4 or rt IPv6 from there.
> 
> Yes, but I find that the NFTA_RT_FAMILY attr seems only useful
> in init routine. For INET family, the length can simply to be setted
> to sizeof(struct in6_addr), i.e:
>     switch (ctx->afi->family) {
>         case IPV4:
>               len = 4;
>               break;
>         case IPV6:
>         case INET:
>               len = 16;
>               break;
>      }
>      ...
>      return nft_validate_register_store(..., len, ...);
> 
> The drawback of this implementation is that the user cannot
> specify dreg to NFT_REG32_13, NFT_REG32_14 and
> NFT_REG32_15 when we use rt4 nexthop in INET family.
> 
> But since the same problem exists when we use rt6 nexthop in
> INET/IPV6 family, so I think this will not be a problem.
>
> And for eval, nft rules can be interpreted as following:
> (1) nft add rule filter inet output rt ip nexthop ... --debug=netlink
> [ meta load nfproto => reg 1 ]
> [ cmp eq reg 1 0x00000002 ]
> [ rt nexthop => reg 1 ]
> ...
> 
> (2) nft add rule filter inet output rt ip6 nexthop ... --debug=netlink
> [ meta load nfproto => reg 1 ]
> [ cmp eq reg 1 0x0000000a ]
> [ rt nexthop => reg 1 ]
> ...
> 
> So I think we cannot earn much benefits from the NFTA_RT_FAMILY attr.
> Or I missed something?

We still need datatype information for the inet family, from the
netlink_delinearize step, when dumping back the policy to userspace.
Given that we cannot infer the datatype from the data size, as this
would be 16 bytes for both cases, we would still need to annotate this
context information somewhere. The existing approach is providing this
datatype information.

  reply	other threads:[~2016-10-21 16:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-19 18:34 [PATCH v2 nf-next 0/5] netfilter: nft: introduce routing expression Anders K. Pedersen | Cohaesio
2016-10-19 18:35 ` [PATCH v2 nf-next 1/5] netfilter: nft: UAPI headers for " Anders K. Pedersen | Cohaesio
2016-10-19 18:38 ` [PATCH v2 nf-next 2/5] netfilter: nft: basic " Anders K. Pedersen | Cohaesio
2016-10-19 18:39 ` [PATCH v2 nf-next 3/5] netfilter: nft: rt nexthop for IPv4 family Anders K. Pedersen | Cohaesio
2016-10-19 18:40 ` [PATCH v2 nf-next 4/5] netfilter: nft: rt nexthop for IPv6 family Anders K. Pedersen | Cohaesio
2016-10-19 18:41 ` [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family Anders K. Pedersen | Cohaesio
2016-10-20  9:13   ` Liping Zhang
2016-10-20 12:36     ` Anders K. Pedersen | Cohaesio
2016-10-20 13:27       ` Liping Zhang
2016-10-20 13:52         ` Anders K. Pedersen | Cohaesio
2016-10-21  2:06           ` Liping Zhang
2016-10-21  4:16             ` Anders K. Pedersen | Cohaesio
2016-10-21  6:17               ` Liping Zhang
2016-10-21  8:26                 ` Anders K. Pedersen | Cohaesio
2016-10-21 12:42                   ` Liping Zhang
2016-10-22 15:25                     ` Anders K. Pedersen | Cohaesio
2016-10-21  9:21                 ` Pablo Neira Ayuso
2016-10-21 13:22                   ` Liping Zhang
2016-10-21 16:58                     ` Pablo Neira Ayuso [this message]
2016-10-22  1:44                       ` Liping Zhang
2016-10-22 16:08                         ` Anders K. Pedersen | Cohaesio
2016-10-23  5:01                           ` Liping Zhang
2016-10-27 17:50                             ` 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=20161021165830.GA1556@salvia \
    --to=pablo@netfilter.org \
    --cc=akp@cohaesio.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=zlpnobody@gmail.com \
    /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.