netdev - Re: [PATCH net-next 5/9] net: hns3: refactor flow director configuration

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Mar 2021 11:32:15 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Huazhong Tan <tanhuazhong@...wei.com>
Cc:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <salil.mehta@...wei.com>, <yisen.zhuang@...wei.com>,
        <huangdaode@...wei.com>, <linuxarm@...neuler.org>,
        <linuxarm@...wei.com>, Jian Shen <shenjian15@...wei.com>
Subject: Re: [PATCH net-next 5/9] net: hns3: refactor flow director
 configuration

On Wed, 17 Mar 2021 09:47:45 +0800 Huazhong Tan wrote:
> On 2021/3/16 4:00, Jakub Kicinski wrote:
> > On Mon, 15 Mar 2021 20:23:47 +0800 Huazhong Tan wrote:  
> >> From: Jian Shen <shenjian15@...wei.com>
> >>
> >> Currently, there are 3 flow director work modes in HNS3 driver,
> >> include EP(ethtool), tc flower and aRFS. The flow director rules
> >> are configured synchronously and need holding spin lock. With this
> >> limitation, all the commands with firmware are also needed to use
> >> spin lock.
> >>
> >> To eliminate the limitation, configure flow director rules
> >> asynchronously. The rules are still kept in the fd_rule_list
> >> with below states.
> >> TO_ADD: the rule is waiting to add to hardware
> >> TO_DEL: the rule is waiting to remove from hardware
> >> ADDING: the rule is adding to hardware
> >> ACTIVE: the rule is already added in hardware
> >>
> >> When receive a new request to add or delete flow director rule,
> >> check whether the rule location is existent, update the rule
> >> content and state, and request to schedule the service task to
> >> finish the configuration.
> >>
> >> Signed-off-by: Jian Shen <shenjian15@...wei.com>
> >> Signed-off-by: Huazhong Tan <tanhuazhong@...wei.com>  
> > How is the application supposed to know if the ethtool rule was already
> > installed or installation is still pending?  
> 
> 
> Yes, it's unable for the application to know whether pending or installed.
> 
> The primitive motivation is to move out the aRFS rule configuration from
> IO path. To keep consistent, so does the ethtool way. We thought
> of it before, considered that the time window between the two state is
> very small.
> 
> How about keep aRFS asynchronously, and the ethtool synchronously?

That'd be fine by me.