netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Kalderon <mkalderon@marvell.com>
To: Leon Romanovsky <leon@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Cc: Ariel Elior <aelior@marvell.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: RE: [EXT] Re: [PATCH net-next 14/14] qed: bump driver version
Date: Thu, 23 Jan 2020 08:18:08 +0000	[thread overview]
Message-ID: <MN2PR18MB31829FA8377460DDB9675596A10F0@MN2PR18MB3182.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20200122182107.GI7018@unreal>

> 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 <aelior@marvell.com>; 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:
> > > 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:
> > > > 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.
> > > >
> > > > Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
> > > > Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
> > > > ---
> > > >  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"
> > > 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.
> > 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.
> > 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
> 
> >

  reply	other threads:[~2020-01-23  8:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22 15:26 [PATCH net-next 00/14] qed*: Utilize FW 8.42.2.0 Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 01/14] qed: FW 8.42.2.0 Internal ram offsets modifications Michal Kalderon
2020-01-22 15:45   ` Jakub Kicinski
2020-01-22 16:02     ` Michal Kalderon
2020-01-23 14:26       ` Jakub Kicinski
2020-01-22 15:26 ` [PATCH net-next 02/14] qed: FW 8.42.2.0 Expose new registers and change windows Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 03/14] qed: FW 8.42.2.0 Queue Manager changes Michal Kalderon
2020-01-24 19:09   ` kbuild test robot
2020-01-22 15:26 ` [PATCH net-next 04/14] qed: FW 8.42.2.0 Parser offsets modified Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 05/14] qed: Use dmae to write to widebus registers in fw_funcs Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 06/14] qed: FW 8.42.2.0 Additional ll2 type Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 07/14] qed: Add abstraction for different hsi values per chip Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 08/14] qed: FW 8.42.2.0 iscsi/fcoe changes Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 09/14] qed: FW 8.42.2.0 HSI changes Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 10/14] qed: FW 8.42.2.0 Add fw overlay feature Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 11/14] qed: Debug feature: ilt and mdump Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 12/14] qed: rt init valid initialization changed Michal Kalderon
2020-01-22 15:26 ` [PATCH net-next 13/14] qed: FW 8.42.2.0 debug features Michal Kalderon
2020-01-22 15:54   ` Jakub Kicinski
2020-01-22 16:03     ` Michal Kalderon
2020-01-22 16:14       ` Leon Romanovsky
2020-01-22 16:41         ` [EXT] " Michal Kalderon
2020-01-22 18:22           ` Leon Romanovsky
2020-01-22 19:12     ` David Miller
2020-01-22 15:26 ` [PATCH net-next 14/14] qed: bump driver version Michal Kalderon
2020-01-22 16:13   ` Leon Romanovsky
2020-01-22 16:39     ` [EXT] " Michal Kalderon
2020-01-22 18:21       ` Leon Romanovsky
2020-01-23  8:18         ` Michal Kalderon [this message]
2020-01-23 12:12           ` Leon Romanovsky
2020-01-23 13:10             ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR18MB31829FA8377460DDB9675596A10F0@MN2PR18MB3182.namprd18.prod.outlook.com \
    --to=mkalderon@marvell.com \
    --cc=aelior@marvell.com \
    --cc=davem@davemloft.net \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).