Messages in this thread | | | Date | Thu, 20 Feb 2020 16:37:45 -0800 | From | Jakub Kicinski <> | 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@marvell.com> > > Sent: Thursday, February 20, 2020 11:17 AM > > To: Paul Menzel <pmenzel@molgen.mpg.de>; Ariel Elior > > <aelior@marvell.com>; GR-everest-linux-l2 <GR-everest-linux- > > l2@marvell.com> > > Cc: netdev@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; it+linux- > > netdev@molgen.mpg.de; David S. Miller <davem@davemloft.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://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.
| |