RE: [PATCH rdma-next v2 08/11] RDMA/erdma: Add connection management (CM) support

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

 




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





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux