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
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,
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
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 the id does not
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 works
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 ones like listen
? For
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
>
> 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.
> >
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
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,
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
>
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
>>> ?
> > 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
On 04/16/2015 03:10 PM, Hal Rosenstock wrote:
> 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
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
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.
Cc: Steve Wise
Cc: Tom Talpey
Cc: Jason Gunthorpe
Cc:
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.
Cc: Steve Wise sw...@opengridcomputing.com
Cc: Tom Talpey
On 04/16/2015 03:10 PM, Hal Rosenstock wrote:
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
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 a
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
device in
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
? Guess this can be
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 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 the
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
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 is
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
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 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
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_listen
32 matches
Mail list logo
