Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 2 Mar 2020 15:53:19 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     "Machulsky, Zorik" <zorik@amazon.com>
Cc:     Josh Triplett <josh@joshtriplett.org>,
        "Belgazal, Netanel" <netanel@amazon.com>,
        "Kiyanovski, Arthur" <akiyano@amazon.com>,
        "Tzalik, Guy" <gtzalik@amazon.com>,
        "Bshara, Saeed" <saeedb@amazon.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ena: Speed up initialization 90x by reducing poll
 delays
Message-ID: <20200302155319.273ee513@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <8B4A52CD-FC5A-4256-B7DE-A659B50654CE@amazon.com>
References: <20200229002813.GA177044@localhost>
        <8B4A52CD-FC5A-4256-B7DE-A659B50654CE@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 2 Mar 2020 23:16:32 +0000 Machulsky, Zorik wrote:
> =EF=BB=BFOn 2/28/20, 4:29 PM, "Josh Triplett" <josh@joshtriplett.org> wro=
te:
>=20
>     Before initializing completion queue interrupts, the ena driver uses
>     polling to wait for responses on the admin command queue. The ena dri=
ver
>     waits 5ms between polls, but the hardware has generally finished long
>     before that. Reduce the poll time to 10us.
>    =20
>     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 t=
ime
>     and time to network bringup.
> =20
> 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! =20

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.