On 6/18/2015 5:00 PM, Doug Ledford wrote:
There is *zero* functional difference between node_type == OPA or node_type
== IB_CA and link_layer == OPA.
An application has *exactly* what they need
We have neither of these things in the kernel today. Also, if I interpreted
what was written by
On Jun 16, 2015, at 5:05 PM, Liran Liss lir...@mellanox.com wrote:
From: Doug Ledford [mailto:dledf...@redhat.com]
No. RoCE is as an open standard from the IBTA with the exact same RDMA
protocol semantics as InfiniBand and a clear set of compliancy rules without
which an implementation
From: Weiny, Ira [mailto:ira.we...@intel.com]
ib_verbs define an *extensive* direct HW access API, which is constantly
evolving.
This is the problem with verbs...
Huh?
It is its strength, if you don't break backward compatibility...
You cannot describe the intricate object relations
ib_verbs define an *extensive* direct HW access API, which is constantly
evolving.
This is the problem with verbs...
You cannot describe the intricate object relations and semantics through an
API.
In addition, you can't abstract anything or fix stuff in SW.
The only way to *truly* know
You're right that apps can be coded to other CA types, like RNICs and
USNICs. However, those are all very different from an IB_CA due to
limited queue pair types or limited primitives. If OPA had that same
limitation then I would agree it needs a different node type.
So this will be my
On 06/14/2015 03:16 PM, Liran Liss wrote:
From: Doug Ledford [mailto:dledf...@redhat.com]
But the node_type stands for more than just an abstract RDMA device:
In IB, it designates an instance of an industry-standard, well-defined,
device type: it's possible link types, transport, semantics,
From: Doug Ledford [mailto:dledf...@redhat.com]
But the node_type stands for more than just an abstract RDMA device:
In IB, it designates an instance of an industry-standard, well-defined,
device type: it's possible link types, transport, semantics, management,
everything.
It *should* be
On 06/11/2015 02:27 PM, Liran Liss wrote:
From: Doug Ledford [mailto:dledf...@redhat.com]
OPA cannot impersonate IB; OPA node and link types have to be
designated as such. In terms of MAD processing flows, both
explicit (as in the handle_opa_smi() call below) and implicit code
paths (which
From: Doug Ledford [mailto:dledf...@redhat.com]
OPA cannot impersonate IB; OPA node and link types have to be
designated as such. In terms of MAD processing flows, both
explicit (as in the handle_opa_smi() call below) and implicit code
paths (which share IB flows - there are
cap_is_switch_smi would be a nice refinement to let us drop nodetype.
Exactly, we need a bit added to the immutable data bits, and a new cap_
helper, and then nodetype is ready to be retired. Add a bit, drop a
u8 ;-)
I agree that the node type enum isn't particularly useful and should be
On 6/11/2015 5:00 PM, Hefty, Sean wrote:
cap_is_switch_smi would be a nice refinement to let us drop nodetype.
Exactly, we need a bit added to the immutable data bits, and a new cap_
helper, and then nodetype is ready to be retired. Add a bit, drop a
u8 ;-)
I agree that the node type enum
I agree that the node type enum isn't particularly useful and should be
retired.
Are you referring to kernel space or user space or both ?
Short term, kernel space. User space needs to keep something around for
backwards compatibility.
But the in tree code will never expose this value
On 6/11/2015 7:52 PM, Hefty, Sean wrote:
I agree that the node type enum isn't particularly useful and should be
retired.
Are you referring to kernel space or user space or both ?
Short term, kernel space. User space needs to keep something around for
backwards compatibility.
But the
From: Ira Weiny ira.we...@intel.com
Hi Ira,
OPA cannot impersonate IB; OPA node and link types have to be designated as
such.
In terms of MAD processing flows, both explicit (as in the handle_opa_smi()
call below) and implicit code paths (which share IB flows - there are several
cases) must
On Wed, 2015-06-10 at 12:56 -0600, Jason Gunthorpe wrote:
On Wed, Jun 10, 2015 at 02:37:26PM -0400, Doug Ledford wrote:
On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
From: Ira Weiny ira.we...@intel.com
Hi Ira,
OPA cannot impersonate IB; OPA node and link types have to
On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
From: Ira Weiny ira.we...@intel.com
Hi Ira,
OPA cannot impersonate IB; OPA node and link types have to be designated as
such.
In terms of MAD processing flows, both explicit (as in the handle_opa_smi()
call below) and implicit code
On Wed, Jun 10, 2015 at 06:30:58AM +, Liran Liss wrote:
From: Ira Weiny ira.we...@intel.com
Hi Ira,
OPA cannot impersonate IB; OPA node and link types have to be designated as
such.
This was discussed at length and we agreed that the kernel would have explicit
capabilities
On Wed, Jun 10, 2015 at 02:37:26PM -0400, Doug Ledford wrote:
On Wed, 2015-06-10 at 06:30 +, Liran Liss wrote:
From: Ira Weiny ira.we...@intel.com
Hi Ira,
OPA cannot impersonate IB; OPA node and link types have to be
designated as such. In terms of MAD processing flows, both
Why do you have RDMA_NODE_IB_SWITCH related stuff inside the
handle_opa_smi() function?
Is there a node type of switch in OPA similar to IB?
Yes. OPA uses the same node types as IB.
Ira
No, OPA cannot impersonate IB.
It has to have distinct node and link types.
--Liran
--
To
On Wed, May 20, 2015 at 12:59:01PM -0600, Jason Gunthorpe wrote:
On Wed, May 20, 2015 at 04:13:35AM -0400, ira.we...@intel.com wrote:
@@ -433,14 +436,23 @@ static inline int get_mad_len(struct mad_rmpp_recv
*rmpp_recv)
{
struct ib_rmpp_base *rmpp_base;
int hdr_size, data_size,
Why do you have RDMA_NODE_IB_SWITCH related stuff inside the handle_opa_smi()
function?
Is there a node type of switch in OPA similar to IB?
Yes. OPA uses the same node types as IB.
Ira
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Can you please clarify:
+static enum smi_action
+handle_opa_smi(struct ib_mad_port_private *port_priv,
+ struct ib_mad_qp_info *qp_info,
+ struct ib_wc *wc,
+ int port_num,
+ struct ib_mad_private *recv,
+ struct ib_mad_private *response) {
+enum smi_forward_action
On Wed, May 20, 2015 at 04:13:35AM -0400, ira.we...@intel.com wrote:
@@ -433,14 +436,23 @@ static inline int get_mad_len(struct mad_rmpp_recv
*rmpp_recv)
{
struct ib_rmpp_base *rmpp_base;
int hdr_size, data_size, pad;
+ int opa =
23 matches
Mail list logo
