[net-next,14/14] qed: bump driver version

Commit Message

Michal Kalderon Jan. 22, 2020, 3:26 p.m. UTC

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 <[e-mail]>
Signed-off-by: Michal Kalderon <[e-mail]>
---
 drivers/net/ethernet/qlogic/qed/qed.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Leon Romanovsky Jan. 22, 2020, 4:13 p.m. UTC | #1

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 <[e-mail]>
> Signed-off-by: Michal Kalderon <[e-mail]>
> ---
>  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

Michal Kalderon Jan. 22, 2020, 4:39 p.m. UTC | #2

> From: Leon Romanovsky <[e-mail]>
> 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 <[e-mail]>
> > Signed-off-by: Michal Kalderon <[e-mail]>
> > ---
> >  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.

Leon Romanovsky Jan. 22, 2020, 6:21 p.m. UTC | #3

On Wed, Jan 22, 2020 at 04:39:26PM +0000, Michal Kalderon wrote:
> > From: Leon Romanovsky <[e-mail]>
> > 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 <[e-mail]>
> > > Signed-off-by: Michal Kalderon <[e-mail]>
> > > ---
> > >  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.

Thanks

>

Michal Kalderon Jan. 23, 2020, 8:18 a.m. UTC | #4

> From: [e-mail] <linux-rdma-
> [e-mail]> On Behalf Of Leon Romanovsky
> Sent: Wednesday, January 22, 2020 8:21 PM
> To: Michal Kalderon <[e-mail]>
> Cc: Ariel Elior <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; linux-
> [e-mail]
> 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 <[e-mail]>
> > > 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 <[e-mail]>
> > > > Signed-off-by: Michal Kalderon <[e-mail]>
> > > > ---
> > > >  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
> 
> >

Leon Romanovsky Jan. 23, 2020, 12:12 p.m. UTC | #5

On Thu, Jan 23, 2020 at 08:18:08AM +0000, Michal Kalderon wrote:
> > From: [e-mail] <linux-rdma-
> > [e-mail]> On Behalf Of Leon Romanovsky
> > Sent: Wednesday, January 22, 2020 8:21 PM
> > To: Michal Kalderon <[e-mail]>
> > Cc: Ariel Elior <[e-mail]>; [e-mail];
> > [e-mail]; [e-mail]; linux-
> > [e-mail]
> > 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 <[e-mail]>
> > > > 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 <[e-mail]>
> > > > > Signed-off-by: Michal Kalderon <[e-mail]>
> > > > > ---
> > > > >  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/[e-mail]

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

Leon Romanovsky Jan. 23, 2020, 1:10 p.m. UTC | #6

On Thu, Jan 23, 2020 at 02:12:03PM +0200, Leon Romanovsky wrote:
> On Thu, Jan 23, 2020 at 08:18:08AM +0000, Michal Kalderon wrote:
> > > From: [e-mail] <linux-rdma-
> > > [e-mail]> On Behalf Of Leon Romanovsky
> > > Sent: Wednesday, January 22, 2020 8:21 PM
> > > To: Michal Kalderon <[e-mail]>
> > > Cc: Ariel Elior <[e-mail]>; [e-mail];
> > > [e-mail]; [e-mail]; linux-
> > > [e-mail]
> > > 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 <[e-mail]>
> > > > > 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 <[e-mail]>
> > > > > > Signed-off-by: Michal Kalderon <[e-mail]>
> > > > > > ---
> > > > > >  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.

Done.

https://patchwork.ozlabs.org/patch/1227912/

Thanks

Patch

diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index 8b6d6f884245..c628c4b0b7ba 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -53,7 +53,7 @@ 
 extern const struct qed_common_ops qed_common_ops_pass;
 
 #define QED_MAJOR_VERSION		8
-#define QED_MINOR_VERSION		37
+#define QED_MINOR_VERSION		42
 #define QED_REVISION_VERSION		0
 #define QED_ENGINEERING_VERSION		20