Re: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression policy

[Jakub Kicinski]

On Thu, 20 Feb 2020 15:40:37 +0000 Ariel Elior wrote:
> > -----Original Message-----
> > From: Sudarsana Reddy Kalluru <skalluru@xxxxxxxxxxx>
> > Sent: Thursday, February 20, 2020 11:17 AM
> > To: Paul Menzel <pmenzel@xxxxxxxxxxxxx>; Ariel Elior
> > <aelior@xxxxxxxxxxx>; GR-everest-linux-l2 <GR-everest-linux-  
> > l2@xxxxxxxxxxx>  
> > Cc: netdev@xxxxxxxxxxxxxxx; LKML <linux-kernel@xxxxxxxxxxxxxxx>; it+linux-
> > netdev@xxxxxxxxxxxxx; David S. Miller <davem@xxxxxxxxxxxxx>
> > 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://www.spinics.net/lists/netdev/msg609889.html
> > 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.

> 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.