netdev - Re: [PATCH] ena: Speed up initialization 90x by reducing poll delays

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:   Mon, 2 Mar 2020 15:53:19 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Machulsky, Zorik" <zorik@...zon.com>
Cc:     Josh Triplett <josh@...htriplett.org>,
        "Belgazal, Netanel" <netanel@...zon.com>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ena: Speed up initialization 90x by reducing poll
 delays

On Mon, 2 Mar 2020 23:16:32 +0000 Machulsky, Zorik wrote:
> On 2/28/20, 4:29 PM, "Josh Triplett" <josh@...htriplett.org> wrote:
> 
>     Before initializing completion queue interrupts, the ena driver uses
>     polling to wait for responses on the admin command queue. The ena driver
>     waits 5ms between polls, but the hardware has generally finished long
>     before that. Reduce the poll time to 10us.
>     
>     On a c5.12xlarge, this improves ena initialization time from 173.6ms to
>     1.920ms, an improvement of more than 90x. This improves server boot time
>     and time to network bringup.
>  
> Thanks Josh,
> We agree that polling rate should be increased, but prefer not to do
> it aggressively and blindly. For example linear backoff approach
> might be a better choice. Please let us re-work a little this patch
> and bring it to review. Thanks!  

Up to Josh if this is fine with him, but in my experience "let us rework
your patch behind the close doors" is not the response open source
contributors are expecting.