-----Original Message-----
From: Long Li <longli@microsoft.com>
Sent: Thursday, 20 October 2022 22:42
To: Bernard Metzler <redacted>; KY Srinivasan
[off-list ref]; Haiyang Zhang [off-list ref]; Stephen
Hemminger [off-list ref]; Wei Liu [off-list ref]; Dexuan
Cui [off-list ref]; David S. Miller [off-list ref]; Jakub
Kicinski [off-list ref]; Paolo Abeni [off-list ref]; Jason
Gunthorpe [off-list ref]; Leon Romanovsky [off-list ref];
edumazet@google.com; shiraz.saleem@intel.com; Ajay Sharma
[off-list ref]
Cc: linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; linux-
kernel@vger.kernel.org; linux-rdma@vger.kernel.org
Subject: [EXTERNAL] RE: [Patch v8 12/12] RDMA/mana_ib: Add a driver for
Microsoft Azure Network Adapter

quoted

Subject: RE: [Patch v8 12/12] RDMA/mana_ib: Add a driver for Microsoft
Azure Network Adapter

<snip>

quoted

While I understand the driver is currently used in a proprietary
environment only, where even the port state seem not to matter,
I am not sure this looks good. Shouldn't the driver better adhere
to basic assumptions of its RDMA core environment?

The user space code is for DPDK. They are at:
INVALID URI REMOVED
3A__github.com_DPDK_dpdk_tree_main_drivers_net_mana&d=DwIGaQ&c=jf_iaSHvJObT
bx-siA1ZOg&r=2TaYXQ0T-
r8ZO1PP1alNwU_QJcRRLfmYTAgd3QCvqSc&m=Wwob5ZbYrjAfZhKpS3eLoAVYnqDfpHBNoIoW88
iq3fhkBx0yeS2BtrlXpYu3FsIr&s=kBEadEfaoNf85WNoAYWaviwBQnUyNbP4fq2aK4HnS5I&e=

The RAW_QP implementation provides all necessary values for
its targeted usage. I'm not aware of mandatory values that
should be reported according to RDMA verbs interface spec.
If there are mandatory required values, please point me to the spec,
I will add those to the driver.

I am not sure if we shall discuss specifications here. It might
hurt badly, see for example that well aged verbs specification:
http://www.rdmaconsortium.org/home/draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf
section '9.2.1.2 Query RNIC'. So many attributes to report ;)
(and most of those are reflected in ib_qp_attr)

For good reasons there are no abstract interface specifications
in Linux kernel. I was just wondering if it is good to leave
concrete attributes which are not (yet?) reported at random. It
is obviously working okay today for your environment.
But memset zero everything you don't care about today might be
just safe to detect an unexpected interpretation of those
fields in the future?


Thanks,
Bernard.