On Fri, Apr 24, 2015 at 02:53:37PM +, Liran Liss wrote:
> > From: ira.weiny [mailto:ira.we...@intel.com]
> > [snip]
> >
> > > >
> > > > 2)The name rdma_tech_* is lame.
> > > > rdma_transport_*(), adhering to the above (*) remark, is much better.
> > > > For example, both IB and ROCE *do* use
On Fri, Apr 24, 2015 at 02:44:29PM +, Liran Liss wrote:
> > From: Michael Wang [mailto:yun.w...@profitbricks.com]
>
>
> > [snip]
> > >
> > > Depends on who is "we".
> > > For ULPs, you are probably right.
> > >
> > > However, core services (e.g., mad management, CM, SA) do care about
> >
On Fri, Apr 24, 2015 at 10:42:26AM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2015 at 03:00:15PM +, Liran Liss wrote:
>
> > Currently, the only code in the kernel that has an SMI interface is IB.
> > When OPA is introduced, add the proper helper.
>
> We already have tests checking for
On Fri, Apr 24, 2015 at 02:53:37PM +, Liran Liss wrote:
From: ira.weiny [mailto:ira.we...@intel.com]
[snip]
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB and ROCE *do* use the same transport.
On Fri, Apr 24, 2015 at 10:42:26AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 24, 2015 at 03:00:15PM +, Liran Liss wrote:
Currently, the only code in the kernel that has an SMI interface is IB.
When OPA is introduced, add the proper helper.
We already have tests checking for SMI is
On Fri, Apr 24, 2015 at 02:44:29PM +, Liran Liss wrote:
From: Michael Wang [mailto:yun.w...@profitbricks.com]
[snip]
Depends on who is we.
For ULPs, you are probably right.
However, core services (e.g., mad management, CM, SA) do care about
various details.
In some
On Fri, Apr 24, 2015 at 03:00:15PM +, Liran Liss wrote:
> Currently, the only code in the kernel that has an SMI interface is IB.
> When OPA is introduced, add the proper helper.
We already have tests checking for SMI is supported so QP0 can be
created, this is to support ROCEE
> All I am
On 04/24/2015 04:44 PM, Liran Liss wrote:
>> From: Michael Wang [mailto:yun.w...@profitbricks.com]
>
>
>> [snip]
[snip]
>>
>
> We don't want to stop code branches that are not abstractions but rather
> depend
> on the specific technology!
> There is no generic "iWARP CM" - only one.
> There
> From: Hefty, Sean [mailto:sean.he...@intel.com]
[snip]
> > > So, I think that our "old-transport" below is just fine.
> > > No need to change it (and you aren't, since it is currently
> > > implemented
> > as a function).
> >
> > I think there is a need to change this. Encoding the transport
> From: Michael Wang [mailto:yun.w...@profitbricks.com]
> [snip]
> >
> > Depends on who is "we".
> > For ULPs, you are probably right.
> >
> > However, core services (e.g., mad management, CM, SA) do care about
> various details.
> > In some cases, where it doesn't matter, this code will use
From: Hefty, Sean [mailto:sean.he...@intel.com]
[snip]
So, I think that our old-transport below is just fine.
No need to change it (and you aren't, since it is currently
implemented
as a function).
I think there is a need to change this. Encoding the transport into
the node
From: Michael Wang [mailto:yun.w...@profitbricks.com]
[snip]
Depends on who is we.
For ULPs, you are probably right.
However, core services (e.g., mad management, CM, SA) do care about
various details.
In some cases, where it doesn't matter, this code will use management
helpers.
On 04/24/2015 04:44 PM, Liran Liss wrote:
From: Michael Wang [mailto:yun.w...@profitbricks.com]
[snip]
[snip]
We don't want to stop code branches that are not abstractions but rather
depend
on the specific technology!
There is no generic iWARP CM - only one.
There is no generic
On Fri, Apr 24, 2015 at 03:00:15PM +, Liran Liss wrote:
Currently, the only code in the kernel that has an SMI interface is IB.
When OPA is introduced, add the proper helper.
We already have tests checking for SMI is supported so QP0 can be
created, this is to support ROCEE
All I am
On 04/22/2015 07:10 PM, ira.weiny wrote:
> On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
>> On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
>
> [snip]
>
>>>
>>> 2)The name rdma_tech_* is lame.
>>> rdma_transport_*(), adhering to the above (*) remark, is much better.
>>>
On 04/22/2015 06:57 PM, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
>
>>> 2)The name rdma_tech_* is lame.
>>> rdma_transport_*(), adhering to the above (*) remark, is much better.
>>> For example, both IB and ROCE *do* use the same transport.
>>
>> I
On 04/22/2015 06:16 PM, Liran Liss wrote:
[snip]
>
> Depends on who is "we".
> For ULPs, you are probably right.
>
> However, core services (e.g., mad management, CM, SA) do care about various
> details.
> In some cases, where it doesn't matter, this code will use management helpers.
> In
On 04/22/2015 06:57 PM, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB and ROCE *do* use the same transport.
I especially want
On 04/22/2015 07:10 PM, ira.weiny wrote:
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
[snip]
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB
On 04/22/2015 06:16 PM, Liran Liss wrote:
[snip]
Depends on who is we.
For ULPs, you are probably right.
However, core services (e.g., mad management, CM, SA) do care about various
details.
In some cases, where it doesn't matter, this code will use management helpers.
In other cases,
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
> On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
[snip]
> >
> > 2)The name rdma_tech_* is lame.
> > rdma_transport_*(), adhering to the above (*) remark, is much better.
> > For example, both IB and ROCE *do* use the same
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
> > 2)The name rdma_tech_* is lame.
> > rdma_transport_*(), adhering to the above (*) remark, is much better.
> > For example, both IB and ROCE *do* use the same transport.
>
> I especially want to second this. I haven't really been
On Apr 21, 2015, at 6:36 PM, Liran Liss wrote:
> An ib_dev (or a port of) should be distinguished by 3 qualifiers:
> - The link layer:
> -- Ethernet (shared by iWARP, USNIC, and ROCE)
> -- Infiniband
>
> - The transport (*)
> -- IBTA transport (shared by IB and ROCE)
> -- iWARP transport
> --
> > So, I think that our "old-transport" below is just fine.
> > No need to change it (and you aren't, since it is currently implemented
> as a function).
>
> I think there is a need to change this. Encoding the transport into the
> node
> type is not a good idea. Having different "transport
On Wed, Apr 22, 2015 at 11:38:34AM +, Liran Liss wrote:
> This is redundant. All IB ports have SMI, so if you know that you
> are using an IB device, you know you have an SMI.
You should really go back and read the whole thread, this has already
been discussed.
The patch set was developed
> From: Michael Wang [mailto:yun.w...@profitbricks.com]
>
> Hi, Liran
>
> Thanks for the comment :-)
>
> On 04/22/2015 01:36 AM, Liran Liss wrote:
> [snip]
> >
> > (**) This has been extended to also encode the transport in the current
> code.
> > At least for user-space visible APIs, we might
On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
> Hi Michael,
>
> The spirit of this patch-set is great, but I think that we need to clarify
> some concepts.
> Since this will affect the whole patch-set, I am laying out my concerns here
> instead.
>
> A suggestion for the resulting
On 04/22/2015 04:41 AM, ira.weiny wrote:
[snip]
>
>>
>> 5) Do no modify phys_state_show() in [PATCH v5 09/27] IB/Verbs: Reform
>> IB-core verbs/uverbs_cmd/sysfs
>> It *is* the link layer!
>
> I agree with this. When the Link Layer is directly being requested we should
> report the link
Hi, Liran
Thanks for the comment :-)
On 04/22/2015 01:36 AM, Liran Liss wrote:
[snip]
>
> (**) This has been extended to also encode the transport in the current code.
> At least for user-space visible APIs, we might chose to leave this for
> backward compatibility, but we can consider
On 04/22/2015 02:28 AM, ira.weiny wrote:
[snip]
>>
>> Highlights:
>> The patch set covered a wide range of IB stuff, thus for those who are
>> familiar with the particular part, your suggestion would be invaluable
>> ;-)
>>
>> Patch 1#~15# included all the logical reform, 16#~25#
So, I think that our old-transport below is just fine.
No need to change it (and you aren't, since it is currently implemented
as a function).
I think there is a need to change this. Encoding the transport into the
node
type is not a good idea. Having different transport semantics
On Wed, Apr 22, 2015 at 11:38:34AM +, Liran Liss wrote:
This is redundant. All IB ports have SMI, so if you know that you
are using an IB device, you know you have an SMI.
You should really go back and read the whole thread, this has already
been discussed.
The patch set was developed
From: Michael Wang [mailto:yun.w...@profitbricks.com]
Hi, Liran
Thanks for the comment :-)
On 04/22/2015 01:36 AM, Liran Liss wrote:
[snip]
(**) This has been extended to also encode the transport in the current
code.
At least for user-space visible APIs, we might chose to leave
On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
Hi Michael,
The spirit of this patch-set is great, but I think that we need to clarify
some concepts.
Since this will affect the whole patch-set, I am laying out my concerns here
instead.
A suggestion for the resulting management
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
On Tue, 2015-04-21 at 23:36 +, Liran Liss wrote:
[snip]
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB and ROCE *do* use the same transport.
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB and ROCE *do* use the same transport.
I especially want to second this. I haven't really been happy
On Apr 21, 2015, at 6:36 PM, Liran Liss lir...@mellanox.com wrote:
An ib_dev (or a port of) should be distinguished by 3 qualifiers:
- The link layer:
-- Ethernet (shared by iWARP, USNIC, and ROCE)
-- Infiniband
- The transport (*)
-- IBTA transport (shared by IB and ROCE)
-- iWARP
On 04/22/2015 04:41 AM, ira.weiny wrote:
[snip]
5) Do no modify phys_state_show() in [PATCH v5 09/27] IB/Verbs: Reform
IB-core verbs/uverbs_cmd/sysfs
It *is* the link layer!
I agree with this. When the Link Layer is directly being requested we should
report the link layer. However,
On 04/22/2015 02:28 AM, ira.weiny wrote:
[snip]
Highlights:
The patch set covered a wide range of IB stuff, thus for those who are
familiar with the particular part, your suggestion would be invaluable
;-)
Patch 1#~15# included all the logical reform, 16#~25# introduced the
Hi, Liran
Thanks for the comment :-)
On 04/22/2015 01:36 AM, Liran Liss wrote:
[snip]
(**) This has been extended to also encode the transport in the current code.
At least for user-space visible APIs, we might chose to leave this for
backward compatibility, but we can consider cleaning up
On Tue, Apr 21, 2015 at 11:36:40PM +, Liran Liss wrote:
> Hi Michael,
>
> The spirit of this patch-set is great, but I think that we need to clarify
> some concepts.
> Since this will affect the whole patch-set, I am laying out my concerns here
> instead.
>
> A suggestion for the resulting
On Mon, Apr 20, 2015 at 10:28:57AM +0200, Michael Wang wrote:
>
> Since v4:
> * Thanks for the comments from Hal, Sean, Tom, Or Gerlitz, Jason,
> Roland, Ira and Steve :-) Please remind me if anything missed :-P
> * Fix logical issue inside 3#, 14#
> * Refine 3#, 4#, 5# with label
Hi Michael,
The spirit of this patch-set is great, but I think that we need to clarify some
concepts.
Since this will affect the whole patch-set, I am laying out my concerns here
instead.
A suggestion for the resulting management helpers is given below.
I believe the result would be much more
nox.co.il
>> Cc: Tom Tucker; Steve Wise; Hoang-Nam Nguyen; Christoph Raisch; Mike
>> Marciniszyn; Eli Cohen; Faisal Latif; Jack Morgenstein; Or Gerlitz; Haggai
>> Eran;
>> Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford
>> Subject: Re: [PATCH v5 00/27] IB/Verbs: I
n; Faisal Latif; Jack Morgenstein; Or Gerlitz; Haggai
> Eran;
> Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford
> Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
>
> Hi, Devesh
>
> On 04/21/2015 07:41 AM, Devesh Sharma wrote:
> > Hi Michael,
> >
> &
Hi, Devesh
On 04/21/2015 07:41 AM, Devesh Sharma wrote:
> Hi Michael,
>
> is there a specific git branch available to pull out all the patches?
Not yet, we may need the maintainer to tell us which branch could
the series been applied for testing purpose, after we all satisfied :-)
For now we
Hi, Devesh
On 04/21/2015 07:41 AM, Devesh Sharma wrote:
Hi Michael,
is there a specific git branch available to pull out all the patches?
Not yet, we may need the maintainer to tell us which branch could
the series been applied for testing purpose, after we all satisfied :-)
For now we
Marciniszyn; Eli Cohen; Faisal Latif; Jack Morgenstein; Or Gerlitz; Haggai
Eran;
Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford
Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
Hi, Devesh
On 04/21/2015 07:41 AM, Devesh Sharma wrote:
Hi Michael,
is there a specific git
On Tue, Apr 21, 2015 at 11:36:40PM +, Liran Liss wrote:
Hi Michael,
The spirit of this patch-set is great, but I think that we need to clarify
some concepts.
Since this will affect the whole patch-set, I am laying out my concerns here
instead.
A suggestion for the resulting
On Mon, Apr 20, 2015 at 10:28:57AM +0200, Michael Wang wrote:
Since v4:
* Thanks for the comments from Hal, Sean, Tom, Or Gerlitz, Jason,
Roland, Ira and Steve :-) Please remind me if anything missed :-P
* Fix logical issue inside 3#, 14#
* Refine 3#, 4#, 5# with label 'free'
*
Hi Michael,
The spirit of this patch-set is great, but I think that we need to clarify some
concepts.
Since this will affect the whole patch-set, I am laying out my concerns here
instead.
A suggestion for the resulting management helpers is given below.
I believe the result would be much more
; Or Gerlitz; Haggai
Eran;
Ira Weiny; Tom Talpey; Jason Gunthorpe; Doug Ledford
Subject: Re: [PATCH v5 00/27] IB/Verbs: IB Management Helpers
Hi, Devesh
On 04/21/2015 07:41 AM, Devesh Sharma wrote:
Hi Michael,
is there a specific git branch available to pull out all the patches
Hi Michael,
is there a specific git branch available to pull out all the patches?
-Regards
Devesh
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Michael Wang
> Sent: Monday, April 20, 2015 1:59 PM
> To: Roland
Hi Michael,
is there a specific git branch available to pull out all the patches?
-Regards
Devesh
-Original Message-
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
ow...@vger.kernel.org] On Behalf Of Michael Wang
Sent: Monday, April 20, 2015 1:59 PM
To: Roland Dreier;
54 matches
Mail list logo
