From: Leon Romanovsky <leon@kernel.org>
To: Shinas Rasheed <srasheed@marvell.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Haseeb Gani <hgani@marvell.com>,
Vimlesh Kumar <vimleshk@marvell.com>,
"egallen@redhat.com" <egallen@redhat.com>,
"mschmidt@redhat.com" <mschmidt@redhat.com>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"horms@kernel.org" <horms@kernel.org>,
"kuba@kernel.org" <kuba@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"wizhao@redhat.com" <wizhao@redhat.com>,
"kheib@redhat.com" <kheib@redhat.com>,
"konguyen@redhat.com" <konguyen@redhat.com>,
Veerasenareddy Burru <vburru@marvell.com>,
Sathesh B Edara <sedara@marvell.com>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [EXT] Re: [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox version support
Date: Mon, 11 Dec 2023 13:23:05 +0200 [thread overview]
Message-ID: <20231211112305.GD4870@unreal> (raw)
In-Reply-To: <PH0PR18MB4734652F50856F52507577ADC78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
On Mon, Dec 11, 2023 at 10:31:32AM +0000, Shinas Rasheed wrote:
> Hi Leon,
>
> > > @@ -28,10 +28,18 @@ static void octep_pfvf_validate_version(struct
> > octep_device *oct, u32 vf_id,
> > > {
> > > u32 vf_version = (u32)cmd.s_version.version;
> > >
> > > - if (vf_version <= OCTEP_PFVF_MBOX_VERSION_V1)
> > > - rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> > > + dev_dbg(&oct->pdev->dev, "VF id:%d VF version:%d PF
> > version:%d\n",
> > > + vf_id, vf_version, OCTEP_PFVF_MBOX_VERSION_CURRENT);
> > > + if (vf_version < OCTEP_PFVF_MBOX_VERSION_CURRENT)
> > > + rsp->s_version.version = vf_version;
> > > else
> > > - rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> > > + rsp->s_version.version =
> > OCTEP_PFVF_MBOX_VERSION_CURRENT;
> > > +
> > > + oct->vf_info[vf_id].mbox_version = rsp->s_version.version;
> > > + dev_dbg(&oct->pdev->dev, "VF id:%d negotiated VF version:%d\n",
> > > + vf_id, oct->vf_info[vf_id].mbox_version);
> > > +
> > > + rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> > > }
> >
> > <...>
> >
> > > +#define OCTEP_PFVF_MBOX_VERSION_CURRENT
> > OCTEP_PFVF_MBOX_VERSION_V1
> >
> > This architecture design is unlikely to work in the real world unless
> > you control both PF and VF environment. Mostly PF is running some old
> > legacy distribution while VFs run more modern OS and this check will
> > prevent to run new driver in VF.
> >
> > Thanks
>
> Thanks for the review. This version validation only concerns regarding the control net API layer (which is used to communicate with
> the firmware). In the case you have described, this instead enables new VF drivers to atleast work atop legacy PF drivers (note legacy here still
> refers to PF drivers which support this backward compatibility), although they might not be able to use the latest control net functionalities that they
> have been enabled for.
The question what will be in X years from now, when you will have v100?
Will you fallback to v0 for backward compatibility?
>
> In the absence of such a backward compatibility, VF drivers would issue control net requests which PF drivers wouldn't know, only leading to logs of
> incompatibility errors and erroneous usage.
>
> Also again please note that this version compatibility only concerns the control net infrastructure and API (the control plane).
It doesn't matter, even in best scenario, you can't guarantee that code in VM actually
implements version Y fully and will need to check correctness per-command anyway.
Thanks
>
next prev parent reply other threads:[~2023-12-11 11:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 6:33 [PATCH net-next v3 0/4] add PF-VF mailbox support Shinas Rasheed
2023-12-11 6:33 ` [PATCH net-next v3] octeon_ep: add PF-VF mailbox communication Shinas Rasheed
2023-12-13 0:10 ` Jakub Kicinski
2023-12-11 6:33 ` [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox version support Shinas Rasheed
2023-12-11 8:46 ` Leon Romanovsky
2023-12-11 10:31 ` [EXT] " Shinas Rasheed
2023-12-11 11:23 ` Leon Romanovsky [this message]
2023-12-11 14:51 ` Shinas Rasheed
2023-12-11 15:16 ` Leon Romanovsky
2023-12-11 15:39 ` Shinas Rasheed
2023-12-11 6:33 ` [PATCH net-next v3 3/4] octeon_ep: control net framework to support VF offloads Shinas Rasheed
2023-12-11 6:33 ` [PATCH net-next v3 4/4] octeon_ep: support firmware notifications for VFs Shinas Rasheed
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=20231211112305.GD4870@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=egallen@redhat.com \
--cc=hgani@marvell.com \
--cc=horms@kernel.org \
--cc=kheib@redhat.com \
--cc=konguyen@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschmidt@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sedara@marvell.com \
--cc=srasheed@marvell.com \
--cc=vburru@marvell.com \
--cc=vimleshk@marvell.com \
--cc=wizhao@redhat.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).