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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 30 Jul 2021 14:40:52 +0300 From: Vlad Buslov <vladbu@...dia.com> To: Jamal Hadi Salim <jhs@...atatu.com> CC: Simon Horman <simon.horman@...igine.com>, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Cong Wang <xiyou.wangcong@...il.com>, Jiri Pirko <jiri@...lanox.com>, <netdev@...r.kernel.org>, <oss-drivers@...igine.com>, Baowen Zheng <baowen.zheng@...igine.com>, Louis Peens <louis.peens@...igine.com>, "Ido Schimmel" <idosch@...dia.com>, Jiri Pirko <jiri@...nulli.us>, Roopa Prabhu <roopa@...dia.com> 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 <jhs@...atatu.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@...atatu.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@...igine.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()). [...]
Powered by blists - more mailing lists