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
Add new callback query_transport() and implement for each HW.
Mapping List:
node-type link-layer old-transport new-transport
nes RNICETH IWARP IWARP
amso1100RNICETH IWARP IWARP
cxg
17 matches
Mail list logo
