linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: kan.liang@intel.com
Cc: David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
	Netdev <netdev@vger.kernel.org>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	James Morris <jmorris@namei.org>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Patrick McHardy <kaber@trash.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	keescook@chromium.org, viro@zeniv.linux.org.uk,
	gorcunov@openvz.org, john.stultz@linaro.org,
	Alex Duyck <aduyck@mirantis.com>,
	Ben Hutchings <ben@decadent.org.uk>,
	decot@googlers.com, "Brandeburg,
	Jesse" <jesse.brandeburg@intel.com>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC PATCH 23/30] i40e/ethtool: support RX_CLS_LOC_ANY
Date: Mon, 18 Jul 2016 09:21:22 -0700	[thread overview]
Message-ID: <CAKgT0UeLeZOj2Z3Zhi_t+2D8xpvtu4WdQPO1zALC5DJ=zsGXEw@mail.gmail.com> (raw)
In-Reply-To: <1468824984-65318-24-git-send-email-kan.liang@intel.com>

On Sun, Jul 17, 2016 at 11:56 PM,  <kan.liang@intel.com> wrote:
> From: Kan Liang <kan.liang@intel.com>
>
> The existing special location RX_CLS_LOC_ANY flag is designed for the
> case which the caller does not know/care about the location. Now, this
> flag is only handled in ethtool user space. If the kernel directly calls
> the ETHTOOL_SRXCLSRLINS interface with RX_CLS_LOC_ANY flag set, it will
> error out.
> This patch implements the RX_CLS_LOC_ANY support for i40e driver. It
> finds the available location from the end of the list.
>
> Signed-off-by: Kan Liang <kan.liang@intel.com>

Instead of reinventing the wheel you may wan to take a look at using
ndo_rx_flow_steer instead.  It was basically meant to be used for
kernel space applications to be able to add flow director rules.

> ---
>  drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 38 ++++++++++++++++++++++++--
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index 1f3537e..4276ed7 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -2552,6 +2552,32 @@ static int i40e_del_fdir_entry(struct i40e_vsi *vsi,
>         return ret;
>  }
>
> +static int find_empty_slot(struct i40e_pf *pf)
> +{
> +       struct i40e_fdir_filter *rule;
> +       struct hlist_node *node2;
> +       __u32 data = i40e_get_fd_cnt_all(pf);
> +       unsigned long *slot;
> +       int i;
> +
> +       slot = kzalloc(BITS_TO_LONGS(data) * sizeof(long), GFP_KERNEL);
> +       if (!slot)
> +               return -ENOMEM;
> +
> +       hlist_for_each_entry_safe(rule, node2,
> +                                 &pf->fdir_filter_list, fdir_node) {
> +               set_bit(rule->fd_id, slot);
> +       }
> +
> +       for (i = data - 1; i > 0; i--) {
> +               if (!test_bit(i, slot))
> +                       break;
> +       }
> +       kfree(slot);
> +
> +       return i;
> +}
> +

This doesn't seem like a very efficient way to find free slots.  If
you are wanting to make this efficient you might just want to keep the
bitmap always allocated.  In addition if you rewrite this so that it
keeps a variable that you can do a simple increment and test with you
will probably find that more often then not you will be able to find a
free slot on your first try.

