netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@netronome.com>
To: Tom Herbert <tom@herbertland.com>
Cc: David Miller <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	oss-drivers@netronome.com
Subject: Re: [oss-drivers] Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info
Date: Mon, 2 Oct 2017 22:04:09 +0200	[thread overview]
Message-ID: <20171002200408.GA20877@netronome.com> (raw)
In-Reply-To: <CALx6S35DpMWdLVWKSoRdsfROM7=A2p9pLi7n2fMtmqwhSEh5wQ@mail.gmail.com>

On Mon, Oct 02, 2017 at 12:36:33PM -0700, Tom Herbert wrote:
> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.horman@netronome.com> wrote:
> > Move dissection of tunnel info from the flower classifier to the flow
> > dissector where all other dissection occurs.  This should not have any
> > behavioural affect on other users of the flow dissector.

...

> > +static void
> > +__skb_flow_dissect_tunnel_info(const struct sk_buff *skb,
> > +                              struct flow_dissector *flow_dissector,
> > +                              void *target_container)
> > +{
> > +       struct ip_tunnel_info *info;
> > +       struct ip_tunnel_key *key;
> > +
> > +       /* A quick check to see if there might be something to do. */
> > +       if (!dissector_uses_key(flow_dissector,
> > +                               FLOW_DISSECTOR_KEY_ENC_KEYID) &&
> > +           !dissector_uses_key(flow_dissector,
> > +                               FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS) &&
> > +           !dissector_uses_key(flow_dissector,
> > +                               FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS) &&
> > +           !dissector_uses_key(flow_dissector,
> > +                               FLOW_DISSECTOR_KEY_ENC_CONTROL) &&
> > +           !dissector_uses_key(flow_dissector,
> > +                               FLOW_DISSECTOR_KEY_ENC_PORTS))
> > +               return;
> 
> This complex conditional is now in the path of every call to flow
> dissector regardless of whether a classifier is enabled or tunnels
> are. What does the assembly show in terms of number of branches? Can
> we at least get this down to one check (might be a use case for
> FLOW_DISSECTOR_F_FLOWER ;-) ), or even better use the static key when
> encap or is enabled?

Hi Tom,

it appears to me (a little to my surprise but I did check before
posting) that the compiler turns the above into a single comparison.

$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  reply	other threads:[~2017-10-02 20:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02  8:41 [PATCH net-next 0/2] flow_dissector: dissect tunnel info Simon Horman
2017-10-02  8:41 ` [PATCH net-next 1/2] net/dst: Make skb parameter of skb{metadata_dst,tunnel_info}() const Simon Horman
2017-10-02  8:41 ` [PATCH net-next 2/2] flow_dissector: dissect tunnel info Simon Horman
2017-10-02 10:00   ` Jiri Pirko
2017-10-02 19:36   ` Tom Herbert
2017-10-02 20:04     ` Simon Horman [this message]
2017-10-02 20:37   ` Tom Herbert
2017-10-03  9:40     ` Simon Horman
2017-10-03 18:17       ` Tom Herbert
2017-10-04  8:08         ` Simon Horman
2017-10-04  8:15           ` Jiri Pirko
2017-10-04 15:52             ` Tom Herbert
2017-10-04 18:07               ` Jiri Pirko
2017-10-04 19:07                 ` Simon Horman
2017-10-04 19:17                   ` Jiri Pirko
2017-10-02 18:06 ` [PATCH net-next 0/2] " David Miller

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=20171002200408.GA20877@netronome.com \
    --to=simon.horman@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=tom@herbertland.com \
    --cc=xiyou.wangcong@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).