Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-kernel-new/dat-provider/dapl_openib_cm.c
===
--- linux-kernel-new/dat-provider/dapl_openib_cm.c (revision 2462)
+++ linux-kernel-new/dat-provider/dapl_openib_cm.c (wo
On Thu, 19 May 2005, Roland Dreier wrote:
> Vivek> The draft does allow for a negotiation per connection for
> Vivek> the implementations that wish to take advantage of
> Vivek> it. However, an implementation can by default choose to use
> Vivek> a 'connected-mode MTU' e.g. 32K alw
This patch optimizes the cancel MAD path. It eliminates searching
the timeout list when setting a MAD's timeout to zero, removes
duplicates checks to insert a work item to process the timeout,
and avoids resending the MAD as it is canceled.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: m
On Fri, May 20, 2005 at 10:49:40AM -0400, Hal Rosenstock wrote:
> Hi Libor,
>
> A possible minor change to ucm.c::ib_ucm_event_handler line 440 would
> be:
>
> uevent->cm_id = (id == IB_UCM_CM_ID_INVALID ?
> cm_id : NULL);
> rather than:
> uevent->cm_id =
This patch removes the kDAPL timer implementation and uses the Linux
native timer class. Please look over and comment.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-kernel-timer/test/dapltest/test/dapl_performance_util.c
===
The following patch adds support to repeat MRA messages in response to
receiving a duplicate REQ, REP, or LAP.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: cm.c
===
--- cm.c(revision 2417)
+++ cm.c(working c
On Mon, 23 May 2005, Roland Dreier wrote:
Roland> I think you may be misunderstanding the suggestion. The
Roland> idea is that the driver takes the input value of
Roland> max_inline_data as a hint, and tries to allocate a QP that
Roland> supports that value. However, if the value
Roland> I think you may be misunderstanding the suggestion. The
Roland> idea is that the driver takes the input value of
Roland> max_inline_data as a hint, and tries to allocate a QP that
Roland> supports that value. However, if the value is too large,
Roland> the driver reduc
Mark Seger wrote:
As I said in my base note I'm currently reading from /proc while some
sets of counters are better organized than others, I can still access
them relatively efficiently. While I could certainly "get by" reading
one variable per file, I do worry about the overhead as the sampl
Since I was the one who originally created this topic I'd like to
restate what I said that got this all started. I'm trying to do
relatively lightweight monitoring of lots of system performance counters
(on the order of 100-200 or more) across a number of subsystems using
standard interfaces.
On Mon, 23 May 2005, Michael S. Tsirkin wrote:
Quoting r. James Lentini <[EMAIL PROTECTED]>:
Subject: Re: Re: libibverbs and max inline data
On Mon, 23 May 2005, Michael S. Tsirkin wrote:
Quoting r. James Lentini <[EMAIL PROTECTED]>:
Subject: Re: Re: libibverbs and max inline data
On
Michael S. Tsirkin wrote:
ib[v]_create_qp should return an error when an unsupported inline data
size is requested.
Why is it important? The user could always check the max_inline_data
returned and close the qp if thats too small, but I dont see
many users doing this - inline data is mainly a t
On Mon, 23 May 2005, Roland Dreier wrote:
James> Once there is a way to programmatically determine the
James> max_inline_data value, your proposal would be
James> feasible. Even if it were possible, I still believe that
James> the driver should validate this value.
I think you may
On Mon, 23 May 2005, Roland Dreier wrote:
James> Once there is a way to programmatically determine the
James> max_inline_data value, your proposal would be
James> feasible. Even if it were possible, I still believe that
James> the driver should validate this value.
I think you may
On Mon, 2005-05-23 at 12:27, Sean Hefty wrote:
> Are there any performance counters that aren't available through the PMA
> MADs? If not, is there any reason why the PMA interface shouldn't be used
> for programmatic access?
All the counters found in:
/sys/class/infiniband/mthca0/ports/1/counte
userspace/management changes to support send side RMPP
(needs change to linux-kernel/infiniband/core/user_mad.c)
ABI_VERSION is now 3
RMPP is enabled in build
SA GetTable is now supported properly (within current RMPP limitations)
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Modified: gen2/t
Mark Seger wrote:
I guess the thing that has me mystified about all this is I can
certainly appreciate the potential 'goodness' of having 1 var/file for
user oriented access but perhaps one of the better examples of why this
is just a bad idea for programmatic access is the individual process
Quoting r. James Lentini <[EMAIL PROTECTED]>:
> Subject: Re: Re: libibverbs and max inline data
>
>
>
> On Mon, 23 May 2005, Michael S. Tsirkin wrote:
>
> >Quoting r. James Lentini <[EMAIL PROTECTED]>:
> >>Subject: Re: Re: libibverbs and max inline data
> >>
> >>
> >>On Sun, 22 May 2005, Roland
James> Once there is a way to programmatically determine the
James> max_inline_data value, your proposal would be
James> feasible. Even if it were possible, I still believe that
James> the driver should validate this value.
I think you may be misunderstanding the suggestion. The i
On Mon, 23 May 2005, Michael S. Tsirkin wrote:
Quoting r. James Lentini <[EMAIL PROTECTED]>:
Subject: Re: Re: libibverbs and max inline data
On Sun, 22 May 2005, Roland Dreier wrote:
Michael> Hi! I tried to figure out how much inline data a qp can
Michael> support, to know what max_i
Hi, Roland!
I have a test that sets .max_recv_wr = 0
and crashes in mthca_poll_cq, when a send completion arrives.
Here's a backtrace of a crash:
#0 0x2b22ad90 in mthca_poll_cq (ibcq=Variable "ibcq" is not available.
) at src/cq.c:317
#1 0x0040259d in main (argc=Variable "argc"
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: registering read-only memory
>
> Michael> What about the patch that I posted?
>
> Adding the "const" makes sense but adding "volatile" doesn't seem good
> to me.
Could you explain why? Since the library never accesses the data, it
On Mon, 2005-05-23 at 10:14, Roland Dreier wrote:
> Looks OK to commit to me.
Thanks. Applied.
-- Hal
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openi
Michael> What about the patch that I posted?
Adding the "const" makes sense but adding "volatile" doesn't seem good
to me. I think it's better for the tiny subset of people who really
need "volatile" to add casts.
- R.
___
openib-general mailing
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: registering read-only memory
>
> Michael> 2. ibv_reg_mr fails. Why is that?
>
> Michael> Returns NULL, naturally.
>
> ... hmm, I'll take a look.
>
> - R.
>
What about the patch that I posted?
--
MST - Michael S. Tsirkin
Quoting r. James Lentini <[EMAIL PROTECTED]>:
> Subject: Re: Re: libibverbs and max inline data
>
>
> On Sun, 22 May 2005, Roland Dreier wrote:
>
> > Michael> Hi! I tried to figure out how much inline data a qp can
> > Michael> support, to know what max_inline_data value to put in the
> >
Quoting r. Ronald G. Minnich :
> Subject: Re: performance counters in /sys
>
>
>
> On Mon, 23 May 2005, Michael S. Tsirkin wrote:
>
> > > I guess the thing that has me mystified about all this is I can
> > > certainly appreciate the potential 'goodness' of having 1 var/file for
> > > user ori
On Mon, 2005-05-23 at 10:29, Roland Dreier wrote:
> Hal> It appears to me that there is nothing that enforces the man
> Hal> page behavior above in Linux so this is a "convention". Is
> Hal> this something we can take advantage of or do we need to
> Hal> require the additional call
On Mon, 23 May 2005, Michael S. Tsirkin wrote:
> > I guess the thing that has me mystified about all this is I can
> > certainly appreciate the potential 'goodness' of having 1 var/file for
> > user oriented access but perhaps one of the better examples of why this
> > is just a bad idea for
On Sun, 22 May 2005, Roland Dreier wrote:
Michael> Hi! I tried to figure out how much inline data a qp can
Michael> support, to know what max_inline_data value to put in the
Michael> qp. However, there doesnt seem to exist a way to do
Michael> that, currently.
I think you're righ
I agree Tom. I think the easiest way to do this is one subsystem at a
time. To avoid us duplicating work, how responding on this thread with
the subsystem(s) you would like to merge.
On a somewhat related topic, the DAPL linked list implementation
should be removed in favor of the Linux implem
Bernhard,
Thank you for pointing these items out. Comments below:
On Sat, 21 May 2005, Bernhard Fischer wrote:
On Fri, May 20, 2005 at 03:05:08PM -0700, [EMAIL PROTECTED] wrote:
Author: jlentini
Date: 2005-05-20 15:05:07 -0700 (Fri, 20 May 2005)
New Revision: 2426
Just tersely parsing, no
Michael> 2. ibv_reg_mr fails. Why is that?
Michael> Returns NULL, naturally.
... hmm, I'll take a look.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
Hal> It appears to me that there is nothing that enforces the man
Hal> page behavior above in Linux so this is a "convention". Is
Hal> this something we can take advantage of or do we need to
Hal> require the additional call to get the buffer length ?
Something I was thinking a lit
Looks OK to commit to me.
- 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
35 matches
Mail list logo
