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

[Ariel Elior]

> -----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.
> 
> Thanks,
> Sudarsana
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.
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.
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.
Thanks,
Ariel