linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Michal Kalderon <mkalderon@marvell.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	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 14:12:03 +0200	[thread overview]
Message-ID: <20200123121203.GL7018@unreal> (raw)
In-Reply-To: <MN2PR18MB31829FA8377460DDB9675596A10F0@MN2PR18MB3182.namprd18.prod.outlook.com>

On Thu, Jan 23, 2020 at 08:18:08AM +0000, Michal Kalderon wrote:
> > 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.

Yes, it is needed to be fixed.

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

Dave was clear about it.
https://lore.kernel.org/linux-rdma/20200122.201241.1054821076123160712.davem@davemloft.net

> Thanks,
> Michal
>
> >
> > Thanks
> >
> > >

  reply	other threads:[~2020-01-23 12:12 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
2020-01-23 12:12           ` Leon Romanovsky [this message]
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=20200123121203.GL7018@unreal \
    --to=leon@kernel.org \
    --cc=aelior@marvell.com \
    --cc=davem@davemloft.net \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkalderon@marvell.com \
    --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).