lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <553604D2.80008@profitbricks.com>
Date:	Tue, 21 Apr 2015 10:05:38 +0200
From:	Michael Wang <yun.wang@...fitbricks.com>
To:	Devesh Sharma <Devesh.Sharma@...lex.Com>,
	Roland Dreier <roland@...nel.org>,
	Sean Hefty <sean.hefty@...el.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hal@....mellanox.co.il" <hal@....mellanox.co.il>
CC:	Tom Tucker <tom@...ngridcomputing.com>,
	Steve Wise <swise@...ngridcomputing.com>,
	Hoang-Nam Nguyen <hnguyen@...ibm.com>,
	Christoph Raisch <raisch@...ibm.com>,
	Mike Marciniszyn <infinipath@...el.com>,
	Eli Cohen <eli@...lanox.com>,
	Faisal Latif <faisal.latif@...el.com>,
	Jack Morgenstein <jackm@....mellanox.co.il>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Haggai Eran <haggaie@...lanox.com>,
	Ira Weiny <ira.weiny@...el.com>, Tom Talpey <tom@...pey.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v5 13/27] IB/Verbs: Reserve legacy transport type in 'dev_addr'

On 04/21/2015 07:58 AM, Devesh Sharma wrote:
[snip]
>>
>> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
>> index ebac646..6195bf6 100644
>> --- a/drivers/infiniband/core/cma.c
>> +++ b/drivers/infiniband/core/cma.c
>> @@ -244,14 +244,35 @@ static inline void cma_set_ip_ver(struct cma_hdr
>> *hdr, u8 ip_ver)
>>  	hdr->ip_version = (ip_ver << 4) | (hdr->ip_version & 0xF);  }
>>
>> +static inline void cma_set_legacy_transport(struct rdma_cm_id *id) {
>> +	switch (id->device->node_type) {
>> +	case RDMA_NODE_IB_CA:
>> +	case RDMA_NODE_IB_SWITCH:
>> +	case RDMA_NODE_IB_ROUTER:
>> +		id->route.addr.dev_addr.transport = RDMA_TRANSPORT_IB;
> 
> What about IBOE transport, am I missing something here? As of today ocrdma exports node_type  as RDMA_NODE_IB_CA, here transport will be set to RDMA_TRANSPORT_IB,
> Should it be RDMA_TRANPORT_IBOE?

This part is actually just the old method we used to get transport type, I'm
not sure about the usage of this 'transport' so reserve the old way for it :-P

Actually I can't locate the place using this stuff in core layer, thus I guess it
may be used by user layer or the protocol, as long as these layer using the old
logical, we better don't touch anything ;-)

Regards,
Michael Wang

> 
>> +		break;
>> +	case RDMA_NODE_RNIC:
>> +		id->route.addr.dev_addr.transport =
>> RDMA_TRANSPORT_IWARP;
>> +		break;
>> +	case RDMA_NODE_USNIC:
>> +		id->route.addr.dev_addr.transport =
>> RDMA_TRANSPORT_USNIC;
>> +		break;
>> +	case RDMA_NODE_USNIC_UDP:
>> +		id->route.addr.dev_addr.transport =
>> RDMA_TRANSPORT_USNIC_UDP;
>> +		break;
>> +	default:
>> +		BUG();
>> +	}
>> +}
>> +
>>  static void cma_attach_to_dev(struct rdma_id_private *id_priv,
>>  			      struct cma_device *cma_dev)
>>  {
>>  	atomic_inc(&cma_dev->refcount);
>>  	id_priv->cma_dev = cma_dev;
>>  	id_priv->id.device = cma_dev->device;
>> -	id_priv->id.route.addr.dev_addr.transport =
>> -		rdma_node_get_transport(cma_dev->device->node_type);
>> +	cma_set_legacy_transport(&id_priv->id);
>>  	list_add_tail(&id_priv->list, &cma_dev->id_list);  }
>>
>> --
>> 2.1.0
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body
>> of a message to majordomo@...r.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