> -----Original Message----- > From: Cheng Xu <chengyou@xxxxxxxxxxxxxxxxx> > Sent: Wednesday, 19 January 2022 04:58 > To: Bernard Metzler <BMT@xxxxxxxxxxxxxx>; jgg@xxxxxxxx; > dledford@xxxxxxxxxx > Cc: leon@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; > KaiShen@xxxxxxxxxxxxxxxxx; tonylu@xxxxxxxxxxxxxxxxx > Subject: [EXTERNAL] Re: [PATCH rdma-next v2 08/11] RDMA/erdma: Add > connection management (CM) support > > > > On 1/18/22 10:49 PM, Bernard Metzler wrote: > > > > <...> > > >> + cm_id = cep->listen_cep->cm_id; > >> + > >> + event.ird = cep->dev->attrs.max_ird; > >> + event.ord = cep->dev->attrs.max_ord; > > > > Provide to the user also the negotiated IRD/ORD of the > > reply. Things may have changed upon peer's request. > > See current siw code for the details. > > > > IRD/ORD in ERDMA hardware is fixed, no need to negotiate them in MPA > request/reply now. For this reason, we didn't follow siw with MPA v2. How is that working? Is the idea that the adapter implements a fixed value which (hopefully) always exceeds any ULP requested IRD/ORD? In any case, the negotiated (even if fixed) value MUST be provided to the ULP's at both ends. In the erdma case, it is likely more than the ULP was asking for. See RFC 5040, section 6.1 https://datatracker.ietf.org/doc/html/rfc5040#section-6.1 > > >> + } else { > >> + cm_id = cep->cm_id; > >> + } > >> + > >> + if (reason == IW_CM_EVENT_CONNECT_REQUEST || > >> + reason == IW_CM_EVENT_CONNECT_REPLY) { > >> + u16 pd_len = be16_to_cpu(cep->mpa.hdr.params.pd_len); > >> + > > > > Does erdma support MPA protocol version 2, and enhanced connection > > setup protocol? In that case, some private data contain protocol > > information and must be hidden to the user. > > > > Now we follow MPA v1. And due to specially network environment in Cloud > VPC, we extend the MPA v1: We exchange information with a extend header, > which followed with original MPA v1 header. This is control information placed between MPAv1 header and ULP's private data? So erdma is not interoperable with a device implementing IETF iWarp? > > >> + if (pd_len) { > >> + event.private_data_len = pd_len; > >> + event.private_data = cep->mpa.pdata; > >> + if (cep->mpa.pdata == NULL) > >> + event.private_data_len = 0; > >> + } > >> + > >> + getname_local(cep->sock, &event.local_addr); > >> + getname_peer(cep->sock, &event.remote_addr); > >> + } > >> + > > <...> > Thanks, Bernard.