RE: [EXT] Re: [PATCH net-next 14/14] qed: bump driver version

From: linux-rdma-owner@vger.kernel.org <linux-rdma-
owner@vger.kernel.org> On Behalf Of Leon Romanovsky
Sent: Wednesday, January 22, 2020 8:21 PM
To: Michal Kalderon <mkalderon@marvell.com>
Cc: Ariel Elior <redacted>; davem@davemloft.net;
netdev@vger.kernel.org; linux-rdma@vger.kernel.org; linux-
scsi@vger.kernel.org
Subject: Re: [EXT] Re: [PATCH net-next 14/14] qed: bump driver version

On Wed, Jan 22, 2020 at 04:39:26PM +0000, Michal Kalderon wrote:

quoted

quoted

From: Leon Romanovsky <leon@kernel.org>
Sent: Wednesday, January 22, 2020 6:14 PM

--------------------------------------------------------------------
-- On Wed, Jan 22, 2020 at 05:26:27PM +0200, Michal Kalderon wrote:

quoted

The FW brings along a large set of fixes and features which will
be added at a later phase. This is an adaquete point to bump the
driver

version.

quoted

Signed-off-by: Ariel Elior <redacted>
Signed-off-by: Michal Kalderon <redacted>
---
 drivers/net/ethernet/qlogic/qed/qed.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

We discussed this a lot, those driver version bumps are stupid and
have nothing close to the reality. Distro kernels are based on some
kernel version with extra patches on top, in RedHat world this "extra"
is a lot. For them your driver version say nothing. For users who
run vanilla kernel, those versions are not relevant too, because
running such kernels requires knowledge and understanding.

You definitely should stop this enterprise cargo cult of "releasing

software"

quoted

quoted

by updating versions in non-controlled by you distribution chain.

Thanks

Due to past discussions on this topic, qedr driver version was not added

and not bumped.

quoted

However, customers are used to seeing a driver version for qed/qede We
only bump major version changes (37 -> 42)  and not the minor versions

anymore.

quoted

This does give a high-level understanding of the driver supports, helps us

and the customers.

It is worth to talk with customers instead of adding useless work for
everyone involved here.

Hi Leon, 

I understand your arguments, and for new drivers I agree it is best to start without a driver version, having said that
Customers are used to what is already out there. 

Ethtool displays a driver version, and  customers go by driver version, not kernel version. 
Mlx drivers haven't bumped the driver version, but it is still displayed when running ethtool. 

Having this version in upstream driver also helps us to understand the level of changes in the inbox driver.
As you mentioned, in some distributions like RHEL, kernel version has no meaning as they backport much newer functionality from upstream.
It is difficult to know based on RedHat kernel/driver, how the driver compares with the upstream driver or what functionality is there.
We have seen that the driver version greatly helps customers here.

Of course if a decision is taken to remove all ethernet driver versions from all vendors and remove the version display from ethtool
We won't object, but since it is still there, and the driver version until now does correlate in the high-level sense to functionality,
I don't see the harm in this single patch.

Dave, what is your take on this ? 
Thanks,
Michal

Thanks

quoted