On 04/10/2015 07:36 PM, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2015 at 01:10:43PM -0400, Doug Ledford wrote:
>
>> documented. I get why you link the address variant, because it pops out
>> all the things that are special about IBoE addressing and calls out that
>> the issues need to be handled.
On 4/10/2015 5:06 PM, ira.weiny wrote:
On Fri, Apr 10, 2015 at 01:17:23PM -0600, Jason Gunthorpe wrote:
...
So trying to sum up.
Have we settled on the following "capabilities"? Helper function names aside.
/* legacy to communicate to userspace */
RDMA_LINK_LAYER_IB = 0x0001,
On Fri, Apr 10, 2015 at 01:17:23PM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2015 at 02:24:26PM -0400, Doug Ledford wrote:
>
> > IPoIB is more than just an ULP. It's a spec. And it's very IB
> > specific. It will only work with OPA because OPA is imitating IB.
> > To run it on another fab
On Fri, Apr 10, 2015 at 12:04:55PM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 10, 2015 at 01:38:38PM -0400, ira.weiny wrote:
>
> >
> > I don't think that is appropriate. You have been advocating that the checks
> > be clear as to what support we need.
>
> Right, but this is narrow, and we ar
On Thu, 2015-04-09 at 10:01 -0600, Jason Gunthorpe wrote:
> On Thu, Apr 09, 2015 at 10:34:30AM -0400, Doug Ledford wrote:
>
> > These are exactly the tests I proposed Jason. I'm not sure I see your
> > point here. I guess my point is that although the scenario of all the
> > different items seem
On Thu, Apr 09, 2015 at 02:42:24PM +0200, Michael Wang wrote:
> On 04/08/2015 10:10 PM, Jason Gunthorpe wrote:
> [snip]
> >
> > Some of the other checks in this file revolve around pkey, I'm not
> > sure what rocee does there? cap_pkey_supported ?
>
> I'm not sure if this count in capability... h
On Thu, Apr 09, 2015 at 10:34:30AM -0400, Doug Ledford wrote:
> These are exactly the tests I proposed Jason. I'm not sure I see your
> point here. I guess my point is that although the scenario of all the
> different items seems complex, it really does boil down to needing only
> exactly what I
On Wed, 2015-04-08 at 14:10 -0600, Jason Gunthorpe wrote:
> On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
>
> > To straighten all this out, lets break management out into the two
> > distinct types:
> >
> > rdma_port_ib_fabric_mgmt() <- fabric specific management tasks: MAD, SM,
>
On 04/08/2015 10:10 PM, Jason Gunthorpe wrote:
[snip]
>
> Some of the other checks in this file revolve around pkey, I'm not
> sure what rocee does there? cap_pkey_supported ?
I'm not sure if this count in capability... how shall we describe it?
Regards,
Michael Wang
>
> Jason
>
--
To unsubsc
On 04/08/2015 10:10 PM, Jason Gunthorpe wrote:
[snip]
>
>> As Sean pointed out, force_grh should be rdma_dev_is_iboe(). The cm
>
> I actually really prefer cap_mandatory_grh - that is what is going on
> here. ie based on that name (as a reviewer) I'd expect to see the mad
> layer check that the
On 04/08/2015 08:29 PM, Doug Ledford wrote:
> On Tue, 2015-04-07 at 14:42 +0200, Michael Wang wrote:
>> Add new callback query_transport() and implement for each HW.
>
> My response here is going to be a long email, but that's because it's
> easier to respond to the various patches all in one resp
On 4/8/2015 4:10 PM, Jason Gunthorpe wrote:
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
...
rdma_port_get_read_sge(dev, port)
{
if (rdma_transport_is_iwarp)
return 1;
return dev->port[port]->max_sge;
}
Hum, that is nice, but it doesn't quite
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
> To straighten all this out, lets break management out into the two
> distinct types:
>
> rdma_port_ib_fabric_mgmt() <- fabric specific management tasks: MAD, SM,
> multicast. The proper test for this with my bitmap above is a simple
On Wed, Apr 08, 2015 at 06:41:22PM +, Hefty, Sean wrote:
> I too would like to see this as the end result, but I think it's
> possible to stage the changes by having the static inline calls
> being added convert to using these sort of attributes.
I agree as well, this patch set is already so
> I'm concerned about the performance implications of this. The size of
> this patchset already points out just how many places in the code we
> have to check for various aspects of the device transport in order to do
> the right thing. Without going through the entire list to see how many
> are
On Tue, 2015-04-07 at 14:42 +0200, Michael Wang wrote:
> Add new callback query_transport() and implement for each HW.
My response here is going to be a long email, but that's because it's
easier to respond to the various patches all in one response in order to
preserve context. So, while I'm res
16 matches
Mail list logo