>  /**
>   * i40e_add_fdir_ethtool - Add/Remove Flow Director filters
>   * @vsi: pointer to the targeted VSI
> @@ -2588,9 +2614,15 @@ static int i40e_add_fdir_ethtool(struct i40e_vsi *vsi,
>
>         fsp = (struct ethtool_rx_flow_spec *)&cmd->fs;
>
> -       if (fsp->location >= (pf->hw.func_caps.fd_filters_best_effort +
> -                             pf->hw.func_caps.fd_filters_guaranteed)) {
> -               return -EINVAL;
> +       if (fsp->location != RX_CLS_LOC_ANY) {
> +               if (fsp->location >= (pf->hw.func_caps.fd_filters_best_effort +
> +                                     pf->hw.func_caps.fd_filters_guaranteed)) {
> +                       return -EINVAL;
> +               }
> +       } else {
> +               fsp->location = find_empty_slot(pf);
> +               if (fsp->location < 0)
> +                       return -ENOSPC;
>         }
>
>         if ((fsp->ring_cookie != RX_CLS_FLOW_DISC) &&

The ethtool interface isn't really meant to be used for writing rules
from kernel space.  You would likely be much better off just using
ndo_rx_flow_steer instead.  Then it will even give you information
back on where the rule you created now resides.

- Alex

  reply	other threads:[~2016-07-18 16:21 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18  6:55 [RFC PATCH 00/30] Kernel NET policy kan.liang
2016-07-18  6:55 ` [RFC PATCH 01/30] net: introduce " kan.liang
2016-07-18  6:55 ` [RFC PATCH 02/30] net/netpolicy: init " kan.liang
2016-07-18  6:55 ` [RFC PATCH 03/30] i40e/netpolicy: Implement ndo_netpolicy_init kan.liang
2016-07-18  6:55 ` [RFC PATCH 04/30] net/netpolicy: get driver information kan.liang
2016-07-18  6:55 ` [RFC PATCH 05/30] i40e/netpolicy: implement ndo_get_irq_info kan.liang
2016-07-18  6:56 ` [RFC PATCH 06/30] net/netpolicy: get CPU information kan.liang
2016-07-18  6:56 ` [RFC PATCH 07/30] net/netpolicy: create CPU and queue mapping kan.liang
2016-07-18  6:56 ` [RFC PATCH 08/30] net/netpolicy: set and remove irq affinity kan.liang
2016-07-18  6:56 ` [RFC PATCH 09/30] net/netpolicy: enable and disable net policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 10/30] net/netpolicy: introduce netpolicy object kan.liang
2016-07-18  6:56 ` [RFC PATCH 11/30] net/netpolicy: set net policy by policy name kan.liang
2016-07-18  6:56 ` [RFC PATCH 12/30] i40e/netpolicy: implement ndo_set_net_policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 13/30] i40e/netpolicy: add three new net policies kan.liang
2016-07-18  6:56 ` [RFC PATCH 14/30] net/netpolicy: add MIX policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 15/30] i40e/netpolicy: add MIX policy support kan.liang
2016-07-18  6:56 ` [RFC PATCH 16/30] net/netpolicy: net device hotplug kan.liang
2016-07-18  6:56 ` [RFC PATCH 17/30] net/netpolicy: support CPU hotplug kan.liang
2016-07-18  6:56 ` [RFC PATCH 18/30] net/netpolicy: handle channel changes kan.liang
2016-07-18  6:56 ` [RFC PATCH 19/30] net/netpolicy: implement netpolicy register kan.liang
2016-07-18  6:56 ` [RFC PATCH 20/30] net/netpolicy: introduce per socket netpolicy kan.liang
2016-07-18  6:56 ` [RFC PATCH 21/30] net/policy: introduce netpolicy_pick_queue kan.liang
2016-07-18  6:56 ` [RFC PATCH 22/30] net/netpolicy: set tx queues according to policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 23/30] i40e/ethtool: support RX_CLS_LOC_ANY kan.liang
2016-07-18 16:21   ` Alexander Duyck [this message]
2016-07-18  6:56 ` [RFC PATCH 24/30] net/netpolicy: set rx queues according to policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 25/30] net/netpolicy: introduce per task net policy kan.liang
2016-07-18  6:56 ` [RFC PATCH 26/30] net/netpolicy: set per task policy by proc kan.liang
2016-07-18  6:56 ` [RFC PATCH 27/30] net/netpolicy: fast path for finding the queues kan.liang
2016-07-18  6:56 ` [RFC PATCH 28/30] net/netpolicy: optimize for queue pair kan.liang
2016-07-18  6:56 ` [RFC PATCH 29/30] net/netpolicy: limit the total record number kan.liang
2016-07-18  6:56 ` [RFC PATCH 30/30] Documentation/networking: Document net policy kan.liang
2016-07-18 16:58   ` Randy Dunlap
2016-07-18 15:18 ` [RFC PATCH 00/30] Kernel NET policy Florian Westphal
2016-07-18 15:45   ` Andi Kleen
2016-07-18 17:52     ` Cong Wang
2016-07-18 20:14       ` Liang, Kan
2016-07-18 20:19         ` Cong Wang
2016-07-18 20:24           ` Liang, Kan
2016-07-18 19:04     ` Hannes Frederic Sowa
2016-07-18 19:43       ` Andi Kleen
2016-07-18 21:51         ` Hannes Frederic Sowa
2016-07-19  1:49           ` Liang, Kan
2016-07-19  5:03             ` David Miller
2016-07-19 13:43               ` Liang, Kan
2016-07-18 15:51   ` Liang, Kan
2016-07-18 16:17     ` Florian Westphal
2016-07-18 17:40       ` Liang, Kan
2016-07-18 16:34     ` Tom Herbert
2016-07-18 17:58       ` Liang, Kan
2016-07-18 16:22 ` Daniel Borkmann
2016-07-18 18:30   ` Liang, Kan
2016-07-18 20:51     ` Daniel Borkmann
2016-07-18 17:00 ` Alexander Duyck
2016-07-18 19:45   ` Liang, Kan
2016-07-18 19:49     ` Andi Kleen

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='CAKgT0UeLeZOj2Z3Zhi_t+2D8xpvtu4WdQPO1zALC5DJ=zsGXEw@mail.gmail.com' \
    --to=alexander.duyck@gmail.com \
    --cc=aduyck@mirantis.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=ben@decadent.org.uk \
    --cc=davem@davemloft.net \
    --cc=decot@googlers.com \
    --cc=gorcunov@openvz.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jmorris@namei.org \
    --cc=john.stultz@linaro.org \
    --cc=kaber@trash.net \
    --cc=kan.liang@intel.com \
    --cc=keescook@chromium.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yoshfuji@linux-ipv6.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).