From: Martin Willi <martin@strongswan.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: David Ahern <dsahern@kernel.org>,
Shrijeet Mukherjee <shrijeet@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH net] vrf: Fix fast path output packet handling with async Netfilter rules
Date: Tue, 10 Nov 2020 16:02:13 +0100 [thread overview]
Message-ID: <2df88651a28cf77daf09e3d1282261d518794629.camel@strongswan.org> (raw)
In-Reply-To: <20201110133506.GA1777@salvia>
Hi Pablo,
> > +static int vrf_output6_direct_finish(struct net *net, struct sock *sk,
> > + struct sk_buff *skb)
> > +{
> > + vrf_finish_direct(skb);
> > +
> > + return vrf_ip6_local_out(net, sk, skb);
> > +}
> > +
> > static int vrf_output6_direct(struct net *net, struct sock *sk,
> > struct sk_buff *skb)
> > {
> > + int err = 1;
> > +
> > skb->protocol = htons(ETH_P_IPV6);
> >
> > - return NF_HOOK_COND(NFPROTO_IPV6, NF_INET_POST_ROUTING,
> > - net, sk, skb, NULL, skb->dev,
> > - vrf_finish_direct,
> > - !(IPCB(skb)->flags & IPSKB_REROUTED));
> > + if (!(IPCB(skb)->flags & IPSKB_REROUTED))
> > + err = nf_hook(NFPROTO_IPV6, NF_INET_POST_ROUTING, net, sk, skb,
> > + NULL, skb->dev, vrf_output6_direct_finish);
>
> I might missing something... this looks very similar to NF_HOOK_COND
> but it's open-coded.
>
> My question, could you still use NF_HOOK_COND?
>
> ret = NF_HOOK_COND(NFPROTO_IPV6, ..., vrf_output6_direct_finish);
>
> just update the okfn.
I don't think this will work. The point of the patch is to have
different paths for sync and async Netfilter rules: In the async case
we call vrf_output6_direct_finish() to additionally do dst_output(). In
the (existing) synchronous path we just do vrf_finish_direct() and let
the caller do the dst_output().
If we prefer a common okfn(), we could return 0 to omit dst_output() in
ip/ip6_local_out(). This changes/extends the call stack for the common
case, though, and this is what I've tried to avoid.
> > + if (likely(err == 1))
>
> I'd suggest you remove likely() here and elsewhere in this patch.
> Just let the branch predictor make its work instead of assuming that
> the ruleset accepts traffic.
The likely() may be questionable, but I seems that is done in most
places when checking for synchronous Netfilter completion. But I'm fine
with changing these hunks, if you prefer.
Thanks,
Martin
next prev parent reply other threads:[~2020-11-10 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 7:30 [PATCH net] vrf: Fix fast path output packet handling with async Netfilter rules Martin Willi
2020-11-09 23:44 ` Jakub Kicinski
2020-11-10 4:04 ` David Ahern
2020-11-10 13:35 ` Pablo Neira Ayuso
2020-11-10 15:02 ` Martin Willi [this message]
2020-11-11 23:43 ` Pablo Neira Ayuso
2020-11-12 15:49 ` Jakub Kicinski
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=2df88651a28cf77daf09e3d1282261d518794629.camel@strongswan.org \
--to=martin@strongswan.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=shrijeet@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 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).