It looks good to me. Thanks, I will take it for RDMAoE.
Great... as Jason suggested, please also add in the appropriate reserved
fields to pad the struct to a 32 bit boundary and zero them in the
wrapper. So if there is a next time we don't have this problem again.
- R.
--
To unsubscribe
On Wed, Dec 09, 2009 at 11:06:41AM -0800, Roland Dreier wrote:
It looks good to me. Thanks, I will take it for RDMAoE.
Great... as Jason suggested, please also add in the appropriate reserved
fields to pad the struct to a 32 bit boundary and zero them in the
wrapper. So if there is a
On Wed, Dec 09, 2009 at 02:48:43PM -0700, Jason Gunthorpe wrote:
Also, if we really must do this, can you please send a patch to Roland
that at least adds the constants for IB, ASAP. Ideally to be included
in OFED 1.5.
At least that way people can make updates to check it prior to RDMAoE
On Fri, Dec 04, 2009 at 08:03:31PM -0800, Roland Dreier wrote:
then I think legacy apps should be OK (port_attr size doesn't change,
binary compat is still there), and new apps that do check link_layer
should also be OK ... if they use an old library and/or old driver,
they'll see
Existing apps rely on transport_type == IBV_TRANSPORT_IB to indicate
IB management is present. There are many examples of this.
The art of API compatability is to not break existing old apps, so you
don't get to change the meaning of transport_type == IBV_TRANSPORT_IB to
mean 'it is only IB
So? There are substantial semantic differences for *all* non-rdmacm
applications. Even common ones like OpenMPI. You propose to ignore them?
On the contrary! Any application that *does* care what the link layer is
can look up a new field in port_attr (rather than a new node transport
type).
'; 'Eli Cohen'; 'Jeff Squyres';
linux-rdma@vger.kernel.org
Subject: RE: RDMAoE verbs questions
Why do you say that Or?
I'm a hardware guy so can't comment on what the s/w supports/prevents,
but I can see no reason why loopback wouldn't be supported. In fact, if
I were guessing, I would guess
Paul Grun wrote:
Why do you say that Or?
I said that b/c the latest patch set posted by Mellanox doesn't support
loopback, I hear now that this was a temporal limitation which will be
removed, let it be.
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body
On Mon, Nov 30, 2009 at 09:03:47AM -0500, Jeff Squyres wrote:
Per my prior question: is it expected that IBoE will function
*exactly* the same as real IB? The addition of the port attribute
seems to imply not.
IBoE and IB should work exactly the same from the perspective of a
user level
On Mon, Nov 30, 2009 at 10:50:02AM -0800, Roland Dreier wrote:
I was thinking the same thing, although maybe a name like link_layer
would be clearer?
Sure, that's cleaer - I'll change that.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
RDMAoE *is* IB transport over Ethernet
RDMAoE carries something that looks a lot like IB L3 or an IPv6 header, so it
isn't exactly IB transport over Ethernet.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More
On Mon, Nov 30, 2009 at 02:01:45PM -0600, Todd Rimmer wrote:
If a given architecture rounds sizeof(transport) up to 16 bits or 32 bits,
then the replacement field should be uint16_t or uint32_t respectively,
otherwise existing binary applications which fetch transport will fetch
On Tue, Dec 01, 2009 at 06:22:06PM +0200, Liran Liss wrote:
Dealing with ABI compatability is a different issue, this new scheme
is API incompatible due to the change in semantics for existing values.
For rdmacm applications, there are no semantic changes between IB and
RDMAoE.
So? There
On Tue, Nov 24, 2009 at 05:11:36PM -0700, Jason Gunthorpe wrote:
On Tue, Nov 24, 2009 at 06:23:15PM -0500, Jeff Squyres wrote:
2. I am somewhat confused by the overloading of the term transport.
It appears that a device will have
ibv_device.transport_type==IBV_TRANSPORT_IB for both
Sorry -- I replied from my PDA last week but the list rejected the mail.
All I have is what was sent to the OMPI list (although I see Pasha
attached the patch in a later mail on this thread). Note that we
(OMPI) tend to operate a bit differently than OpenFabrics -- we don't
typically send
Per my prior question: is it expected that IBoE will function
*exactly* the same as real IB? The addition of the port attribute
seems to imply not.
Additionally, per Jason's question, why not simply expose this as an
additional device? E.g., can you APM across a real IB port and an
On Mon, Nov 30, 2009 at 03:34:06PM +0200, Eli Cohen wrote:
If we change struct ibv_port_attr transport field from enum to uint8,
we eliminate binary compatibility problems. That's because the previous
filed is aligned to 16 bits address so that leaves us 16 bits more.
Dealing with ABI
If we change struct ibv_port_attr transport field from enum to uint8,
we eliminate binary compatibility problems. That's because the previous
filed is aligned to 16 bits address so that leaves us 16 bits more.
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index
On Mon, Nov 30, 2009 at 10:50:02AM -0800, Roland Dreier wrote:
If we change struct ibv_port_attr transport field from enum to uint8,
we eliminate binary compatibility problems. That's because the previous
filed is aligned to 16 bits address so that leaves us 16 bits more.
diff
diff --git a/include/infiniband/verbs.h b/include/infiniband/verbs.h
index 07d4395..f7fe68d 100644
--- a/include/infiniband/verbs.h
+++ b/include/infiniband/verbs.h
@@ -192,7 +192,7 @@ struct ibv_port_attr {
uint8_t active_width;
uint8_t
Or Gerlitz wrote:
Pavel Shamis (Pasha) wrote:
The patch is attached
Thanks, this patch basically replaces checks for the device transport
type to be IB to a check that makes sure either the former happens or
the port transport type is rdmaoe. As Jason, Tziporet and noted, the
port transport
Pavel Shamis (Pasha) wrote:
The only reason for this changes is the fact that for IB devices we
prefer to use our own open mpi connection managers. In case if we will
decide to use RDMA-CM for all devices the number of changes will be zero...
whatever, currently, this change is still there,
On Nov 25, 2009, at 2:25 AM, Or Gerlitz wrote:
I was reviewing Mellanox's Open MPI patches for RDMAoE support
Can you send us point to the patch series (mail thread or some
repository where they sit)?
Here's one thread:
http://www.open-mpi.org/community/lists/devel/2009/11/7063.php
the
On Nov 24, 2009, at 11:52 PM, Jason Gunthorpe wrote:
OMPI uses RDMACM (among others), so I'm not sure I follow what
you're
asking me...?
I think I'm asking you about the non RDMACM stuff in openmpi, ibcm,
xoob, etc. I can't tell at glance if any of them will be safe to run
on RDMAoE
Jason Gunthorpe wrote:
On Tue, Nov 24, 2009 at 06:23:15PM -0500, Jeff Squyres wrote:
2. I am somewhat confused by the overloading of the term transport.
It appears that a device will have
ibv_device.transport_type==IBV_TRANSPORT_IB for both IB and RDMAOE
devices. The only way to tell
On Wed, Nov 25, 2009 at 09:30:40AM -0500, Jeff Squyres wrote:
In practice, we have seen that applications *do* need to query the
transport type -- at least (real) IB vs. iWARP. It is your
expectation that IB and IBoE will function identically?
Can you discuss the transport vs.
Jeff Squyres wrote:
Here's one thread:
http://www.open-mpi.org/community/lists/devel/2009/11/7063.php
Jeff, looking on the threads you have sent, I didn't find a way to
download the patch in a form which can be applied on a source tree, is
there a way to do it through this archive? are these
On Wed, Nov 25, 2009 at 04:41:08PM +0200, Eli Cohen wrote:
On Wed, Nov 25, 2009 at 09:30:40AM -0500, Jeff Squyres wrote:
In practice, we have seen that applications *do* need to query the
transport type -- at least (real) IB vs. iWARP. It is your
expectation that IB and IBoE will
Or,
The patch is attached.
Regards,
Pasha.
Or Gerlitz wrote:
Jeff Squyres wrote:
Here's one thread:
http://www.open-mpi.org/community/lists/devel/2009/11/7063.php
Jeff, looking on the threads you have sent, I didn't find a way to
download the patch in a form which can be applied on a source
Pavel Shamis (Pasha) wrote:
The patch is attached
Thanks, this patch basically replaces checks for the device transport
type to be IB to a check that makes sure either the former happens or
the port transport type is rdmaoe. As Jason, Tziporet and noted, the
port transport type seems to be
I was reviewing Mellanox's Open MPI patches for RDMAoE support this
afternoon and came up with the following general questions:
1. It looks like there is a new field on the ibv_port_attr struct:
transport. Is it expected that all device drivers will start filling
in this value, or is it
On Tue, Nov 24, 2009 at 06:23:15PM -0500, Jeff Squyres wrote:
2. I am somewhat confused by the overloading of the term transport.
It appears that a device will have
ibv_device.transport_type==IBV_TRANSPORT_IB for both IB and RDMAOE
devices. The only way to tell the difference is to
On Nov 24, 2009, at 7:11 PM, Jason Gunthorpe wrote:
Is the same true for openmpi? If you try to run it as is on a RDMAOE
interface will it work? If not I think that alone should kill this
idea..
OMPI uses RDMACM (among others), so I'm not sure I follow what you're
asking me...?
The
On Tue, Nov 24, 2009 at 09:12:53PM -0500, Jeff Squyres wrote:
On Nov 24, 2009, at 7:11 PM, Jason Gunthorpe wrote:
Is the same true for openmpi? If you try to run it as is on a RDMAOE
interface will it work? If not I think that alone should kill this
idea..
OMPI uses RDMACM (among
Jeff Squyres wrote:
I was reviewing Mellanox's Open MPI patches for RDMAoE support
Hi Jeff,
Can you send us point to the patch series (mail thread or some
repository where they sit)?
1. It looks like there is a new field on the ibv_port_attr struct:
transport. Is it expected that all
35 matches
Mail list logo
