On 04/16/2015 05:58 PM, Jason Gunthorpe wrote:
> On Thu, Apr 16, 2015 at 10:08:10AM +0200, Michael Wang wrote:
>>
>> Use raw management helpers to reform cm related part in IB-core cma/ucm.
>>
>> These checks focus on the device cm type rather than the port capability,
>> directly pass port 1 wor
On 04/16/2015 07:30 PM, Hefty, Sean wrote:
>>> To be confirmed:
>>> PORT ASSIGNED
>>> rdma_init_qp_attr Y
>>> rdma_destroy_id unknown
>>> cma_listen_on_dev N
>>> cma_bind_loopback N
>
> Bind loopback will attach to a port, but
On 04/16/2015 07:21 PM, Tom Talpey wrote:
> On 4/16/2015 11:22 AM, Michael Wang wrote:
>>
>>
>> On 04/16/2015 04:31 PM, Hefty, Sean wrote:
> This is equivalent to today where the checks are per node rather than
> per port.
>
> Should all checks here be port 1 based or only certain
On Thu, Apr 16, 2015 at 01:38:07PM -0400, Hal Rosenstock wrote:
> On 4/16/2015 11:58 AM, Jason Gunthorpe wrote:
> > It also looks like hardwired 1 won't work on switch ports, so it is no-go.
>
> AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the
> current code. There is no need for
>
> On 4/16/2015 11:58 AM, Jason Gunthorpe wrote:
> > It also looks like hardwired 1 won't work on switch ports, so it is no-go.
>
> AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the current
> code. There is no need for CM/RDMA CM on base switch port 0.
I concur and I thought I
On 4/16/2015 11:58 AM, Jason Gunthorpe wrote:
> It also looks like hardwired 1 won't work on switch ports, so it is no-go.
AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the
current code. There is no need for CM/RDMA CM on base switch port 0.
--
To unsubscribe from this list: send
> > To be confirmed:
> > PORT ASSIGNED
> > rdma_init_qp_attr Y
> > rdma_destroy_id unknown
> > cma_listen_on_dev N
> > cma_bind_loopback N
Bind loopback will attach to a port, but the id does not have on entry.
> > rdma_lis
On 4/16/2015 11:22 AM, Michael Wang wrote:
On 04/16/2015 04:31 PM, Hefty, Sean wrote:
This is equivalent to today where the checks are per node rather than
per port.
Should all checks here be port 1 based or only certain ones like listen
? For example, in connect/reject/disconnect, don't we a
On Thu, Apr 16, 2015 at 04:55:10PM +, Hefty, Sean wrote:
> > After the discussion settled, I ended up thinking that implementing
> > explicit device checks, for use by CM, and the BUG_ON at register to
> > require all ports have the same value was the best option.
>
> Sure, but why not update
> After the discussion settled, I ended up thinking that implementing
> explicit device checks, for use by CM, and the BUG_ON at register to
> require all ports have the same value was the best option.
Sure, but why not update the other areas anyway? This way when listens become
per port, rather
On Thu, Apr 16, 2015 at 10:08:10AM +0200, Michael Wang wrote:
>
> Use raw management helpers to reform cm related part in IB-core cma/ucm.
>
> These checks focus on the device cm type rather than the port capability,
> directly pass port 1 works currently, but can't support mixing cm type
> devic
On 04/16/2015 04:31 PM, Hefty, Sean wrote:
>>> This is equivalent to today where the checks are per node rather than
>>> per port.
>>>
>>> Should all checks here be port 1 based or only certain ones like listen
>>> ? For example, in connect/reject/disconnect, don't we already have port
>>> ? Gues
> > This is equivalent to today where the checks are per node rather than
> > per port.
> >
> > Should all checks here be port 1 based or only certain ones like listen
> > ? For example, in connect/reject/disconnect, don't we already have port
> > ? Guess this can be dealt with later as this is not
On 4/16/2015 4:08 AM, Michael Wang wrote:
>
> Use raw management helpers to reform cm related part in IB-core cma/ucm.
>
> These checks focus on the device cm type rather than the port capability,
> directly pass port 1 works currently, but can't support mixing cm type
> device in future.
This i
14 matches
Mail list logo
