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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 30 Jul 2021 14:40:52 +0300
From:   Vlad Buslov <>
To:     Jamal Hadi Salim <>
CC:     Simon Horman <>,
        David Miller <>,
        Jakub Kicinski <>,
        Cong Wang <>,
        Jiri Pirko <>, <>,
        Baowen Zheng <>,
        Louis Peens <>,
        "Ido Schimmel" <>, Jiri Pirko <>,
        Roopa Prabhu <>
Subject: Re: [PATCH net-next 1/3] flow_offload: allow user to offload tc
 action to net device

On Fri 30 Jul 2021 at 13:17, Jamal Hadi Salim <> 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 <> wrote:
>>>>>> On 2021-07-27 10:38 a.m., Vlad Buslov wrote:
>>>>>>> On Tue 27 Jul 2021 at 16:04, Simon Horman <> 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()).


Powered by blists - more mailing lists