| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 23 Sep 2019 22:18:44 +0800
From: wenxu <wenxu@...oud.cn>
To: John Hurley <john.hurley@...ronome.com>
Cc: Or Gerlitz <gerlitz.or@...il.com>,
Pieter Jansen van Vuuren
<pieter.jansenvanvuuren@...ronome.com>,
Oz Shlomo <ozsh@...lanox.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
David Miller <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
Roi Dayan <roid@...lanox.com>,
Paul Blakey <paulb@...lanox.com>,
Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net v3] net/sched: cls_api: Fix nooffloaddevcnt counter
when indr block call success
在 2019/9/23 17:42, John Hurley 写道:
> On Mon, Sep 23, 2019 at 5:20 AM wenxu <wenxu@...oud.cn> wrote:
>> Hi John & Jakub
>>
>> There are some limitations for indirect tc callback work with skip_sw ?
>>
> Hi Wenxu,
> This is not really a limitation.
> As Or points out, indirect block offload is not supposed to work with skip_sw.
> Indirect offload allows us to hook onto existing kernel devices (for
> TC events we may which to offload) that are out of the control of the
> offload driver and, therefore, should always accept software path
> rules.
> For example, the vxlan driver does not implement a setup_tc ndo so it
> does not expect to run rules in hw - it should always handle
> associated rules in the software datapath as a minimum.
> I think accepting skip_sw rules for devices with no in-built concept
> of hardware offload would be wrong.
> Do you have a use case that requires skip_sw rules for such devices?
>
> John
When we use ovs to control the tc offload. The ovs kernel already provide the software
path rules so maybe user don't want other soft path. And with skip_sw it can be easily
distinguish offloaded and non-offloaded rules.
>
>
>> BR
>>
>> wenxu
>>
>> On 9/19/2019 8:50 PM, Or Gerlitz wrote:
>>>> successfully bind with a real hw through indr block call, It also add
>>>> nooffloadcnt counter. This counter will lead the rule add failed in
>>>> fl_hw_replace_filter-->tc_setup_cb_call with skip_sw flags.
>>> wait.. indirect tc callbacks are typically used to do hw offloading
>>> for decap rules (tunnel key unset action) set on SW devices (gretap, vxlan).
>>>
>>> However, AFAIK, it's been couple of years since the kernel doesn't support
>>> skip_sw for such rules. Did we enable it again? when? I am somehow
>>> far from the details, so copied some folks..
>>>
>>> Or.
>>>
>>>
>>>> In the tc_setup_cb_call will check the nooffloaddevcnt and skip_sw flags
>>>> as following:
>>>> if (block->nooffloaddevcnt && err_stop)
>>>> return -EOPNOTSUPP;
>>>>
>>>> So with this patch, if the indr block call success, it will not modify
>>>> the nooffloaddevcnt counter.
>>>>
>>>> Fixes: 7f76fa36754b ("net: sched: register callbacks for indirect tc block binds")
>>>> Signed-off-by: wenxu <wenxu@...oud.cn>
>>>> ---
>>>> v3: rebase to the net
>>>>
>>>> net/sched/cls_api.c | 30 +++++++++++++++++-------------
>>>> 1 file changed, 17 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>>> index 32577c2..c980127 100644
>>>> --- a/net/sched/cls_api.c
>>>> +++ b/net/sched/cls_api.c
>>>> @@ -607,11 +607,11 @@ static void tc_indr_block_get_and_ing_cmd(struct net_device *dev,
>>>> tc_indr_block_ing_cmd(dev, block, cb, cb_priv, command);
>>>> }
>>>>
>>>> -static void tc_indr_block_call(struct tcf_block *block,
>>>> - struct net_device *dev,
>>>> - struct tcf_block_ext_info *ei,
>>>> - enum flow_block_command command,
>>>> - struct netlink_ext_ack *extack)
>>>> +static int tc_indr_block_call(struct tcf_block *block,
>>>> + struct net_device *dev,
>>>> + struct tcf_block_ext_info *ei,
>>>> + enum flow_block_command command,
>>>> + struct netlink_ext_ack *extack)
>>>> {
>>>> struct flow_block_offload bo = {
>>>> .command = command,
>>>> @@ -621,10 +621,15 @@ static void tc_indr_block_call(struct tcf_block *block,
>>>> .block_shared = tcf_block_shared(block),
>>>> .extack = extack,
>>>> };
>>>> +
>>>> INIT_LIST_HEAD(&bo.cb_list);
>>>>
>>>> flow_indr_block_call(dev, &bo, command);
>>>> - tcf_block_setup(block, &bo);
>>>> +
>>>> + if (list_empty(&bo.cb_list))
>>>> + return -EOPNOTSUPP;
>>>> +
>>>> + return tcf_block_setup(block, &bo);
>>>> }
>>>>
>>>> static bool tcf_block_offload_in_use(struct tcf_block *block)
>>>> @@ -681,8 +686,6 @@ static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
>>>> goto no_offload_dev_inc;
>>>> if (err)
>>>> goto err_unlock;
>>>> -
>>>> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
>>>> up_write(&block->cb_lock);
>>>> return 0;
>>>>
>>>> @@ -691,9 +694,10 @@ static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
>>>> err = -EOPNOTSUPP;
>>>> goto err_unlock;
>>>> }
>>>> + err = tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
>>>> + if (err)
>>>> + block->nooffloaddevcnt++;
>>>> err = 0;
>>>> - block->nooffloaddevcnt++;
>>>> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_BIND, extack);
>>>> err_unlock:
>>>> up_write(&block->cb_lock);
>>>> return err;
>>>> @@ -706,8 +710,6 @@ static void tcf_block_offload_unbind(struct tcf_block *block, struct Qdisc *q,
>>>> int err;
>>>>
>>>> down_write(&block->cb_lock);
>>>> - tc_indr_block_call(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
>>>> -
>>>> if (!dev->netdev_ops->ndo_setup_tc)
>>>> goto no_offload_dev_dec;
>>>> err = tcf_block_offload_cmd(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
>>>> @@ -717,7 +719,9 @@ static void tcf_block_offload_unbind(struct tcf_block *block, struct Qdisc *q,
>>>> return;
>>>>
>>>> no_offload_dev_dec:
>>>> - WARN_ON(block->nooffloaddevcnt-- == 0);
>>>> + err = tc_indr_block_call(block, dev, ei, FLOW_BLOCK_UNBIND, NULL);
>>>> + if (err)
>>>> + WARN_ON(block->nooffloaddevcnt-- == 0);
>>>> up_write(&block->cb_lock);
>>>> }
>>>>
>>>> --
>>>> 1.8.3.1
>>>>
Powered by blists - more mailing lists