This looks like a great start.
One part I didn't understand, however, was where the local port is
assigned for children of the listening endpoint? The local port for
these endpoints will be the same as for the listening parent. So if
cma_use_port is used to bind these child endpoints (i.e. add the
Roland Dreier wrote:
Should I add this on top of the CMA patches I have queued for 2.6.18?
I'd like to get some feedback on the implementation first, but we probably want
to get this functionality in, even if the implementation gets tweaked a little.
- Sean
__
Should I add this on top of the CMA patches I have queued for 2.6.18?
___
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-gener
Dear valued MoneyBookers member ,
Our security system has detected a strange activity about your account . If you cold please
take 1-2 minutes out of your online experience and confirm your identity . However , failure to confirm your records
will result in account suspension
Roland Dreier wrote:
Roland> Hmm, you may be right -- scsi_eh_bus_device_reset() in
Roland> scsi_error.c does seem to flush all commands. But do you
Roland> see srp_reset_device() being called? I didn't think I saw
Roland> it in your trace.
It was in my trace. I probably left
Thanks, applied. Sorry for letting that sneak through...
- R.
___
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 patch makes the needlessly global mthca_update_rate() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.17-rc1-mm3-full/drivers/infiniband/hw/mthca/mthca_mad.c.old
2006-04-18 21:38:06.0 +0200
+++ linux-2.6.17-rc1-mm3-full/drivers/infiniband/hw/mthca/mthca_ma
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
03:07:06 PM:
> Shirley> It's on mthca. If you are interested. I
can submit a test
> Shirley> patch for your experimental.
>
> Sure, that would be useful.
>
> - R.
It is built on top of splitting CQ patch.
I will send you the patch
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
03:06:33 PM:
> And actually it argues against splitting the CQ, because having one
CQ
> increases the number of CQ entries that we have a chance to poll at
> any one time, by lumping send and receive completions together...
>
> - R.
The sen
Shirley> It's on mthca. If you are interested. I can submit a test
Shirley> patch for your experimental.
Sure, that would be useful.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-genera
Shirley> After completion handler receives the notification, don't
Shirley> poll the CQ right away, and wait for more WIKIs in
Shirley> CQ. That way can reduce the CQ lock overhead.
Roland> That's interesting... it makes sense, and it argues in
Roland> favor of deferring CQ pol
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
03:01:57 PM:
> Shirley> After completion handler receives the notification,
don't
> Shirley> poll the CQ right away, and wait for more
WIKIs in
> Shirley> CQ. That way can reduce the CQ lock overhead.
>
> That's interesting... it
Shirley> After completion handler receives the notification, don't
Shirley> poll the CQ right away, and wait for more WIKIs in
Shirley> CQ. That way can reduce the CQ lock overhead.
That's interesting... it makes sense, and it argues in favor of
deferring CQ polling to a kernel thread.
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
02:49:34 PM:
> Shirley> The patch allows you tuning send/recv NUM_WC
per poll and
> Shirley> add some cycles before polling to sync with
the hardware.
>
> I have no problem increasing NUM_WC to something much bigger. What
do
> you me
Shirley> The patch allows you tuning send/recv NUM_WC per poll and
Shirley> add some cycles before polling to sync with the hardware.
I have no problem increasing NUM_WC to something much bigger. What do
you mean by "add some cycles before polling"?
- R.
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
02:33:55 PM:
> Shirley> This is another patch to gain huge performance
on ehca
> Shirley> driver. I haven't submitted yet. :-)
>
> What does the patch do?
>
> - R.
The patch allows you tuning send/recv NUM_WC per poll
and add some
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/18/2006
01:45:17 PM:
> I'm a little uncomfortable splitting the IPoIB CQ until we have a
> plausible theory as to why it improves performance. It may be
that
> understanding this would lead us to fix the underlying issue in a
> better way and get eve
Shirley> This is another patch to gain huge performance on ehca
Shirley> driver. I haven't submitted yet. :-)
What does the patch do?
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gene
Bernie,
Bernard King-Smith/Poughkeepsie/IBM wrote on 04/18/2006
01:48:28 PM:
> When we ran with the split completion queue patch, we no longer see
one
> process pegging the CPU at 100% and we get a speedup of 65% going
> from STREAM to Duplex. Without the split completion queue, we only
> saw
On Tue, 18 Apr 2006, Dotan Barak wrote:
> On Monday 17 April 2006 23:46, James Lentini wrote:
> >
> > On Sun, 16 Apr 2006, Dotan Barak wrote:
> >
> > > On Wednesday 12 April 2006 17:50, James Lentini wrote:
> > > > > OpenIB-cma u1.2 nonthreadsafe default /usr/lib/libdaplcma.so
> > > > > mv_da
Bernard> On a multiple CPU system looking at TOP you see one
Bernard> process consuming a full CPU. This happens to be the
Bernard> thread handling completion queue entries. I suggested
Bernard> that we look at separate threads handing send completions
Bernard> vs. receive com
Shirley> Some tests have been done over mthca and
Shirley> ehca. Unidirectional stream test, gains up to 15%
Shirley> throughout with this patch on systems over 4 cpus.
Shirley> Bidirectional could gain more. People might get different
Shirley> performance improvement number und
> > Actually, do you have some explanation for why this helps performance?
> > My intuition would be that it just generates more interrupts for the
> > same workload.
> The only lock contension in IPoIB I saw is tx_lock. When seperating
> the completion queue to have seperate completion hand
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
Roland> The closest analogy I can come up with is doing
Roland> socket()/bind() and then accept() on the socket, which
Roland> returns a new file desc.
Oh, I forgot one of the main points I wanted to talk about: doing
something like an open() on a file in uverbsfs to create a new event
I noticed this small mistake in the libmthca README
Signed-off-by: James Lentini <[EMAIL PROTECTED]>
Index: libmthca/README
===
--- libmthca/README (revision 6507)
+++ libmthca/README (working copy)
@@ -20,7 +20,7 @@ libmthc
Roland> Hmm, you may be right -- scsi_eh_bus_device_reset() in
Roland> scsi_error.c does seem to flush all commands. But do you
Roland> see srp_reset_device() being called? I didn't think I saw
Roland> it in your trace.
And what if you comment out the line
.eh_device_res
Vu> Right for abort command; however, I'm not sure after scsi
Vu> midlayer called device_reset
Hmm, you may be right -- scsi_eh_bus_device_reset() in scsi_error.c
does seem to flush all commands. But do you see srp_reset_device()
being called? I didn't think I saw it in your trace.
_
Roland Dreier wrote:
> The return happened before reaching the code above. It happened at:
> if (!wait_for_completion_timeout(&req->done,
>msecs_to_jiffies(SRP_ABORT_TIMEOUT_MS)))
> return FAILED;
>
> because the qp was in fatal state. Theref
Christoph> I'd like to get rid of get_empty_filp midterm. Because
Christoph> of that's I've looked at all the users, and the only
Christoph> modular and most creative one is the uverbs code.
Christoph> Everything else only every returns new fds from
Christoph> syscalls, which i
> The return happened before reaching the code above. It happened at:
> if (!wait_for_completion_timeout(&req->done,
>
> msecs_to_jiffies(SRP_ABORT_TIMEOUT_MS)))
> return FAILED;
>
> because the qp was in fatal state. Therefore, the c
Roland Dreier wrote:
Hmm, I don't understand what could be going on. srp_send_tsk_mgmt()
currently has:
if (req->cmd_done) {
srp_remove_req(target, req, req_index);
scmnd->scsi_done(scmnd);
} else if (!req->tsk_status) {
srp_remove
Roland,
Roland Dreier <[EMAIL PROTECTED]> wrote on 04/17/2006
01:12:38 PM:
> Have you ever seen this hurt performance? It seems that splitting
> receives and send CQs will increase the number of events generated
and
> possibly use more CPU.
The performance gain was not free, it did cost cpu util
On 4/17/06, Roland Dreier <[EMAIL PROTECTED]> wrote:
> It's up to you whether you think it's more appropriate to merge iSER
> through James's tree or my tree. In any case, the best way to proceed
> would be to post a final set of patches sent To: the maintainer you
> want to go through, Cc:ed to l
Thanks for the patch! This is a nice cleanup...
The code does actually wait. If you go look at the implementation of
wait_event_timeout you will see that it essentially the same thing. At
the time this code was written, the wait_event_timeout function didn't
exist ...
On Tue, 2006-04-18 at 12:4
I'd like to get rid of get_empty_filp midterm. Because of that's I've
looked at all the users, and the only modular and most creative one
is the uverbs code. Everything else only every returns new fds from
syscalls, which is a good thing. Trying to show-horn fds into ->write
otohg creates variou
Hi
This patch corrects the vq_wait_for_reply function so that it actually waits
for the reply till the timeout occurs.
Signed-off-by: Pradipta Kumar B <[EMAIL PROTECTED]>
Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
---
Index: c2_vq.c
37 matches
Mail list logo
