From: Jakub Kicinski <kuba@kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>, Jiri Pirko <jiri@mellanox.com>
Subject: Re: [PATCH net-next 01/11] devlink: add macro for "drv.spec"
Date: Wed, 18 Mar 2020 19:14:27 -0700 [thread overview]
Message-ID: <20200318191427.20b1ec5f@kicinski-fedora-PC1C0HJN> (raw)
In-Reply-To: <CACKFLikpaDrykkzsUNgRdUejQSM4S3M==+TVnRxMCA54DRFFOQ@mail.gmail.com>
On Wed, 18 Mar 2020 17:47:26 -0700 Michael Chan wrote:
> On Wed, Mar 18, 2020 at 5:05 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> > On 3/18/2020 1:04 PM, Jakub Kicinski wrote:
> > > We're just getting rid of driver versions, with significant effort,
> > > so starting to extend devlink info with driver stuff seems risky.
> > > How is driver information part of device info in the first place?
> > >
> > > As you said good driver and firmware will be modular and backward
> > > compatible, so what's the meaning of the API version?
> > >
> > > This field is meaningless.
> >
> > I think I agree with Jakub here. I assume, if it's anything like what
> > the ice driver does, the firmware has an API field used to communicate
> > to the driver what it can support. This can be used by the driver to
> > decide if it can load.
> >
> > For example, if the major API number increases, the ice driver then
> > assumes that it must be a very old driver which will not work at all
> > with that firmware. (This is mostly kept as a safety hatch in case no
> > other alternative can be determined).
> >
> > The driver can then use this API number as a way to decide if certain
> > features can be enabled or not.
> >
> > I suppose printing the driver's "expected" API number makes sense, but I
> > think the stronger approach is to make the driver able to interoperate
> > with any previous API version. Newer minor API numbers only mean that
> > new features exist which the driver might not be aware of. (for example,
> > if you're running an old driver).
>
> Agreed. Our driver is backward and forward compatible with all
> production firmware for the most part. The idea is that the effective
> API version number is the minimum of the driver's API and firmware's
> API. For example, if firmware is at v1.5 and driver is at v1.4, then
> the effective or operating API is v1.4. The new features after v1.4
> are unused because the driver does not understand those new features.
> Similarly, a newer driver running on older firmware will have the
> older firmware's API as the effective API. The driver will not use
> the new features that the firmware doesn't understand.
>
> So if there is only one API version to report, reporting the min.
> makes the most sense to the user in our case. It is similar to a Gen4
> PCIe card currently operating in a Gen3 slot.
Sounds reasonable.
next prev parent reply other threads:[~2020-03-19 2:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 15:14 [PATCH net-next 00/11] bnxt_en updates to devlink cmd Vasundhara Volam
2020-03-17 15:14 ` [PATCH net-next 01/11] devlink: add macro for "drv.spec" Vasundhara Volam
2020-03-17 17:40 ` Jakub Kicinski
2020-03-17 18:33 ` Jacob Keller
2020-03-18 4:21 ` Vasundhara Volam
2020-03-18 20:04 ` Jakub Kicinski
2020-03-19 0:05 ` Jacob Keller
2020-03-19 0:47 ` Michael Chan
2020-03-19 2:14 ` Jakub Kicinski [this message]
2020-03-17 15:14 ` [PATCH net-next 02/11] bnxt_en: Add driver HWRM spec version to devlink info_get cb Vasundhara Volam
2020-03-17 15:14 ` [PATCH net-next 03/11] devlink: add macro for "hw.addr" Vasundhara Volam
2020-03-17 15:14 ` [PATCH net-next 04/11] bnxt_en: Refactor bnxt_hwrm_get_nvm_cfg_ver() Vasundhara Volam
2020-03-17 15:14 ` [PATCH net-next 05/11] bnxt_en: Add hw addr and multihost base hw addr to devlink info_get cb Vasundhara Volam
2020-03-17 17:47 ` Jakub Kicinski
2020-03-18 4:16 ` Vasundhara Volam
2020-03-18 20:10 ` Jakub Kicinski
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=20200318191427.20b1ec5f@kicinski-fedora-PC1C0HJN \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=jiri@mellanox.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=vasundhara-v.volam@broadcom.com \
/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).