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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux