Message-ID: <F07A24C7-930D-4F59-92BD-405B74F01707@amazon.com>
Date:   Thu, 5 Mar 2020 20:37:43 +0000
From:   "Machulsky, Zorik" <zorik@...zon.com>
To:     Leon Romanovsky <leon@...nel.org>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>
CC:     David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Wilson, Matt" <msw@...zon.com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        "Bshara, Nafea" <nafea@...zon.com>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        "Belgazal, Netanel" <netanel@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Herrenschmidt, Benjamin" <benh@...zon.com>,
        "Dagan, Noam" <ndagan@...zon.com>,
        "Agroskin, Shay" <shayagr@...zon.com>,
        "Jubran, Samih" <sameehj@...zon.com>
Subject: Re: [RESEND PATCH V1 net-next] net: ena: fix broken interface between ENA
 driver and FW



On 3/5/20, 11:17 AM, "Leon Romanovsky" <leon@...nel.org> wrote:

    
    On Thu, Mar 05, 2020 at 02:28:33PM +0000, Kiyanovski, Arthur wrote:
    > > -----Original Message-----
    > > From: Leon Romanovsky <leon@...nel.org>
    > > Sent: Sunday, March 1, 2020 3:50 PM
    > > To: David Miller <davem@...emloft.net>
    > > Cc: Kiyanovski, Arthur <akiyano@...zon.com>; netdev@...r.kernel.org;
    > > Woodhouse, David <dwmw@...zon.co.uk>; Machulsky, Zorik
    > > <zorik@...zon.com>; Matushevsky, Alexander <matua@...zon.com>;
    > > Bshara, Saeed <saeedb@...zon.com>; Wilson, Matt <msw@...zon.com>;
    > > Liguori, Anthony <aliguori@...zon.com>; Bshara, Nafea
    > > <nafea@...zon.com>; Tzalik, Guy <gtzalik@...zon.com>; Belgazal, Netanel
    > > <netanel@...zon.com>; Saidi, Ali <alisaidi@...zon.com>; Herrenschmidt,
    > > Benjamin <benh@...zon.com>; Dagan, Noam <ndagan@...zon.com>;
    > > Agroskin, Shay <shayagr@...zon.com>; Jubran, Samih
    > > <sameehj@...zon.com>
    > > Subject: Re: [RESEND PATCH V1 net-next] net: ena: fix broken interface between
    > > ENA driver and FW
    > >
    > > On Wed, Feb 26, 2020 at 08:48:09PM -0800, David Miller wrote:
    > > > From: <akiyano@...zon.com>
    > > > Date: Wed, 26 Feb 2020 12:03:35 +0200
    > > >
    > > > > From: Arthur Kiyanovski <akiyano@...zon.com>
    > > > >
    > > > > In this commit we revert the part of commit 1a63443afd70
    > > > > ("net/amazon: Ensure that driver version is aligned to the linux
    > > > > kernel"), which breaks the interface between the ENA driver and FW.
    > > > >
    > > > > We also replace the use of DRIVER_VERSION with DRIVER_GENERATION
    > > > > when we bring back the deleted constants that are used in interface
    > > > > with ENA device FW.
    > > > >
    > > > > This commit does not change the driver version reported to the user
    > > > > via ethtool, which remains the kernel version.
    > > > >
    > > > > Fixes: 1a63443afd70 ("net/amazon: Ensure that driver version is
    > > > > aligned to the linux kernel")
    > > > > Signed-off-by: Arthur Kiyanovski <akiyano@...zon.com>
    > > >
    > > > Applied.
    > >
    > > Dave,
    > >
    > > I see that I'm late here and my email sounds like old man grumbling, but I asked
    > > from those guys to update their commit with request to put the following line:
    > > "/* DO NOT CHANGE DRV_MODULE_GEN_* values in in-tree code */"
    > > https://lore.kernel.org/netdev/20200224162649.GA4526@unreal/
    > >
    > > I also asked how those versions are transferred to FW and used there, but was
    > > ignored.
    > > https://lore.kernel.org/netdev/20200224094116.GD422704@unreal/
    > >
    > > BTW, It is also unclear why I wasn't CCed in this patch.
    > >
    > > Thanks
    >
    > Leon,
    >  Sorry for not responding earlier to your inquiries, they are exactly touching the
    >  points that we would like to discuss.
    >  Up until now, we in AWS, have been monitoring the drivers in the datacenter using the
    >  driver version, and actively suggesting driver updates to our customers
    >  whenever a critical bug was fixed, or a new important feature was added.
    >  Removing the driver version and not allowing to maintain our own internal
    >  version negatively impacts our effort to give our customers the best possible cloud
    >  experience. We therefore prefer to maintain using our internal driver version.
    >
    >  Are there any other recommended ways to achieve our goal without a driver
    >  version?
    
    Of course, drivers are supposed to behave like any other user visible API.
    They need to ensure backward compatibility, so new code will work with
    old HW/FW. This is normally done by capability masks, see how it is done
    in Mellanox drivers and I think in Intel too.
    
    So your update policy based on driver version string is nonsense and
    broken by design.
    
    Original thread with Linus is here [1].
    
    [1] https://lore.kernel.org/ksummit-discuss/CA+55aFx9A=5cc0QZ7CySC4F2K7eYaEfzkdYEc9JaNgCcV25=rg@mail.gmail.com/
    
    Thanks 

We do support features capability mask as well as versioning per feature. 
However, whenever there are known issues in a certain version of the  driver
that can be worked around by the device, we need the device to be aware of the 
driver version. Another purpose is operational - knowing driver version helps us 
reproduce customer issues and debug them, as well as suggest our customers
to upgrade their drivers, as Arthur mentioned above.
Thanks

    
    >
    >  Thanks!
    >
    

Powered by blists - more mailing lists