Steve Wise wrote:
The Chelsio RNIC has this issue. If the server sends the first FPDU
_before_ the client driver has moved the connection/qp into RDMA mode,
then the data is placed as streaming data and the connection must be
terminated (dapltest 6 exposes this intermittently). Ammasso doesn't
received, the connection will be aborted. This will
result in sending a consumer REJ message when the cm_id is
destroyed.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]
---
Michael, can you test this against SDP? This patch should address
CA4-15, 17, and 22. CA4-43 is handled automatically by the
Today, a request MAD received by the MAD layer is handed to a client. The
client processes the MAD, and generates a response. If the client is slow to
process the MAD, the request may have been resent. The duplicate request is
also handed to the client. The result is that clients perform duplic
Sean Hefty wrote:
I'd like to propose that the MAD layer detect duplicate requests. After a
request MAD has been handed to a client, its context would be maintained until
the user calls ib_free_recv_mad(), allowing duplicate requests to be discarded.
I should add that this also pro
>+static int iser_free_device_ib_res(struct iser_device *device)
>+{
>+ BUG_ON(device->mr == NULL);
>+
>+ tasklet_kill(&device->cq_tasklet);
>+
>+ (void)ib_dereg_mr(device->mr);
>+ (void)ib_destroy_cq(device->cq);
>+ (void)ib_dealloc_pd(device->pd);
>+
>+ device->mr =
>You can't add this kind of thing piecemeal to a protocol and have it
>work. If the sender doesn't see a response (perhaps the response was
>lost, or was slow coming), and sends another MAD, this 2nd MAD will
>have a different sequence number. How does the recipient know it's the
If a MAD is sent
>> >Check GID/LID for requester side when searching for request which matches
>> >received response. This, in order to guarantee uniqueness if use same TID
>> >when requesting via multiple source LIDs (when LMC is not zero). To perform
>> >check, add LMC to cache.
>> >
>> >Further, do not perform
>I understand that this is along the lines of the approach poposed by Jack a
>while ago:
>
>https://openib.org/svn/trunk/contrib/mellanox/gen2/patches/mad_rmpp_requester_r
>etry.patch
>
>with the difference that duplicate request detection will be handled by full
>GID/TID/class/request/response mat
>Can a ULP assume that cma callbacks for to the same CMA ID
>are serialized?
Yes. (This is required to avoid reporting events out of order to the user.)
>Also and related to this, is it correct that ***always** before
>DISCONNECTED event there will be one of {ESTABLISHED, REJECTED,
>CONNECT_ERRO
>> There is a real issue that is seen when a duplicate request (same TID, SGID,
>> mgmt class) is received at the client, resulting in a duplicate response.
>
>You had mentioned in the previous email on this that this was the case
>of a slow responder. Is the responder slow but playing by the IB
>t
>There's still a window here depending on when free MAD is called versus
>when the response gets back to the original requester.
There are no issues in this case. We just need to avoid having two responses
being sent at the same time.
>> but I'm not sure if this would happen in practice. A
>>
>Aren't there 3 cases possible here: (1) non RMPP request/RMPP response
>(e.g. SA GetTable for one), (2) RMPP request/RMPP response (e.g. SA
>GetMulti), and (3) RMPP request/non RMPP response (I don't think this
>currently exists but may be mistaken). Are all handled on the
>initiator/requester sid
>Why is the requester resending ?
He's simply timed out waiting for a response. For instance, if this is an SA
query, maybe the SA is swamped with requests. I don't think that there are any
timeout restrictions for this.
- Sean
___
openib-general mail
>It needs to fail in a way so that it is not retried, right ?
The ib_post_send_mad() call will fail. Since the first response removed the
request from the list to check, subsequent retries will also fail.
Basically, this prevents a user from sending a response MAD unless it had
previously receiv
>Rds uses RDMA_PS_UDP.
>Here is a patch to add that.
I thought that RDS established a connection. (Maybe it should be called a
channel multiplexing service?)
I don't think that we want to use the RDMA UDP port space for connected QPs.
That should be reserved for UD QPs.
Can't RDS sit over the T
>I see, so just to make sure: following rmda_connect i will get always
>see one of {ESTABLISHED, REJECTED, CONNECT_ERROR} ?
Or DEVICE_REMOVAL, but those are the typical callbacks.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://o
>> And I don't believe that case 3 exists either, but would end up being treated
>as
>> DS RMPP by the implementation.
>
>Why ? Just wondering...
>
>> If case 3 doesn't exist, then I think we can
>> come up with a generic way to identify DS RMPP that doesn't require checking
>> class or methods.
>
>It probably would be better to commit it as a separate patch -- one
>idea per patch."
>
>so I understand he's fine with it, and the comment was with regard to
>how to commit this - first core files, then MAD files.
>
>Anyway, its trivial to split the patch, if you want help with that let me know.
>Agreed... as an interface to userspace, get/set opt makes sense, but
>inside the kernel you just end up with a dispatch function that
>demultiplexes things to the real work. So I think the real work
>functions should be the kernel API.
The dispatch function would still be there for userspace, bu
Roland Dreier wrote:
I thought that after the DREP is received, the CM will go through
timewait and we will eventually get a TIMEWAIT_EXIT event (with a
completion). Am I wrong? Have you actually seen this deadlock happen
in practice?
This should be the case. TIMEWAIT_EXIT should follow DREP
Michael S. Tsirkin wrote:
Add LMC cache.
Committed - thanks!
___
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
Applied - thanks.
- 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
Hal Rosenstock wrote:
It could have been done the other way 'round as well with the new SDP on
a new branch as other ULPs have done prior to being ready for the trunk
and all the same goals that you mention accomplished.
I agree with Hal. If there was a good chance that the code was more stabl
Or Gerlitz wrote:
changed iser ib conn state management to be done with an int variable
keeping the state and a lock. When a related race is possible the lock is
used to check (comp) or change (comp_exch) the state. When no race can
happen the state is just examined or changed.
These look fin
Moving discussion to list.
Hal Rosenstock wrote:
MPR does allow for better selection of paths for APM though.
Beyond adding the Independence Selector, does MPR add anything else?
I assume that the Independence Selector works when paths between multiple GIDs
are requested. Have you thought a
Hal Rosenstock wrote:
To me, this feature seems most useful for all-to-all type connections, but would
require some sort of coordination between connecting end-points in order to have
fault independent connections between different nodes. E.g. the connection from
A to B is independent from the
Hal Rosenstock wrote:
I'm just trying to determine how an implementation can make use of MPR to
understand the best way to expose it. The use of MPR over just path records
seems complex.
In terms of what ?
To be clear, that wasn't a criticism, just a statement that MPR provides
additional
Hal Rosenstock wrote:
that I'm not sure we can provide value beyond basic MAD support.
By that do you mean expose the PRs returned ?
That along with exposing the details of the query use to obtain the path
records.
I'm wondering if we can come up with a sensible abstraction for path records
being established.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: core/ucma.c
===
--- core/ucma.c (revision 6884)
+++ core/ucma.c (working copy)
@@ -41,6 +41,8 @@
#include
#include
+#include "ucma_ib.h"
Add routines to the userspace RDMA CM library to get/set transport
specific options.
Add an option to retrieve possible path records for a connection, and
set which path a connection will be established on.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: include/rdma/rdma_cma
This patch series has been committed.
- 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
different threads to process events for different rdma_cm_id's.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: src/cma.c
===
--- src/cma.c (revision 6950)
+++ src/cma.c (working copy)
@@ -120,7 +120,6 @@ static s
Update test programs to use the event channel interfaces.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: examples/rping.c
===
--- examples/rping.c(revision 5693)
+++ examples/rping.c(working copy)
@@ -141,6
>cm_process_work does:
>
>cm_deref_id(cm_id_priv);
>if (ret)
>ib_destroy_cm_id(&cm_id_priv->id);
>
>assume that another thread calls ib_destroy_cm_id.
>Now
>
>wait_event(cm_id_priv->wait, !atomic_read(&cm_id_priv->refcount));
>while ((work = cm_dequeu
>Another possible issue:
>
>static inline void cm_deref_id(struct cm_id_private *cm_id_priv)
>{
>if (atomic_dec_and_test(&cm_id_priv->refcount))
>wake_up(&cm_id_priv->wait);
>}
>
>A thread could test the refcount after atomic_dec_and_test but before
>wake_up(&cm_id_priv->wai
>> Sync up with Sean on commits.
>
>I'm watching for Sean's commit. Did I miss it?
No - I will commit by noon PST today.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
Michael S. Tsirkin wrote:
Two nits wrt rdma_cm.h:
/**
* * rdma_reject - Called on the passive side to reject a connection request.
*/
Its OK to call rdma_reject on active side as well, isn't it?
Yes - but only for users that are managing the QP states themselves.
/**
* rdma_cm_event_ha
Or Gerlitz wrote:
Looking in the code i have realized that it is a must for the CMA
consumer to call rdma_disconnect to have the QP state moved into ERROR.
Maybe it would make sense for the CMA to transition the QP to the error state
before destroying it?
Am i correct? with this understandin
Or Gerlitz wrote:
+ /* change the ib conn state only if the conn is UP, however always call
+ * rdma_disconnect since this is the only way to cause the CMA to change
+ * the QP state to ERROR
+ */
I updated the comments in the header file to state that rdma_disconnect()
transitions that QP
Michael S. Tsirkin wrote:
I was originally thinking along the lines of still using ESTABLISHED, and simply
delaying RTU till after the handler is called. We would then need to teach CMA
to perform reject instead of RTU if handler returns an error code.
We even can have a flag to select the requ
Michael S. Tsirkin wrote:
void mthca_cq_event(struct mthca_dev *dev, u32 cqn,
enum ib_event_type event_type)
{
struct mthca_cq *cq;
struct ib_event event;
spin_lock(&dev->cq_table.lock);
cq = mthca_array_get(&dev->cq_table.cq, cqn & (dev->limi
Michael S. Tsirkin wrote:
Sean, I am seeing the following problem: I have a dual-port HCA
with IPoIB interfaces ib0 on port 1 and ib1 on port 2.
port 1 is down and port 2 is up,
and I try creating a connection to the loopback address 127.0.0.1.
The problem I am seeing is that I am getting RDMA_
Michael S. Tsirkin wrote:
static inline void cm_deref_id(struct cm_id_private *cm_id_priv)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&cm_id_priv->lock, flags);
if (atomic_dec_and_test(&cm_id_priv->refcount))
wake_up(&cm_id_priv->wait);
+ spin_unloc
Michael S. Tsirkin wrote:
Fine, but rdma_reject will have to alter the state then, to avoid RTU
after REJ.
It should be able to work just as it does for userspace. The user either calls
accept or reject. The IB CM will not send an RTU if a REJ has been sent.
I think that the real issue her
Michael S. Tsirkin wrote:
Is it possible to communicate between QPs on
the same device if that device is disconnected from the fabric?
Yes.
What attributes do you use for the pkey index and address vector when connecting
the QPs?
I'm wondering if the correct solution to this issue isn't t
Michael S. Tsirkin wrote:
I actually think all we have to do is to change CMA behaviour on REP:
send RTU after, and not before, calling user handler.
Since other ULPs don't seem t care when RTU is sent, they will continue
working.
I think that it makes more sense to give the user the CONNECT_RE
Michael S. Tsirkin wrote:
static inline void cm_deref_id(struct cm_id_private *cm_id_priv)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&cm_id_priv->lock, flags);
if (atomic_dec_and_test(&cm_id_priv->refcount))
wake_up(&cm_id_priv->wait);
+ spin_unloc
Roland Dreier wrote:
Sean> Could we use atomic_dec_and_lock() instead? This would keep
Sean> refcount atomic, but use a spinlock to synchronize with
Sean> destruction.
Hmm, how does that help?
Just going to a plain integer with a spinlock to protect it seems
simple and clear.
Bas
Jack Morgenstein wrote:
Should we use this revision (6949/6950 of the openib trunk) of the rdma_cm in
the upcoming OFED (branch) release?
The end-users should probably decide that. These changes use the local_sa,
which has not been queued to be merged upstream yet.
(since the branch rdma_c
>If you wanted to implement this, you would have to use a completion.
>A mutex can't be used because it must be released in process context
>with interrupts enabled. And a semaphore can't be used because
>there's an implicit use-after-free with semaphores (basically up()
>touches the semaphore mem
Jack Morgenstein wrote:
Use of local_sa in the rdma_cm kernel module is already patched out for OFED.
local_sa is used ONLY in kernel cma.c ( static function
cma_resolve_ib_route(), which calls ib_get_path_rec()).
Icall to ib_get_path_rec() is eliminated, and we call cma_query_ib_route()
direct
Michael S. Tsirkin wrote:
From iSER point of view, this approach is fine, and it would allow for
some future flexibility to reject the REP. We prefer to implement it
only for 2.6.19, that is when 2.6.18-rc1 is out.
Let us start by implementing this in SVN trunk. Sean, if you agree too, can yo
Here's a patch that should fix both the IB CM and RDMA CM using
completions rather than spinlock / wait objects.
Michael, can you test that this version works for you?
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
>> Sync up with Sean on commits.
>
>I'm watching for Sean's commit. Did I miss it?
It looks like my commit failed for some reason, and I missed it. I've just
re-committed the changes, which should be in revision 7019.
- Sean
___
openib-general mailing
Dotan Barak wrote:
Compilation of the gen2 driver generate compilation warnings when compiling
the libibcm.
I've committed changes that should eliminate these warnings. I've also updated
librdmacm to replace deprecated function/structure names with the latest names.
Thanks.
- Sean
__
Here's a patch for all of the files that you listed.
I did do some basic testing and didn't see any issues.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: mad_rmpp.c
===
--- mad_rmpp.c (revision 6884
Michael S. Tsirkin wrote:
I thought about this too. People actually do expect loopback to work when link
is down. I guess we could create "loopback" path record, with parameters such
as SL editable from sysfs.
Until the underlying IB stack supports loopback connections on a non-active
port, m
Michael S. Tsirkin wrote:
Until the underlying IB stack supports loopback connections on a non-active
port
How do you mean? You can already create loopback connections as per IB spec - it
works already.
It works if the port is active. I don't believe that there's any code to
support connect
mple patch and see if it fixes your problem? You will
need to call rdma_accept() or rdma_reject() after receiving a CONNECT_RESPONSE
event. The conn_param to rdma_accept() should be NULL.
Signed-off-by: Sean Hefty <[EMAIL PROTECT
Ira Weiny wrote:
I have been struggling with getting svn6829 to work and this is one of the
latest issues.
# odev1 /root > simple_rdma -S
librdmacm: kernel ABI version 0 doesn't match library version 1.
Failed to create rdma_cm_id
This is a little rdma app I wrote which uses the rdma_cm userspa
Tom Tucker wrote:
Its OK to call rdma_reject on active side as well, isn't it?
You'll get -EINVAL on iWARP if you do this
For IB, rdma_reject can be called on the active side if the user is managing
their own QP states, or is SDP. How does iWarp support userspace QPs?
- Sean
_
Michael S. Tsirkin wrote:
No, looking in the code shows that qp will be changed to rtr and then
rts ***before*** sending the RTU since you will call rdma_accept which
in turn will call cma_rep_recv
Right, missed that, thanks!
I was wandering why it was behaving not the way I expected it to :)
Jack Morgenstein wrote:
Userspace rdma_get_option() will then also get -ENODATA. OK.
We can, therefore, do the following:
the dummy procedures in the dummy ib_local_sa.h file will
return -ENODATA for all get operations and for ib_create_path_cursor(),
and -ENOSYS for all
Dotan Barak wrote:
There is a compilation warning in the file: src/userspace/librdmacm/src/cma.c.
Thanks - I committed a fix for this. It should have been a void.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mai
Jack Morgenstein wrote:
I assume you mean "disabled".
Uhm.. yes - that's what I meant.
Looks like setting cache_timeout to zero as the default is good enough:
in sa_db_init(), cache_timeout remains 0 when translated to jiffies, resulting
in paths_per_dest being set to zero as well.
Therefo
Thanks - committed.
- 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
Michael S. Tsirkin wrote:
BTW, Sean, could you please explain why is RESPONSE event IB-specific?
Does not it match Syn/Ack in the TCP 3-way handshake?
I didn't think that even iWarp exposed the TCP connection messages to the users.
Plus iWarp connections can be formed over an existing TCP con
For context, I'm trying to work backwards from send a message on a UD QP to
determine what information is needed and how it is obtained.
Does anyone know how the user determines if the grh flag should be set in the
ib_ah_attr when allocating an ib_ah? Do they do this by examining the GIDs in a
pa
> - CMA. Sean, I think there have been a lot of updates to the cma
> since the last time you updated me. Can you send me a patch to
> resync my for-2.6.18 branch with the latest code for upstream?
I will start on this by the end of the week.
- Sean
__
Michael S. Tsirkin wrote:
This has run for a couple of nights here without issues. Please commit.
I also think we shall push this patch for 2.6.17 - it is clean and simple
enough. Agree?
I've committed these changes to svn.
Roland, can you queue this patch for 2.6.17, or at least 2.6.18?
- Se
Roland,
I just wanted to make sure that this patch wasn't dropped.
Can we queue the multicast module for 2.6.18?
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
Roland Dreier wrote:
Sean> Can we queue the multicast module for 2.6.18?
I guess so. What's the motivation? Do we have any users of it other
than IPoIB?
I'm working on adding multicast support for userspace (MPI), which will also
need this.
- Sean
_
Roland, this is the patch that I was referring to.
---
Fix race condition during destruction calls to avoid possibility of accessing
object after it has been freed.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: mad_
Roland Dreier wrote:
Sean> I'm working on adding multicast support for userspace (MPI),
Sean> which will also need this.
Right, but that's not going to be ready for 2.6.18, is it?
It won't be ready for merging, no. I was hoping to limit the number of out of
tree modules that it requi
Hal Rosenstock wrote:
Anytime the send is off the local subnet (as well as multicast), a GRH
is required. Also, there is a management response rule for responding
when the request contained a GRH that require a GRH (13.5.4.4 p. 769).
Reading through the responses, I think my problems are worse.
Sean Hefty wrote:
Can you try this simple patch and see if it fixes your problem? You will
need to call rdma_accept() or rdma_reject() after receiving a CONNECT_RESPONSE
event. The conn_param to rdma_accept() should be NULL.
Michael,
Did you ever get a chance to try this patch? If so, I
Michael S. Tsirkin wrote:
In that case, how about we change rdma_disconnect for IB to do reject if
connection isn't established yet?
Unless I missed something, the only problem that we're trying to solve is that
SDP needs to be able to reject a connection based on private data in the REP,
but
Michael S. Tsirkin wrote:
I'm nervous about doing big changes in the multicast code in ipoib - it had more
than a fair share of subtle races.
The patch simplifies the multicast code in ipoib, and the serialization in the
multicast module is simple enough that we should be able to have a fair a
Eric Barton wrote:
What have I done bad to make a send (the very first one on a newly established
RC QP) complete with status 10 (IB_WC_REM_ACCESS_ERR)?
The remote QP gets an event callback of type 3 (IB_EVENT_QP_ACCESS_ERR), and
then all posted receives on both QPs complete with status 5
(IB_WC
Eric Barton wrote:
int
kiblnd_post_rx (kib_rx_t *rx, int credit)
{
kib_conn_t *conn = rx->rx_conn;
struct ib_recv_wr *bad_wrq;
int rc;
LASSERT (!in_interrupt());
LASSERT (credit == IBLND_POSTRX_NO_CREDIT ||
credit
I consistently get a URL error: 504... error: Unable to find 2ac5. under
http://git... every time I try to clone your git tree. Is there a mirror that I
can try cloning from, or do you know of an alternative way of getting the tree?
___
openib-gen
Jason Gunthorpe wrote:
How about this, how do you see this scenario:
1) Client gets a DGID from 'someplace'
2) Client sends a SA query to resolve the DGID to a Path Record
3) Client configures a QP based on the Path Record
Now, the question I'm interested in is this:
During step #3 what test
Thanks for the info. I just updated my git version, and it worked 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/
Michael S. Tsirkin wrote:
Sean, CMA currently does not support IPv6 addresses at all. Is that right?
This is correct. At best, there's some code in places to handle it.
However, while I don't have immediate need to make real IPv6 addressing to work,
some applications (notably Java) always us
Ian Brown wrote:
Are there Etherenet NICS in the market (or will there be soon such nics)
such NICs which are RDMA nics (RDMA enabled NICs)?
And in case the answer is positive - does linux kernel has support
for such nics?
The Linux kernel does not have support for RNICs at this time, but there
Thanks! - applied.
- 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
>OK. May we discuss the design/API for now?
Sounds good.
>My understanding is an IPv4 socket should only listen on IPv4 requests,
>while IPv6 socket should listen on both IPv4 and IPv6, unless
>IPV6_V6ONLY is set.
>
>Is that right? What will the API be for this? Maybe create_cm_id should get an
>
>Rdma_create_id() already takes a struct sockaddr *, which has an address
>family selector (sa_family) to define the contained address format. Why is
>that one not sufficient?
Rdma_bind() and rdma_resolve_addr() take struct sockaddr *. Rdma_create_id()
only has an event handler, context, and port
>Looking at rdma_listen(), the code I see checks for bound state before
>proceeding to listen:
>
>int rdma_listen(struct rdma_cm_id *id, int backlog)
>{
>struct rdma_id_private *id_priv;
>int ret;
>
>id_priv = container_of(id, struct rdma_id_private, id);
>if (!cma_c
I'm assuming that since the CMA isn't upstream yet, a single patch will
work.
The patch below should contain everything that makes sense to merge
upstream for the CMA.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
diff --git a/drivers/infiniband/core/cma.c b/drivers/infin
OK, I just tested and this works for me. Here's the SDP patch to do what you
described. The code actually got cleaner now: its convenient to get
different events on active versus passive side - previously I had
to check a flag to figure out what does ESTABLISHED mean.
I committed the CMA patch.
Please post generic questions to the openib
mailing list.
i have started working over infiniband recently
i want to develop a sample utility that would perform simple RDMA (read/write)
operations
There are some test applications that can be
used as a base. Are you wanting a userspac
>Any reason not to apply this?
Looks fine to apply be me.
- 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
Dotan Barak wrote:
Added checks to the return values of all of the functions that may fail
(in order to add this test to the regression system).
Thanks - applied with one minor change.
+ int rc;
Changed 'rc' to 'ret' to match the rest of the code.
- Sean
_
Thanks! Committed with only minor adjustment to spacing.
- 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
>Sean> Thanks! Committed with only minor adjustment to spacing. -
>
>Should I add that commit to what I have queued for 2.6.18?
It shouldn't hurt, but isn't strictly needed. The changes are for SDP, and IPv6
support still requires more work. My personal vote would be yes, with the hope
tha
The pkey is provided into a SIDR REQ in two places, once as a parameter,
and again in the path record. Remove the pkey as a parameter and always
use that given in the path record.
This change has no practical effect on ABI functionality.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Expose a new call to initialize address handle attributes from a work
completion. This functionality is duplicated by both verbs and the CM.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: include/rdma/ib_v
a client calls: resolve_addr, resolve_route, and
connect. A server calls: listen and accept. Connect and accept
correspond to SIDR REQ / SIDR REP, respectively.
This patch introduces a new protocol for SIDR that is the same as that
used by the CMA for connection REQs.
Signed-off-by: Sean Hefty
Remove the pkey from the API for SIDR REQ. The pkey is provided
in the path record.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: include/infiniband/cm.h
===
--- include/infiniband/cm.h (revision 7020)
+++ i
601 - 700 of 2719 matches
Mail list logo
