Date:   Mon, 24 Feb 2020 17:34:09 +0000
From:   Ariel Elior <aelior@...vell.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Sudarsana Reddy Kalluru <skalluru@...vell.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "it+linux-netdev@...gen.mpg.de" <it+linux-netdev@...gen.mpg.de>,
        "David S. Miller" <davem@...emloft.net>
Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression
 policy



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, February 21, 2020 2:38 AM
> To: Ariel Elior <aelior@...vell.com>
> Cc: Sudarsana Reddy Kalluru <skalluru@...vell.com>; Paul Menzel
> <pmenzel@...gen.mpg.de>; GR-everest-linux-l2 <GR-everest-linux-
> l2@...vell.com>; netdev@...r.kernel.org; LKML <linux-
> kernel@...r.kernel.org>; it+linux-netdev@...gen.mpg.de; David S. Miller
> <davem@...emloft.net>
> Subject: Re: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression
> policy
> 
> On Thu, 20 Feb 2020 15:40:37 +0000 Ariel Elior wrote:
> > > -----Original Message-----
> > > From: Sudarsana Reddy Kalluru <skalluru@...vell.com>
> > > Sent: Thursday, February 20, 2020 11:17 AM
> > > To: Paul Menzel <pmenzel@...gen.mpg.de>; Ariel Elior
> > > <aelior@...vell.com>; GR-everest-linux-l2 <GR-everest-linux-
> > > l2@...vell.com>
> > > Cc: netdev@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>;
> > > it+linux- netdev@...gen.mpg.de; David S. Miller
> > > <davem@...emloft.net>
> > > Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no
> > > regression policy
> > >
> > > Hi Paul,
> > >     Bnx2x driver and the storm FW are tightly coupled, and the info
> > > is exchanged between them via shmem (i.e., common structures which
> > > might change between the releases). Also, FW provides some offset
> > > addresses to the driver which could change between the FW releases,
> following is one such commit,
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net
> > >
> _lists_netdev_msg609889.html&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=c
> WB
> > >
> gNIFUifZRx2xhypdcaYrfIsMGt93NxP1r8GQtC0s&m=W4pEZSYmEGyvbakqtsYcE7
> OaK
> > >
> vjaEvlWjSFfUUOc65A&s=A7UihKukjHlFL16Z1MFf9zY0BItRgbDSAzwq48PkmvY&e
> =
> > > Hence it's not very straight forward to provide the backward
> > > compatibility i.e., newer (updated) kernel driver with the older FW.
> > > Currently we don’t have plans to implement the new model mentioned
> below.
> > >
> > Hi,
> > There are additional reasons why backwards/forwards compatibility
> > considerations are not applicable here. This Fw is not nvram based,
> > and does not reside in the device. It is programed to the device on
> > every driver load. The driver will never face a device "already
> > initialized" with a version of FW it is not familiar with.
> 
> How do you deal with VFs?
> 
> > The device also has traditional management FW in nvram in the device
> > with which we have a backwards and forwards compatibility mechanism,
> > which works just fine.
> > But the FW under discussion is fastpath Fw, used to craft every packet
> > going out of the device and analyze and place every packet coming into the
> device.
> > Supporting multiple versions of FW would be tantamount to implementing
> > dozens of versions of start_xmit and napi_poll in the driver (not to
> > mention multiple fastpath handles of all the offloads the device
> > supports, roce, iscsi, fcoe and iwarp, as all of these are offloaded by the FW).
> > The entire device initialization sequence also changes significantly
> > from one FW version to the Next. All of these differences are
> > abstracted away in the FW file, which includes the init sequence and
> > the compiled FW. The amount of changes required in driver are very
> > significant when moving from one version to the next. Trying to keep
> > all those versions alive concurrently would cause this already very large
> driver to be 20x larger.
> 
> All your points are disproved by all the devices which have drivers upstream
> and don't break backward compatibility on every release.
Note that we are talking about compatibility with a file on the disk, not with
the FW in the device. I don't think any of the other drivers have fastpath
FW which needs to be programmed to the device on every driver load. As
noted, this is not FW that resides in flash. It has to be reprogrammed on
driver load. Note that we do always make sure to have the new FW file
accepted in the Linux FW tree before we send to Dave the series for making
use of it. And the driver does detect that the FW file is not available and
fails the load flow gracefully.

I think this boils down to a simple question: Is the use case of upgrading
the kernel without pulling the FW tree a legitimate one? If so, I think the
solution we can offer is to create an .h file with the required init sequence
(FW an all) and have the driver compile with it, so it can always initialize
the device. This is how this device is initialized in OSes which don't support
dynamic FW load. This is not difficult to do and would solve the problem
you are facing (FW file not available on disk) but would also mean that the
compiled driver size would be much larger. Is that desirable?

As an aside, please note that this model is implemented qede for a few
years and in bnx2x for many years, and I did not get this complaint yet.

> 
> > We don't have a method of keeping the device operational if the kernel
> > was upgraded but firmware tree was not updated. The best that can be
> > done is report the problem, which is what we do.

Powered by blists - more mailing lists