Brian Long wrote:
How much overhead is going to be incurred by using a standard RDBMS
instead of not caching anything? I'm not completely familiar with the
IB configurations that would benefit from the proposed SA cache, but it
seems to me, adding a RDBMS to anything as fast as IB would
Brian Long wrote:
What about SQLite (http://www.sqlite.org/)? This is used by yum 2.4 in
Fedora Core and other distributions.
SQLite is a small C library that implements a self-contained,
embeddable, zero-configuration SQL database engine.
Someone else sent me a link to this same site, and
Eitan Zahavi wrote:
The issue is the number of queries grow by N^2.
I understand.
On a related note, why does every instance of the application need to query for
every other instance? To establish all-to-all communication, couldn't instance
X only initiate connections to instances X?
Rimmer, Todd wrote:
1 million entry SA database.
This is exactly why I think that the SA needs to be backed by a real DBMS.
In contrast the replica on each node only needs to handle O(N) entries.
And its lookup time could be O(logN).
This is still O(NlogN) operations, which made me look at
Eitan Zahavi wrote:
[EZ] MPI opens a connection from each node to every other node. Actually
even from every CPU to every other CPU. So this is why we have N^2
connections.
I was confusing myself. I think that there are n(n-1)/2 connections, but that's
still O(n^2).
- Sean
Rimmer, Todd wrote:
Each MPI process is independent. However they all need to get pathrecords
for all the other processes/nodes in the system.
Hence, each process on a node will make the exact same set of queries.
That should still only be P queries per node, with P = number of processes on a
Rimmer, Todd wrote:
While each process could do a GET_TABLE for all path records that
would be rather inefficient and would provide 1,000,000 path records in
the RMPP response, of which only 500 are of interest.
Each process could do a GET_TABLE for only those path records with the SGID set
Ralph Campbell wrote:
struct ib_mad_send_buf * ib_create_send_mad(struct ib_mad_agent *mad_agent,
u32 remote_qpn, u16 pkey_index,
- int rmpp_active,
+ int rmpp_active,
Eitan Zahavi wrote:
[EZ] The scalability issues we see today are what I most worry about.
I think that we have a couple scalability issues at the core of this problem. I
think that a cache can solve part of the problem, but to fully address the
issues, we eventually may need to extend our
Eitan Zahavi wrote:
[EZ] Having N^2 messages is not a big problem if they do not all go one
target...
CM is distributed and this is good. Only the PathRecord section of the
connection establishment is going today to one node (SA) and you are
about to fix it...
I expect that we'll start
The following set of patches defines a connection abstraction for Infiniband and
other RDMA devices, and serves several purposes:
* It implements a connection protocol over Infiniband based on IP addressing.
This greatly simplifies clients wishing to establish connections over
Infiniband.
* It
The following patch provides common handling for marshalling data between
userspace clients and kernel mode Infiniband drivers.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cm.c
linux-2.6.ib/drivers/infiniband/core
The following provides an address translation service that maps IP addresses
to Infiniband addresses (GIDs) using IPoIB.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/addr.c
linux-2.6.ib/drivers
on behalf of clients.
- Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cma.c
linux-2.6.ib/drivers/infiniband/core/cma.c
--- linux-2.6.git/drivers/infiniband/core/cma.c 1969-12-31 16:00:00.0
-0800
This patch adds the kernel component to support the userspace Infiniband/RDMA
connection agent library.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drivers/infiniband/core
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
static void cm_mask_compare_data(u8 *dst, const u8 *src, u8 *mask)
but I would rename it to cm_mask_copy since it doesn't really do a compare.
I'll change this. The function is masking the data to use in the comparison,
but I can
Jack Morgenstein wrote:
Prevent multiple outstanding MAD transactions with the same TID.
Could happen if duplicate requests are posted.
This is an issue only for a single client, so I think that each client should be
responsible for handling this.
- Sean
James Lentini wrote:
The CMA appears to assume that a struct sockaddr_in's sin_port value
will be in host byte order. This is incorrect.
Thanks - I'm fairly certain that the CMA will need some updates before final
acceptance into the kernel. I'll add this in beforehand.
- Sean
Grant Grundler wrote:
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] mask[i];
+}
Is this code going to get invoked very often?
In practice, it would be invoked
Grant Grundler wrote:
Is this code going to get invoked very often?
In practice, it would be invoked when matching any listen requests
originating from the CMA (RDMA connection abstraction).
hrm..I'm not sure how to translate your answer into a workload.
e.g. which netperf or netpipe test
Roland Dreier wrote:
+ UCMA_MAX_BACKLOG= 128
Is there any reason that we might want to make this a tunable? Maybe
as a module parameter that's writable in sysfs...
There's no reason not to make this tunable.
- Sean
___
openib-general
Tom Tucker wrote:
enum ib_device_cap_flags {
@@ -86,6 +87,14 @@
IB_DEVICE_RC_RNR_NAK_GEN= (112),
IB_DEVICE_SRQ_RESIZE= (113),
IB_DEVICE_N_NOTIFY_CQ = (114),
+ IB_DEVICE_IN_ORD_PLCMNT = (115),
+ IB_DEVICE_ZERO_STAG
Devesh Sharma wrote:
I have some queries regarding the significance of the function
ib_register_mad_agent()
A) What this function dose?
B) What is the significance of this function in implementing HCA driver?
I didn't see a response to this.
This function permits a client to send and receive
Tom Tucker wrote:
Enclosed is a combined include file and core patch for iWARP support in CMA. This
patch includes changes per your last review.
Unless anyone has an objection, I will commit these changes within the next day
or so.
- Sean
___
Or Gerlitz wrote:
Sean, when you commit this change please change ulp/iser/iser_socket.c
since this code indeed sets it for the CMA in host order (it is htons
on something which is network order... confusing, anyway you will
delete it).
Thanks - committed.
- Sean
Tom Tucker wrote:
Enclosed is a combined include file and core patch for iWARP support in CMA. This
patch includes changes per your last review.
It was brought up that there's still not an iWarp driver in the OpenIB trunk.
Is one ready to be merged? Thinking about this more, I'm not sure
Eric W. Biederman wrote:
No. If you're running a full IB stack, we provide the usual IB subnet
management facilities, and you can run OpenSM to manage your subnet. If
you're *not*, which is the case I'm concerned with here, it makes no
sense to replicate the byzantine IB management interfaces
Bryan O'Sullivan wrote:
the dual license text needs a bit of clarification I suspect to make
explicit that the or BSD part only applies when used entirely outside
the linux kernel. (that already is the case, just it's not explicit.
Making that explicit would be good).
One appropriate way to do
Tom Tucker wrote:
3. Getting the core support in early will give us time to tweak, tune,
and test. I think this is a very good thing.
I'm not disagreeing, but my concern is that if we start applying changes to the
trunk to support branches we can end up maintaining a large amount of code that
Bryan O'Sullivan wrote:
At least one kernel developer has asked me privately to get the
boilerplate language on source files clarified, to make it clear that
the dual BSD/GPL licensing is GPL-only for the Linux kernel, and the
user's choice of either in other cases.
Here was the suggestion
Bryan O'Sullivan wrote:
Our lowest-level driver works in the absence of any IB support being
compiled into the kernel, so in that situation, there are no QPs or any
other management infrastructure present at all. All of that stuff lives
in a higher layer, in which situation the cut-down subnet
Bryan O'Sullivan wrote:
We are not really in the RDMA camp. Our facility looks more like when
this kind of message comes in, be sure that it shows up at this point in
my address space, which does not match RDMA semantics.
A lot of people mean QP-like semantics when they talk about RDMA,
1. What usermode tools should I use if I want to use the modules that
are part of the current kernels (e.g. Fedora). The OpenIB subversion
code, the IBGD stuff or something else.
Not sure what IBGD is. The OpenIB svn code matches with that shipping in the
current kernels.
2. Is there any reason
Just so I understand. When you say 'svn code matches' it means a) the
kernel modules are the same (or close enough). b) the usermode stuff
will/should work without a problem. Could you be a little more specific?
Just curious how this works until things stabilize more.
The IB code included in
Devesh Sharma wrote:
In mad.c while calling ib_post_receive() operation
spin_lock_irqsave(recv_queue-lock, flags);
post = (++recv_queue-count recv_queue-max_active);
list_add_tail(mad_priv-header.mad_list.list, recv_queue-list);
Tom Tucker wrote:
Enclosed is a combined include file and core patch for iWARP support in CMA. This
patch includes changes per your last review.
I applied the portion of your patch that modifies the CMA to use a union to
store the underlying cm_id's, with a couple of changes - see below.
I
Steve Wise wrote:
Is it possible to just go ahead and push the core iwarp stuff into
kernel.org?
I don't think that makes sense or would be accepted. This would be asking for
changes to the kernel code that nothing else in the kernel would use.
- Sean
Tom Tucker wrote:
Phases I and II are complete in the branch, were demonstrated at SC'05,
and have now been submitted as a patch to the trunk.
To add to this, the patch makes fairly minor changes (a couple to only a few
lines) to ib_verbs, ib_mad, ib_addr, and ib_cm. Some work was done to
Steve Wise wrote:
I think I found a bug in rdma_connect(). Shouldn't it bump the
rdma_cm_id refcnt before calling down into the transport-specific CM to
inititiate a connect? Then deref it in the callback function.
The case I'm thinking about is if an ib_client does and rdma_connect(),
Does anyone know if OpenSM (or any SM) includes path records where the DGID=SGID
when responding to a GET_TABLE request?
The fields being set in the request are SGID, NumbPath, and PKey.
- Sean
___
openib-general mailing list
openib-general@openib.org
How important is this? Should I queue it for 2.6.16, or can it wait
for 2.6.17 to open?
It's a compliance issue, but the fact that the code has gone this long without
hitting an issue probably means that it can wait.
The RMPP code actually checks the active flag before checking the version,
Hal Rosenstock wrote:
Yes, loopback paths should be returned. I did a totally wildcard query
and they are returned. Are you just asking or is there some issue with
this ?
My testing of the caching code wasn't failing in the location that I expected
when attempting loopback connections. (I
Hal Rosenstock wrote:
I didn't do the exact query you mentioned but a get all PathRecords
returned a loopback path in the very first record. Wouldn't madeye at
least print out some headers and some hex ? I could verify from that if
you want.
I'll spend some time debugging this first. I
Sean Hefty wrote:
The RMPP code actually checks the active flag before checking the version, which
is wrong, but why this has gone undetected.
On second thought, and checking the spec in more detail...
o13-21.1.3: States that if Active=0, all other fields shall be reserved.
and
o13-21.1.4
Arlin Davis wrote:
This is exactly why immediate data was initially proposed as an
extension instead of general API. We start to penalize native IB
features based on the requirements of other RDMA interfaces that have to
emulate the feature anyway. What prevents the next RDMA interface that
Kanevsky, Arkady wrote:
But this penalizes user which need to deal with 2 way to deal
with post calls and completions.
Yes, any app that wants to take advantage of transport specific features, which
immediate data is, is no longer transport neutral.
How do you plan to handle the next RDMA
Expose functions to pack/unpack SA attributes. This capability is
also required by the local SA database.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: core/sa_query.c
===
--- core/sa_query.c (revision 5098)
+++ core
Add a fast indexing service that permits quick insertion, removal, and
retrieval of data items using a key.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: core/index.c
===
--- core/index.c(revision 0)
+++ core
Modify the CMA to use the local SA database for path record lookups.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Index: core/cma.c
===
--- core/cma.c (revision 5115)
+++ core/cma.c (working copy)
@@ -34,7 +34,7 @@
#include rdma
footprint, registering the local SA database to receive SA events, and failing
over from the local SA database to using SA queries.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman
Roland Dreier wrote:
This probably doesn't belong under drivers/infiniband, since it's
completely generic. How close are the existing rbtree, radix tree and
idr libraries to what you need? It might be better to slightly extend
an existing kernel library rather than creating yet another API...
James Lentini wrote:
enum ib_node_type {
- IB_NODE_CA = 1,
+ IB_NODE_IB = 0x10, /* mask for all IB node types */
Is is time to update the prefix to RDMA_ (e.g. RDMA_NODE_IB)?
Probably. I used IB_NODE_IB, under the assumption that it would be renamed to
how it would be used. If this is okay, then similar changes
would be needed by a dozen or so other files, which I would do before
submitting a final patch.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Index: include/rdma/ib_verbs.h
Roland Dreier wrote:
enum ib_node_type {
- IB_NODE_CA = 1,
+ IB_NODE_IB = 0x10, /* mask for all IB node types */
+ IB_NODE_CA,
IB_NODE_SWITCH,
IB_NODE_ROUTER
};
Is there anywhere that uses this value to compare against the values
that the IB spec uses in
Sean Hefty wrote:
rbtree can work, but would be less performant. Idr doesn't work for
this purpose. I didn't realize that there was a radix tree available,
so I'll see if that will work.
The radix tree implementation that's available uses an unsigned long for its
index key. For path
Sean Hefty wrote:
I didn't notice anything that assumed the values assigned to the enum
members, but I can think of several reasons how I would miss that. I
guess an easy sanity check is to change the value assigned to IB_NODE_CA
and see if anything stops working.
I changed the value
Michael S. Tsirkin wrote:
Wouldnt a simple helper function be sufficient?
I thought about this, but it seemed like there should be a better approach.
enum ib_node_type {
Flags as enums, hmm.
We can drop the name on the enum.
I think this changes the ABI, so its somewhat problematic.
A
Steve Wise wrote:
I can provide a patch for this soon, but I'd rather get the current CMA
changes into the trunk, then post a delta patch from the trunk...
Regarding this, I'm trying to identify each of the individual changes to the
trunk in the CMA patch, discuss the effect of the change,
Hal Rosenstock wrote:
This looks like a wildcarded DGID request but NumbPaths is 1. Am I
missing something ?
This is correct. The cache is only retrieving a single path to each destination
from a given port. NumbPaths is required for a GetTable request.
Supporting multiple paths between
Or Gerlitz wrote:
- the ib_get_path_rec api does not seem to allow its consumer to specify
a callback to be called when there is no path in the cache
- the ib_get_path_rec seems to only look in the index and return path
only if there is cached one.
So is it an incomplete implementation just
Here's an updated version of the patch that doesn't break the ABI.
Note that for RNICs, node_type would be set to IB_NODE_IWARP | IB_NODE_CA.
Comments?
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: ib_verbs.h
Steve Wise wrote:
I agree. However, the question is how to find the associated openib
device once you determine which netdev device you are using for the next
hop. In the existing IB CMA code, this is done by a linear search
through the ib devices and finding a device that has the gid
Steve Wise wrote:
I'm running the kernel cmatose. The server side gets a connect request,
but the init_node() returns an error because the qp create fails. The
cmatose module then rejects the connect request on that connect request
upcall. Concurrently (on the main work thread running
Tom Tucker wrote:
+/* Handles an inbound connect request. The function creates a new
+ * iw_cm_id to represent the new connection and inherits the client
+ * callback function and other attributes from the listening parent.
+ *
+ * The work item contains a pointer to the listen_cm_id and the
Sean Hefty wrote:
Expose functions to pack/unpack SA attributes. This capability is
also required by the local SA database.
Roland, any objection to committing this change to sa_query?
I can also move index.h into include/rdma/linux subdirectory to clarify that it
is not IB specific code
Sean Hefty wrote:
I can also move index.h into include/rdma/linux subdirectory to clarify
that it is not IB specific code.
Er... I meant include/linux.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo
amith rajith mamidala wrote:
qp_attr.port_num = 0;
Try port_num = 1.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
The following patch extends the node_type associated with an ib_device
to support iWarp without breaking the ABI. Comments on this approach?
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: ulp/ipoib/ipoib_main.c
===
--- ulp
Roland Dreier wrote:
That's still silly. I wasn't very clear in my original email. But my
point was that if a function does
if ((device-node_type IB_NODE_IB) != IB_NODE_IB)
return;
then we should just write tests like
if (device-node_type == IB_NODE_SWITCH)
Grant Grundler wrote:
If node_type were a bitmask mask, I'd expect
if (node_type (IB_NODE_IB | IB_NODE_SWITCH))
This would be true if node_type = IB_NODE_IB | IB_NODE_CA. Okay, if the check
for IB_NODE_IB is there, I think that all that's needed is:
if (node_type IB_NODE_SWITCH)
Michael S. Tsirkin wrote:
The cache is updated every 15 minutes, but this value is user configurable at
module load time. The cache is also updated if a local event occurs, such as
port up/down or SM LID change.
Unfortunately port down on any link in the path has the same effect
but wont
Michael S. Tsirkin wrote:
BTW, just moving poll_cq and req_notify_cq to struct ib_cq will already remove
one indirection level from the datapath. And this can be done without touching
low-level drivers.
Same for QP and various ib_post callbacks.
Should I submit such a patch? Sean?
Are you
Hal Rosenstock wrote:
Ultimately, this should likely be using MultiPathRecord as it is able to
do some things PathRecords can't.
Can you elaborate on this?
- Sean
___
openib-general mailing list
openib-general@openib.org
Hal Rosenstock wrote:
It's able to choose SGID and/or DGID as explicit GIDs, GIDs from same
node or GIDs from same system, request multiple SGID/DGID pairs in one
request, and request varying path independence (as fault tolerant as
possible or not).
I see where a MultiPathRecord contains a
Sean Hefty wrote:
Here's an updated version that actually does the device checks correctly, and
hopefully clarifies how node_type is formatted. I include two helper functions
to extract the transport and device information from the node_type.
I tried to include related changes to all files
Hal Rosenstock wrote:
I see where a MultiPathRecord contains a path independence field. But since it
only provides a single value for all other PathRecord fields for all SGID/DGID
pairs, it seems less flexible than PathRecords.
It depends on whether those components are wildcarded or not.
Hal Rosenstock wrote:
The query response is PathRecords not MultiPathRecords.
Okay - this is what I was missing. It makes a whole lot more sense now.
Thanks.
- Sean
___
openib-general mailing list
openib-general@openib.org
Here's an updated version of the patch based on Roland's comments.
Patch includes updates to mthca, ipath, and ehca drivers.
I did not update any userspace verbs support code.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: ulp/ipoib/ipoib_main.c
I have now instrumented iser code to always call rdma_disconnect /
rdma_destory_qp etc from sleepable context. Before doing so i was
getting
this oops few times. My interpertation was that cma_modify_qp_err is
not supposted to get called when in_atomic is true, am i correct?
It looks like this
Aren't we creating a monster here??? if this is SA replica which should
work for scale from day one, lets call it this way and see how to reach
there.
The cache update window is configurable. What we don't know is how
often the SA would be queried to establish connections without a local
cache
How about either having a mod param to the local SA practically telling
it to do nothing (ugly) or the local SA doing symbol_put to the cache
query function and the CMA attempting to symbol_get it, if the symbol
exists, then the CMA is first trying the cache before querying the SA,
or whatever
Here's an updated version of these patches based on feedback. (The license
did not change and continues to match that of the other Infiniband code.)
Please consider for inclusion in 2.6.17.
The following set of patches defines a connection abstraction for Infiniband and
other RDMA devices, and
The following provides an address translation service that maps IP addresses
to Infiniband addresses (GIDs) using IPoIB.
This patch exports ip_dev_find() to locate a net_device given an IP address.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation
on behalf of clients.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cma.c
linux-2.6.ib/drivers/infiniband/core/cma.c
--- linux-2.6.git/drivers/infiniband/core/cma.c 1969-12-31 16:00:00.0
-0800
This patch adds the kernel component to support the userspace Infiniband/RDMA
connection agent library.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drivers/infiniband/core
enum ib_device_cap_flags {
@@ -86,6 +87,14 @@
IB_DEVICE_RC_RNR_NAK_GEN= (112),
IB_DEVICE_SRQ_RESIZE= (113),
IB_DEVICE_N_NOTIFY_CQ = (114),
+ IB_DEVICE_IN_ORD_PLCMNT = (115),
+ IB_DEVICE_ZERO_STAG = (116),
+
Or is it just me? I see even trivial stuff like
svn ls https://openib.org/svn
just hanging.
An svn update just worked for me.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
Update madeye for changes for rdma_node_type and use utility function
to
check the transport type based on the node type.
I had updates to the util directory that I forgot to commit. I just
committed them.
- Sean
___
openib-general mailing list
Or Gerlitz wrote:
I recall that SilverStorm mentioned they had a well working SA replica,
but when i look on the naked math for 1k nodes and the hard to reach in
real life uniform distribution of queries over time, i really can't see
how to reach it unless you practically never update the
Or Gerlitz wrote:
I think we really need to have in the very short term some solution at
hand which effectively allows for both the cma being used and the local
SA not replicating the SA.
This is since the trunk is used in various environments, currently most
of them are not all-to-all MPI
important when
multicast tracking is added to the local SA module.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
I'm not sure if this is an appropriate way of doing this, but it worked in
my testing.
Index: core/local_sa.c
===
--- core
Here is an updated immediate data proposal
based on the latest discussions. I am working on a patch.
I dont see any app using this unless immediate data
is supported, and the data shows up in a completion.
You have variables to indicate support, the number of work
requests
This is a good goal but the implementation looks way too crazy. Can
we revamp the API to the SA so that this symbol chicanery isn't
required? Maybe have an SA core that the cache registers itself with
when it's loaded?
It's probably not even worth it long term. I was planning on using the
Davis, Arlin R wrote:
“Applications need an optimized mechanism to notify the receiving end
that RDMA write data has completed beyond the two operation method
currently used (RDMA write followed by message send). This new RDMA
write feature will support 4-bytes of inline data that will be sent
But the remote side does posts Recv. Since it anticipate that
this Recv will be matched against the RDMA Write with immediate
it posts the recv buffer which fits. Yes, there is an issue
for Transport-independent ULP that it does needs a buffer.
For IB it is possible to post 0-size buffer. But if
I would think an array of pointers and a count to standard work requests
would do it. And of course, each work request can control whether is
solicits a completion so a write/send sequence can generate a single
completion event on both ends. Use the EVD lock to guard against other
threads
And further it is only on the receiving side.
And only if the receiving side cares about the data
(sometimes it only needs the notification).
The send size cares about this check because it must size its SQ appropriately.
I disagree with the assumption that a
Why would any Consumer hook itself on proprietary features and
APIs is a different question.
Because it provides a real performance benefit. This is the same reason apps
code to DAPL versus standard sockets.
- Sean
___
openib-general mailing list
Based on what you've done, I'd like to suggest changing interface similar to
that shown below. I believe that this could be done with minor changes to the
current patches. Detailed comments that led to suggesting this change are
inline in my responses.
struct ib_mad_segments {
u32
901 - 1000 of 2277 matches
Mail list logo
