Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
From:   Shinas Rasheed <srasheed@marvell.com>
To:     Leon Romanovsky <leon@kernel.org>
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
Thread-Topic: [EXT] Re: [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox
 version support
Thread-Index: AQHaK/wMORkyMuRMT0eHMOpWmawaoLCjxTQAgAAaEyCAABGSgIAAG5SA
Date:   Mon, 11 Dec 2023 14:51:19 +0000
Message-ID: <PH0PR18MB4734AAA106B7EDE3D80C59DCC78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
References: <20231211063355.2630028-1-srasheed@marvell.com>
 <20231211063355.2630028-3-srasheed@marvell.com>
 <20231211084652.GC4870@unreal>
 <PH0PR18MB4734652F50856F52507577ADC78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
 <20231211112305.GD4870@unreal>
In-Reply-To: <20231211112305.GD4870@unreal>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8vcB4lw74FQdscLwY3lHZlqoh34U9LCz4XOLoxeqBcF0lqEijp7on6BmQ8uf?=
 =?us-ascii?Q?kBlViQva+HJSfFmsxfLj203A0xmvPkyrS3V8gVqiZJ5PEjkz7ngb0hlZURSq?=
 =?us-ascii?Q?zFzrKUYl0e2j5L/U9p4yvsuoa3jZtJFkSWk4zPoTfE3FWwj5+RenaFMS+fzQ?=
 =?us-ascii?Q?uB5coUWbvwlngoC4O3rTaAVvTsZ2OC7e692aDp9eMMgl6KGN6V6GGdHCAmqi?=
 =?us-ascii?Q?nNLzFhQ3fnb88kDT6O4Xm7evdYvsi9Qlfr0Ihb2iaF3j3EAZiRB8bcHq7+to?=
 =?us-ascii?Q?strLLCrnp6t+Yo9+zBKkjbh38MRQNDqWNyrHyeBA6cMS5l6KRyZOcH7olDTn?=
 =?us-ascii?Q?abwagyYFOtqZL5DtwoAOrvHkeZMTLtnhyjO5SB1U+hbaaDU9Li0PVT9xPBz/?=
 =?us-ascii?Q?D40IyKjTAFMcQzN9poCJduWTz6KEIehnvAL2KE192YvpKI3pU8oUqgVnd67j?=
 =?us-ascii?Q?oRZNOR5L3stk1dsCQbQIVesTw/uAs3dNoXpBXdkEVuqYuniIMFYEFu6Me7NY?=
 =?us-ascii?Q?7zZi/hKbWD2rVnxmqLMpyTEuOGxglqhoT8QxkpmoYNdoRohEKTjhARh8H55E?=
 =?us-ascii?Q?CXOYVdkGwwbFsj2OmmwNUjVOY9MOy/TWOEOOCEYxzWXGld81k8EpRh24nsid?=
 =?us-ascii?Q?XaIBV5iPImDDn8qQWxG5wAirGh1XpWLJwvmgiuH7bEuU9vN9W5g1Jy8JsFL5?=
 =?us-ascii?Q?N89+HvuSlx3mFELmxpPab2zrbtlsuGO3xD11mxYSuNqjKjXXxaNdvp4JnTgi?=
 =?us-ascii?Q?vK878SXIVPqhTZnay1olWrCBJGiL1muDd3+SBWp4p0Ueqg9yUdSNMVVIDT9T?=
 =?us-ascii?Q?wbcc8+TGjDRJhhI56bc9Eza4ae3YLTYvlrmkpy4Bbc09jH7re9B3Ha7M7SHX?=
 =?us-ascii?Q?/pCsf2QNllodnzAuEyxD+CYtuW+abejJHuAAuf7UICjTEztKJDa6YyxfNfpF?=
 =?us-ascii?Q?xVFd773Ozyps2okR6l55nVPk6e59kiW7CIwdpT4DXHE2lo0EzraTVM6qUEqi?=
 =?us-ascii?Q?fytkXFtAQ1IQUsBYOROPaVOqB5zaVm+UUKGiAzPlv3Fa1NkEIBw6g+1UV1oF?=
 =?us-ascii?Q?lF/XV2aEcx/cXdYeGuU2Uxnv+7dBOFz5s0KiMqvJC8bqrzUUM6+vtmSLTX+0?=
 =?us-ascii?Q?z5UJoMAI7Mh6Qj1JfByheGQMHe76ntlWhaXLxFUJJSYTwxr8vHT6NRvXLi1H?=
 =?us-ascii?Q?hhQhSb1Z07RMB3SNZqcP/WvTiYd7M5KTcOpTIFNP/9GPTPZAhW9u+rtTzgAn?=
 =?us-ascii?Q?BI+H5ymoOddRp38FS6G2x7I65sv7DL75zbkrw0YKFJMHxFN3VSja4fqBsavZ?=
 =?us-ascii?Q?vVCVj+41hOfACQK5r6QATAuGaqYpGphFgo/JRK/DFoX7sGHo6/kS1W57sdvG?=
 =?us-ascii?Q?ienWsPW1VGi/GnLSXz1Mzzxrw+/Tw/sTdwUCQtMYkjz9AJpRZBi8c79K7HSI?=
 =?us-ascii?Q?4Babu1HoES+n0Br9DNb2yjqRKLMuX3s0KNcdWxRUpqadpqwaW2BjGCTyZTAt?=
 =?us-ascii?Q?P6RewUY8gzCYDJJZmiBazbS5IMxvVfuOClY2C1xcSSvvpRKap2MpOwxDaPWb?=
 =?us-ascii?Q?uqddlC9NJ5qU03mJnhruRlwHxsRHw4bVdLopAW9I?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: marvell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4734.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00f7646f-f710-4db6-afb7-08dbfa58a2c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2023 14:51:19.7730
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KnuEsQjPaLlGD0ylFaM3eRdUE5+ZHR7FaDGQkHSHchq7zWCUraHE+uhTdmfX3+bG4Yurn/bSS7OXTweCtv/fsA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR18MB4257
X-Proofpoint-GUID: uBsjNSyrxVhbyzH0g4DRxQlQ2d5tC4EH
X-Proofpoint-ORIG-GUID: uBsjNSyrxVhbyzH0g4DRxQlQ2d5tC4EH
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-12-09_02,2023-12-07_01,2023-05-22_02
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 11 Dec 2023 06:51:57 -0800 (PST)

> > > 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), althou=
gh
> >they might not be able to use the latest control net functionalities tha=
t they
> > have been enabled for.
>=20
> The question what will be in X years from now, when you will have v100?
> Will you fallback to v0 for backward compatibility?
>=20
> >
> > In the absence of such a backward compatibility, VF drivers would issue
> >control net requests which PF drivers wouldn't know, only leading to log=
s of
> > incompatibility errors and erroneous usage.
> >
> > Also again please note that this version compatibility only concerns th=
e
> > control net infrastructure and API (the control plane).
>=20
> It doesn't matter, even in best scenario, you can't guarantee that code i=
n VM
> actually
> implements version Y fully and will need to check correctness per-command
> anyway.
>=20
> Thanks

I'm afraid as to what else can be an alternative? The control net commands =
have to be decoded and passed by the PF driver for the VFs,
as only the PFs have access to talk to firmware directly. The VF drivers do=
 not have an alternative way to query control net APIs, and may fail=20
if the control net APIs they have are not even recognized by the PF to deco=
de them.

Either VF commands which the PF can't support can be blocked at the source =
(by the equivalent PF-VF backward compatibility which will exist in VF driv=
ers)
by this negotiation, or we have to let commands come through and fail them,=
 leading to just redundancy in terms of running code. I don't see how this =
negotiation in
any way 'limit' the VF drivers.

As you said, in essence the VF drivers will have to fallback to v0 for back=
ward compatibility if the native host uses some old OS having older PF driv=
ers. If not, the=20
commands would come and fail anyways at the PF. Either way, it's an error c=
ase and this negotiation is just to decide if we are going to allow letting=
 such commands in.

Thanks for your time