From: John Fastabend <john.fastabend@gmail.com>
To: Amir Vadai <amir@vadai.me>, "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org,
John Fastabend <john.r.fastabend@intel.com>,
Jiri Pirko <jiri@mellanox.com>,
Or Gerlitz <ogerlitz@mellanox.com>,
Saeed Mahameed <saeedm@mellanox.com>,
Hadar Har-Zion <hadarh@mellanox.com>,
Rony Efraim <ronye@mellanox.com>
Subject: Re: [PATCH net-next V2 01/10] net/flower: Introduce hardware offload support
Date: Fri, 04 Mar 2016 09:01:39 -0800 [thread overview]
Message-ID: <56D9BF73.3050101@gmail.com> (raw)
In-Reply-To: <1457016960-27832-2-git-send-email-amir@vadai.me>
On 16-03-03 06:55 AM, Amir Vadai wrote:
> This patch is based on a patch made by John Fastabend.
> It adds support for offloading cls_flower.
> when NETIF_F_HW_TC is on:
> flags = 0 => Rule will be processed twice - by hardware, and if
> still relevant, by software.
> flags = SKIP_HW => Rull will be processed by software only
>
> If hardare fail/not capabale to apply the rule, operation will fail.
>
> Suggested-by: John Fastabend <john.r.fastabend@intel.com>
> Signed-off-by: Amir Vadai <amir@vadai.me>
> ---
[...]
> static bool fl_destroy(struct tcf_proto *tp, bool force)
> {
> struct cls_fl_head *head = rtnl_dereference(tp->root);
> @@ -174,6 +220,7 @@ static bool fl_destroy(struct tcf_proto *tp, bool force)
> return false;
>
> list_for_each_entry_safe(f, next, &head->filters, list) {
> + fl_hw_destroy_filter(tp, (u64)f);
> list_del_rcu(&f->list);
> call_rcu(&f->rcu, fl_destroy_filter);
> }
> @@ -454,11 +501,13 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> u32 handle, struct nlattr **tca,
> unsigned long *arg, bool ovr)
> {
> + struct net_device *dev = tp->q->dev_queue->dev;
> struct cls_fl_head *head = rtnl_dereference(tp->root);
> struct cls_fl_filter *fold = (struct cls_fl_filter *) *arg;
> struct cls_fl_filter *fnew;
> struct nlattr *tb[TCA_FLOWER_MAX + 1];
> struct fl_flow_mask mask = {};
> + u32 flags = 0;
> int err;
>
> if (!tca[TCA_OPTIONS])
> @@ -486,6 +535,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> }
> fnew->handle = handle;
>
> + if (tb[TCA_FLOWER_FLAGS])
> + flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]);
> +
> err = fl_set_parms(net, tp, fnew, &mask, base, tb, tca[TCA_RATE], ovr);
> if (err)
> goto errout;
> @@ -498,9 +550,22 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> head->ht_params);
> if (err)
> goto errout;
> - if (fold)
> +
> + err = fl_hw_replace_filter(tp,
> + &head->dissector,
> + &mask.key,
> + &fnew->key,
> + &fnew->exts,
> + (u64)fnew,
> + flags);
> + if (err)
> + goto err_hash_remove;
> +
This behaviour is different than how I did u32 in the u32 case I just
let the software case get loaded and do not throw any errors. The
intent was if we required a HW entry we would explicitly state that
with the SKIP_SW (to be implemented) flag. This error path seems
to block the software filter when the hardware fails.
I think it would be best to do the same as u32 here and use the error
path only if SKIP_SW is set. Or if you really want an error path on
SW/HW loads then use another bit in the flag to specify STRICT or
something along those lines.
> + if (fold) {
> rhashtable_remove_fast(&head->ht, &fold->ht_node,
> head->ht_params);
> + fl_hw_destroy_filter(tp, (u64)fold);
> + }
>
> *arg = (unsigned long) fnew;
>
> @@ -514,6 +579,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
>
> return 0;
>
> +err_hash_remove:
> + rhashtable_remove_fast(&head->ht, &fnew->ht_node, head->ht_params);
> +
> errout:
> kfree(fnew);
> return err;
> @@ -527,6 +595,7 @@ static int fl_delete(struct tcf_proto *tp, unsigned long arg)
> rhashtable_remove_fast(&head->ht, &f->ht_node,
> head->ht_params);
> list_del_rcu(&f->list);
> + fl_hw_destroy_filter(tp, (u64)f);
> tcf_unbind_filter(tp, &f->res);
> call_rcu(&f->rcu, fl_destroy_filter);
> return 0;
>
next prev parent reply other threads:[~2016-03-04 17:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 14:55 [PATCH net-next V2 00/10] cls_flower hardware offload support Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 01/10] net/flower: Introduce " Amir Vadai
2016-03-03 14:57 ` Jiri Pirko
2016-03-03 17:30 ` David Miller
2016-03-03 19:53 ` Amir Vadai"
2016-03-04 17:01 ` John Fastabend [this message]
2016-03-06 9:00 ` Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 02/10] net/flow_dissector: Make dissector_uses_key() and skb_flow_dissector_target() public Amir Vadai
2016-03-03 14:57 ` Jiri Pirko
2016-03-04 16:55 ` John Fastabend
2016-03-03 14:55 ` [PATCH net-next V2 03/10] net/sched: Macro instead of CONFIG_NET_CLS_ACT ifdef Amir Vadai
2016-03-03 14:57 ` Jiri Pirko
2016-03-03 17:45 ` Cong Wang
2016-03-03 19:51 ` Amir Vadai
2016-03-04 18:20 ` Cong Wang
2016-03-06 8:54 ` Amir Vadai
2016-03-04 16:54 ` John Fastabend
2016-03-03 14:55 ` [PATCH net-next V2 04/10] net/act_skbedit: Utility functions for mark action Amir Vadai
2016-03-03 14:57 ` Jiri Pirko
2016-03-03 17:48 ` Cong Wang
2016-03-03 19:58 ` Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 05/10] net/mlx5_core: Set flow steering dest only for forward rules Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 06/10] net/mlx5e: Relax ndo_setup_tc handle restriction Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 07/10] net/mlx5e: Add a new priority for kernel flow tables Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 08/10] net/mlx5e: Introduce tc offload support Amir Vadai
2016-03-03 14:55 ` [PATCH net-next V2 09/10] net/mlx5e: Support offload cls_flower with drop action Amir Vadai
2016-03-03 14:56 ` [PATCH net-next V2 10/10] net/mlx5e: Support offload cls_flower with skbedit mark action Amir Vadai
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=56D9BF73.3050101@gmail.com \
--to=john.fastabend@gmail.com \
--cc=amir@vadai.me \
--cc=davem@davemloft.net \
--cc=hadarh@mellanox.com \
--cc=jiri@mellanox.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=ronye@mellanox.com \
--cc=saeedm@mellanox.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.