From: Ido Schimmel <idosch@idosch.org>
To: dsatish <satish.d@oneconvergence.com>
Cc: davem@davemloft.net, jhs@mojatatu.com, xiyou.wangcong@gmail.com,
jiri@resnulli.us, kuba@kernel.org, netdev@vger.kernel.org,
simon.horman@netronome.com, kesavac@gmail.com,
prathibha.nagooru@oneconvergence.com,
intiyaz.basha@oneconvergence.com, jai.rana@oneconvergence.com
Subject: Re: [PATCH net-next 3/3] cls_flower: Allow flow offloading though masked key exist.
Date: Fri, 19 Jun 2020 16:35:48 +0300 [thread overview]
Message-ID: <20200619133548.GB400561@splinter> (raw)
In-Reply-To: <20200619094156.31184-4-satish.d@oneconvergence.com>
On Fri, Jun 19, 2020 at 03:11:56PM +0530, dsatish wrote:
> A packet reaches OVS user space, only if, either there is no rule in
> datapath/hardware or there is race condition that the flow is added
> to hardware but before it is processed another packet arrives.
>
> It is possible hardware as part of its limitations/optimizations
> remove certain flows.
Which driver is doing this? I don't believe it's valid to remove filters
from hardware and not tell anyone about it.
> To handle such cases where the hardware lost
> the flows, tc can offload to hardware if it receives a flow for which
> there exists an entry in its flow table. To handle such cases TC when
> it returns EEXIST error, also programs the flow in hardware, if
> hardware offload is enabled.
>
> Signed-off-by: Chandra Kesava <kesavac@gmail.com>
> Signed-off-by: Prathibha Nagooru <prathibha.nagooru@oneconvergence.com>
> Signed-off-by: Satish Dhote <satish.d@oneconvergence.com>
> ---
> net/sched/cls_flower.c | 23 +++++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index f1a5352cbb04..d718233cd5b9 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -431,7 +431,8 @@ static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f,
>
> static int fl_hw_replace_filter(struct tcf_proto *tp,
> struct cls_fl_filter *f, bool rtnl_held,
> - struct netlink_ext_ack *extack)
> + struct netlink_ext_ack *extack,
> + unsigned long cookie)
> {
> struct tcf_block *block = tp->chain->block;
> struct flow_cls_offload cls_flower = {};
> @@ -444,7 +445,7 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
>
> tc_cls_common_offload_init(&cls_flower.common, tp, f->flags, extack);
> cls_flower.command = FLOW_CLS_REPLACE;
> - cls_flower.cookie = (unsigned long) f;
> + cls_flower.cookie = cookie;
> cls_flower.rule->match.dissector = &f->mask->dissector;
> cls_flower.rule->match.mask = &f->mask->key;
> cls_flower.rule->match.key = &f->mkey;
> @@ -2024,11 +2025,25 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> fl_init_unmasked_key_dissector(&fnew->unmasked_key_dissector);
>
> err = fl_ht_insert_unique(fnew, fold, &in_ht);
> - if (err)
> + if (err) {
> + /* It is possible Hardware lost the flow even though TC has it,
> + * and flow miss in hardware causes controller to offload flow again.
> + */
> + if (err == -EEXIST && !tc_skip_hw(fnew->flags)) {
> + struct cls_fl_filter *f =
> + __fl_lookup(fnew->mask, &fnew->mkey);
> +
> + if (f)
> + fl_hw_replace_filter(tp, fnew, rtnl_held,
> + extack,
> + (unsigned long)(f));
> + }
> goto errout_mask;
> + }
>
> if (!tc_skip_hw(fnew->flags)) {
> - err = fl_hw_replace_filter(tp, fnew, rtnl_held, extack);
> + err = fl_hw_replace_filter(tp, fnew, rtnl_held, extack,
> + (unsigned long)fnew);
> if (err)
> goto errout_ht;
> }
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-06-19 13:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 9:41 [PATCH net-next 0/3] cls_flower: Offload unmasked key dsatish
2020-06-19 9:41 ` [PATCH net-next 1/3] cls_flower: Set addr_type when ip mask is non-zero dsatish
2020-06-19 9:41 ` [PATCH net-next 2/3] cls_flower: Pass the unmasked key to hw dsatish
2020-06-19 13:14 ` Ido Schimmel
2020-06-19 14:00 ` Jiri Pirko
2020-06-19 9:41 ` [PATCH net-next 3/3] cls_flower: Allow flow offloading though masked key exist dsatish
2020-06-19 13:35 ` Ido Schimmel [this message]
2020-06-19 14:01 ` Jiri Pirko
2020-06-19 16:15 ` Vlad Buslov
2020-06-19 20:12 ` [PATCH net-next 0/3] cls_flower: Offload unmasked key David Miller
2020-06-30 3:09 ` Satish
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=20200619133548.GB400561@splinter \
--to=idosch@idosch.org \
--cc=davem@davemloft.net \
--cc=intiyaz.basha@oneconvergence.com \
--cc=jai.rana@oneconvergence.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kesavac@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=prathibha.nagooru@oneconvergence.com \
--cc=satish.d@oneconvergence.com \
--cc=simon.horman@netronome.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).