All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Anders K. Pedersen | Cohaesio" <akp@cohaesio.com>
Cc: "fw@strlen.de" <fw@strlen.de>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nf-next] netfilter: nf_meta: support for nexthop and nexthop6
Date: Thu, 22 Sep 2016 11:39:42 +0200	[thread overview]
Message-ID: <20160922093942.GA11850@salvia> (raw)
In-Reply-To: <1474434441.1021.42.camel@cohaesio.com>

On Wed, Sep 21, 2016 at 05:07:22AM +0000, Anders K. Pedersen | Cohaesio wrote:
> Hi Pablo,
> 
> On tir, 2016-09-20 at 17:28 +0200, Pablo Neira Ayuso wrote:
> > Hi Anders,
> > 
> > On Wed, Sep 14, 2016 at 05:47:08AM +0000, Anders K. Pedersen |
> > Cohaesio wrote:
> > > Add meta support for IPv4 nexthop and IPv6 nexthop6 (i.e. the
> > > directly
> > > connected IP address that an outgoing packet is sent to), which can
> > > be used
> > > either for matching or accounting, eg.
> 
> > Florian is working on explicitly fib lookup expression, 
> 
> I had noticed his RFC before doing this, but thought that it wouldn't
> be ideal for my use case, since 1) it might not give the route that is
> actually used in case of ECMP, and 2) it would be less efficient to
> perform an additional route lookup in stead of just reusing the one
> that has to be performed anyway for routing the packet - especially on
> a router with a full BGP feed (currently close to 600.000 routes).

Sorry, I didn't mean we should select fib or rt, I think they have
both valid usecases. So I'm fine with what you're doing.

[...]
> > Would you have a look at this? Let me know, thanks!
> 
> I had an initial look at this and found that it would involve
> modifying/creating the following files:
> 
> nf-next:
> include/net/netfilter/nft_rt.h - new file based on nft_meta.h
> include/uapi/linux/netfilter/nf_tables.h
>  - new NFT_RT_* and NFTA_RT_* - based on what exists for nft_meta
> net/netfilter/{Kconfig,Makefile} - new config NFT_RT and NFT_RT_INET
> net/netfilter/nft_rt.c - new file based on nft_meta.c
> net/netfilter/nft_rt_inet.c - new file based on nft_meta_bridge.c
> net/ipv4/netfilter/{Kconfig,Makefile} - new config NFT_RT_IPV4
> net/ipv4/netfilter/nft_rt_ipv4.c - new file based on nft_meta_bridge.c
> net/ipv6/netfilter/{Kconfig,Makefile} - new config NFT_RT_IPV6
> net/ipv6/netfilter/nft_rt_ipv6.c - new file based on nft_meta_bridge.c
> 
> libnftnl:
> include/linux/netfilter/nf_tables.h - same as kernel changes
> include/libnftnl/expr.h - add new NFTNL_EXPR_RT_* and NFT_EXPR_RT_*
> src/expr/rt.c - new file based on meta.c
> src/expr_ops.c - add references to expr_ops_rt
> src/Makefile.am - add expr/rt.c
> 
> nftables:
> doc/nft.xml - document new rt expression
> include/linux/netfilter/nf_tables.h - same as kernel changes
> include/expression.h - add new EXPR_RT
> include/rt.h - new file based on meta.h
> include/statement.h - add new STMT_RT and rt_stmt
> src/evaluate.c - add handling of EXPR_RT and STMT_RT
> src/netlink_linearize.c - add handling of EXPR_RT and STMT_RT
> src/netlink_delinearize.c - add handling of EXPR_RT and STMT_RT
> src/rt.c - new file based on meta.c
> src/Makefile.am - add rt.c to nft_SOURCES
> src/parser_bison.y - define new keywords and syntax
> src/scanner.l - define new keywords
> 
> Does this seem right, or have I missed something?
> 
> It looks like quite a bit more code than my first attempt, but I can
> give it a try. I don't know how much time I'll have for this, so it
> will probably take some weeks to do.

Yes, it's a bit of more code than this, but if there are more usecase
to access the skb_rtable(), then this makes sense to me.

And no problem wrt. time.

Please, let us know if you have any problem. Thanks!

      reply	other threads:[~2016-09-22  9:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14  5:47 [PATCH nf-next] netfilter: nf_meta: support for nexthop and nexthop6 Anders K. Pedersen | Cohaesio
2016-09-20 15:28 ` Pablo Neira Ayuso
2016-09-21  5:07   ` Anders K. Pedersen | Cohaesio
2016-09-22  9:39     ` Pablo Neira Ayuso [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=20160922093942.GA11850@salvia \
    --to=pablo@netfilter.org \
    --cc=akp@cohaesio.com \
    --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 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.