> -----Original Message----- > From: Long Li <longli@xxxxxxxxxxxxx> > Sent: Thursday, 20 October 2022 22:42 > To: Bernard Metzler <BMT@xxxxxxxxxxxxxx>; KY Srinivasan > <kys@xxxxxxxxxxxxx>; Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>; Stephen > Hemminger <sthemmin@xxxxxxxxxxxxx>; Wei Liu <wei.liu@xxxxxxxxxx>; Dexuan > Cui <decui@xxxxxxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Jakub > Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; Jason > Gunthorpe <jgg@xxxxxxxx>; Leon Romanovsky <leon@xxxxxxxxxx>; > edumazet@xxxxxxxxxx; shiraz.saleem@xxxxxxxxx; Ajay Sharma > <sharmaajay@xxxxxxxxxxxxx> > Cc: linux-hyperv@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx > Subject: [EXTERNAL] RE: [Patch v8 12/12] RDMA/mana_ib: Add a driver for > Microsoft Azure Network Adapter > > > Subject: RE: [Patch v8 12/12] RDMA/mana_ib: Add a driver for Microsoft > > Azure Network Adapter > > <snip> > > > > 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.
