From: Vlad Buslov <vladbu@nvidia•com>
To: Jamal Hadi Salim <jhs@mojatatu•com>
Cc: Simon Horman <simon.horman@corigine•com>,
David Miller <davem@davemloft•net>,
Jakub Kicinski <kuba@kernel•org>,
Cong Wang <xiyou.wangcong@gmail•com>,
Jiri Pirko <jiri@mellanox•com>, <netdev@vger•kernel.org>,
<oss-drivers@corigine•com>,
Baowen Zheng <baowen.zheng@corigine•com>,
Louis Peens <louis.peens@corigine•com>,
"Ido Schimmel" <idosch@nvidia•com>, Jiri Pirko <jiri@resnulli•us>,
Roopa Prabhu <roopa@nvidia•com>
Subject: Re: [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device
Date: Fri, 30 Jul 2021 14:40:52 +0300 [thread overview]
Message-ID: <ygnhv94sowqj.fsf@nvidia.com> (raw)
In-Reply-To: <2ba4e24f-e34e-f893-d42b-d0fd40794da5@mojatatu.com>
On Fri 30 Jul 2021 at 13:17, Jamal Hadi Salim <jhs@mojatatu•com> wrote:
> On 2021-07-28 10:46 a.m., Simon Horman wrote:
>> On Wed, Jul 28, 2021 at 09:51:00AM -0400, Jamal Hadi Salim wrote:
>>> On 2021-07-28 3:46 a.m., Simon Horman wrote:
>>>> On Tue, Jul 27, 2021 at 07:47:43PM +0300, Vlad Buslov wrote:
>>>>> On Tue 27 Jul 2021 at 19:13, Jamal Hadi Salim <jhs@mojatatu•com> wrote:
>>>>>> On 2021-07-27 10:38 a.m., Vlad Buslov wrote:
>>>>>>> On Tue 27 Jul 2021 at 16:04, Simon Horman <simon.horman@corigine•com> wrote:
>>>
>>> [..]
>>>
>>>>>>> I think we have the same issue with filters - they might not be in
>>>>>>> hardware after driver callback returned "success" (due to neigh state
>>>>>>> being invalid for tunnel_key encap, for example).
>>>>>>
>>>>>> Sounds like we need another state for this. Otherwise, how do you debug
>>>>>> that something is sitting in the driver and not in hardware after you
>>>>>> issued a command to offload it? How do i tell today?
>>>>>> Also knowing reason why something is sitting in the driver would be
>>>>>> helpful.
>>>>>
>>>>> It is not about just adding another state. The issue is that there is no
>>>>> way for drivers to change the state of software filter dynamically.
>>>>
>>>> I think it might be worth considering enhancing things at some point.
>>>> But I agree that its more than a matter of adding an extra flag. And
>>>> I think it's reasonable to implement something similar to the classifier
>>>> current offload handling of IN_HW now and consider enhancements separately.
>>>
>>> Debugability is very important. If we have such gotchas we need to have
>>> the admin at least be able to tell if the driver returns "success"
>>> and the request is still sitting in the driver for whatever reason
>>> At minimal there needs to be some indicator somewhere which say
>>> "inprogress" or "waiting for resolution" etc.
>>> If the control plane(user space app) starts making other decisions
>>> based on assumptions that filter was successfully installed i.e
>>> packets are being treated in the hardware then there could be
>>> consequences when this assumption is wrong.
>>>
>>> So if i undestood the challenge correctly it is: how do you relay
>>> this info back so it is reflected in the filter details. Yes that
>>> would require some mechanism to exist and possibly mapping state
>>> between whats in the driver and in the cls layer.
>>> If i am not mistaken, the switchdev folks handle this asynchronicty?
>>> +Cc Ido, Jiri, Roopa
>>>
>>> And it should be noted that: Yes, the filters have this
>>> pre-existing condition but doesnt mean given the opportunity
>>> to do actions we should replicate what they do.
>> I'd prefer symmetry between the use of IN_HW for filters and actions,
>> which I believe is what Vlad has suggested.
>>
>
> It still not clear to me what it means from a command line pov.
> How do i add a rule and when i dump it what does it show?
>
>> If we wish to enhance things - f.e. for debugging, which I
>> agree is important - then I think that is a separate topic.
>>
>
> My only concern is not to repeat mistakes that are in filters
> just for the sake of symmetry. Example the fact that something
> went wrong with insertion or insertion is still in progress
> and you get an indication that all went well.
> Looking at mlnx (NIC) ndrivers it does seem that in the normal case
> the insertion into hw is synchronous (for anything that is not sw
> only). I didnt quiet see what Vlad was referring to.
Filters with tunnel_key encap actions can be offloaded/unoffloaded
dynamically based on neigh state (see mlx5e_rep_neigh_update()) and fib
events (see mlx5e_tc_fib_event_work()).
[...]
next prev parent reply other threads:[~2021-07-30 11:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 9:19 [PATCH net-next 0/3] flow_offload: hardware offload of TC actions Simon Horman
2021-07-22 9:19 ` [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device Simon Horman
2021-07-22 12:24 ` Roi Dayan
2021-07-22 13:19 ` Simon Horman
2021-07-22 13:29 ` Vlad Buslov
2021-07-22 13:33 ` Jamal Hadi Salim
2021-07-27 13:04 ` Simon Horman
2021-07-27 14:38 ` Vlad Buslov
2021-07-27 16:13 ` Jamal Hadi Salim
2021-07-27 16:47 ` Vlad Buslov
2021-07-28 7:46 ` Simon Horman
2021-07-28 8:05 ` Vlad Buslov
2021-07-28 13:51 ` Jamal Hadi Salim
2021-07-28 14:46 ` Simon Horman
2021-07-30 10:17 ` Jamal Hadi Salim
2021-07-30 11:40 ` Vlad Buslov [this message]
2021-08-03 9:57 ` Jamal Hadi Salim
2021-08-03 12:02 ` tc offload debug-ability Jamal Hadi Salim
2021-08-03 12:14 ` Vlad Buslov
2021-08-03 12:50 ` Jamal Hadi Salim
2021-08-03 13:34 ` Ido Schimmel
2021-07-30 13:20 ` [PATCH net-next 1/3] flow_offload: allow user to offload tc action to net device Simon Horman
2021-08-03 10:14 ` Jamal Hadi Salim
2021-08-03 11:36 ` Simon Horman
2021-08-03 11:45 ` Jamal Hadi Salim
2021-08-03 12:31 ` Simon Horman
2021-08-03 13:01 ` Jamal Hadi Salim
2021-08-03 14:46 ` Simon Horman
2021-07-22 13:57 ` kernel test robot
2021-07-22 15:31 ` kernel test robot
2021-08-03 10:50 ` Jamal Hadi Salim
2021-08-03 11:05 ` Jamal Hadi Salim
2021-08-03 11:31 ` Simon Horman
2021-07-22 9:19 ` [PATCH net-next 2/3] flow_offload: add process to delete offloaded actions from " Simon Horman
2021-07-22 14:25 ` Vlad Buslov
2021-07-22 14:50 ` kernel test robot
2021-07-22 17:07 ` kernel test robot
2021-08-03 10:59 ` Jamal Hadi Salim
2021-07-22 9:19 ` [PATCH net-next 3/3] flow_offload: add process to update action stats from hardware Simon Horman
2021-07-22 14:55 ` Vlad Buslov
2021-08-03 11:24 ` Jamal Hadi Salim
2021-08-03 11:35 ` Simon Horman
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=ygnhv94sowqj.fsf@nvidia.com \
--to=vladbu@nvidia$(echo .)com \
--cc=baowen.zheng@corigine$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=idosch@nvidia$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=kuba@kernel$(echo .)org \
--cc=louis.peens@corigine$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=oss-drivers@corigine$(echo .)com \
--cc=roopa@nvidia$(echo .)com \
--cc=simon.horman@corigine$(echo .)com \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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