> This patchset is a proposal to create new API's and data structures with
> transport neutral names.
We named ourselves OpenFabrics instead of OpenRDMA for a reason, did I
miss some point where we decided that we would use RDMA as a transport
neutral name in the source code?
-- greg
__
Tziporet Koren wrote:
> Hi all,
>
> This is the outcome of the meeting we had today regarding OFED 1.1
> schedule and features.
>
>
>
>
Can we include librdmacm and dapl in the basic installation option?
Also, it would be nice to have rdma_ucm and rdma_cm load on boot by
default.
Thanks,
-a
Thanks, applied.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
OK, I applied these patches.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> This is an oversight. It will be fixed in the next major version of the
> LSI Logic Storage controller firmware. The OUI after the fix will be
> A0B8.
OK great. So let's respin this patch so it defaults on but only
triggers for targets with the Mellanox OUI -- that will catch current
LSI ta
you're right...its friday... ;-)
On Fri, 2006-07-28 at 13:21 -0700, Roland Dreier wrote:
> Steve> Uh, won't that break binary compatibility? Or is that not
> Steve> a requirement? IE: If you make the ibv_* names #defines,
> Steve> then all apps will have to recompile to use the ne
Steve> Uh, won't that break binary compatibility? Or is that not
Steve> a requirement? IE: If you make the ibv_* names #defines,
Steve> then all apps will have to recompile to use the new lib.
Steve> If you leave them as the real names, then apps can still
Steve> link to the n
On Fri, 2006-07-28 at 12:27 -0700, Roland Dreier wrote:
> > Why not just do:
> >
> > #define rdma_structure_name ibv_structure_name
> >
> > Then we simply remove the #define and replace ibv_structure_name with
> > rdma_structure_name when ready. This better shows the changes, prevents
>
> I realize why you did this, but adding the 'v' to these two calls makes them
> inconsistent with all the other calls in the API. I don't know what the
> right
> approach is here, but it may be better to have the RDMA CM use different
> names.
Maybe the best approach is to use rdmav_ to
> From: Sean Hefty
>
> Michael S. Tsirkin wrote:
> > Neither am I, but still I'm a bit uncomfortable - after all,
> > the spec explicitly says:
> >
> > "it should be pointed out that successful reception of the final
message
> > in a CM protocol message exchange cannot be guaranteed."
>
> The pat
> Why not just do:
>
> #define rdma_structure_name ibv_structure_name
>
> Then we simply remove the #define and replace ibv_structure_name with
> rdma_structure_name when ready. This better shows the changes, prevents
> duplicating every structure, and should avoid any compile warnings.
Michael S. Tsirkin wrote:
> Neither am I, but still I'm a bit uncomfortable - after all,
> the spec explicitly says:
>
> "it should be pointed out that successful reception of the final message
> in a CM protocol message exchange cannot be guaranteed."
The patch handles this by routing the commun
This is an oversight. It will be fixed in the next major version of the
LSI Logic Storage controller firmware. The OUI after the fix will be
A0B8.
Timothy Snider
Storage Architect
Strategic Planning, Technology and Architecture
LSI Logic Corporation
3718 North Rock Road
Wichita, KS 67226
(316) 6
Rimmer, Todd wrote:
>> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
>>
>> That assumes that there is any valid reason for an application to
>> post send requests before the connection is established. While there
>> is clearly a need to post receive work requests before the
>> connection is esta
---
drivers/infiniband/core/addr.c | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index d294bbc..1205e80 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/
Generate netevents for:
- neighbour changes
- routing redirects
- pmtu changes
---
net/core/Makefile|2 +-
net/core/neighbour.c | 14 --
net/ipv4/route.c |8
net/ipv6/route.c |7 +++
4 files changed, 24 insertions(+), 7 deletions(-)
diff --git
This patch uses notifier blocks to implement a network event
notifier mechanism.
Clients register their callback function by calling
register_netevent_notifier() like this:
static struct notifier_block nb = {
.notifier_call = my_callback_func
};
...
register_netevent_notifier(&nb);
---
Dave/Roland, is this patchset about ready to go?
Round 5 Changes:
- removed user-mode support
- removed route add/del events.
--
This patch implements a mechanism that allows interested clients to
register for notification of certain network events. The intended use
is to allow RDMA device
These changes look fine.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
These changes look fine. We just need to decide if we want to change
everything
that's ibv_* to rdma_*, or keep IB specific names (path records, GIDs, PKeys,
etc.) the same.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://ope
Krishna Kumar wrote:
> struct ucma_abi_query_route_resp {
> __u64 node_guid;
> - struct ibv_kern_path_rec ib_route[2];
> + struct rdma_kern_path_rec ib_route[2];
Path records are IB specific. Not sure we need to rename them.
> struct ib_addr {
> - union ibv_gid sgid;
> -
Krishna Kumar wrote:
> +/**
> + * rdmav_create_qp - Create a queue pair.
> + */
> +struct rdma_qp *rdmav_create_qp(struct rdma_pd *pd,
> +struct rdma_qp_init_attr *qp_init_attr);
> +
> +/**
> + * rdmav_destroy_qp - Destroy a queue pair.
> + */
> +int rdmav_destroy_qp(st
Krishna Kumar wrote:
> +struct rdma_kern_async_event {
Why not just do:
#define rdma_structure_name ibv_structure_name
Then we simply remove the #define and replace ibv_structure_name with
rdma_structure_name when ready. This better shows the changes, prevents
duplicating every structure, and
Kanevsky, Arkady wrote:
> If a QP is not in the RTS state then Send post should
> be flushed to CQ for IB.
> This fact need to be preserved so ULP can ensure that
> for Completion Suppression Sends have been completed.
Sends posted when in the RTR state result in an immediate error. No work
comp
> From: Rimmer, Todd
>
> > From: Sean Hefty [mailto:[EMAIL PROTECTED]
> >
> > >That assumes that there is any valid reason for an application to
> > >post send requests before the connection is established. While
there
> > >is clearly a need to post receive work requests before the
connection
> >
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
>
> That assumes that there is any valid reason for an application to
> post send requests before the connection is established. While there
> is clearly a need to post receive work requests before the connection
> is established I cannot think of
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
>
> >That assumes that there is any valid reason for an application to
> >post send requests before the connection is established. While there
> >is clearly a need to post receive work requests before the connection
> >is established I cannot think of a
If a QP is not in the RTS state then Send post should
be flushed to CQ for IB.
This fact need to be preserved so ULP can ensure that
for Completion Suppression Sends have been completed.
Thanks,
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. ph
Dear Sir,
what's your progress on sdp connection? I'm waiting
for the new release to test.
tks
zhu
--- Tziporet Koren <[EMAIL PROTECTED]> wrote:
> zhu shi song wrote:
> > I'm sorry SDP is not in production state. SDP is
> very
> > important for our application and we are waiting
> it
> >
29 matches
Mail list logo
