On Thu, 2005-05-19 at 21:43 -0400, James Lentini wrote:
> I commited a fix for this in revision 2420. The problem turned out to
> be that DAPL wasn't initializing the max_inline_data value of the QP
> attr's cap structure.
>
> Let me know if you still have any problems.
Good job. All is well n
On Thu, 2005-05-19 at 21:30 -0700, Shirley Ma wrote:
>
> > Error, some other host already uses address 192.168.0.233.
>
> I hit a simliar problem a while ago. But I couldn't reproduct it since
> then.
> Is this reproducible if you configure duplicate IP addresses?
I don't think this particula
> Error, some other host already uses address 192.168.0.233.
I hit a simliar problem a while ago. But I couldn't reproduct it since
then.
Is this reproducible if you configure
duplicate IP addresses?
Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Pho
Committed in revision 2423.
On Thu, 19 May 2005, Hal Rosenstock wrote:
halr> at: Change normal message from WARN to DEBUG
halr>
halr> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
halr>
halr> Index: at.c
halr> ===
halr> --- at
Committed in revision 2422.
On Wed, 18 May 2005, Tom Duffy wrote:
tduffy> return is not a function
tduffy>
tduffy> Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
tduffy>
tduffy> Index: linux-kernel-return/dat-provider/dapl_cookie.c
tduffy>
Commited in revision 2421.
On Wed, 18 May 2005, Tom Duffy wrote:
tduffy> I was running into some issues and noticed that these printks were not
tduffy> very clear about where they were coming from. So, adding a little more
tduffy> info.
tduffy>
tduffy> Signed-off-by: Tom Duffy <[EMAIL PROTECTE
Itamar,
Thank you for pointing this out.
Long term I think it will be better to keep the flags with the spin
lock so that these "scoping" issues don't crop up and force us to pass
the flags around. The fix for this is in revision 2420.
james
On Wed, 18 May 2005, Itamar wrote:
itamar> when s
With revision 2420, I made the dat and ib_dat_provider module
debug parameter names consistent. They are now both dbg_mask.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, pleas
I commited a fix for this in revision 2420. The problem turned out to
be that DAPL wasn't initializing the max_inline_data value of the QP
attr's cap structure.
Let me know if you still have any problems.
There is a patch in the pipeline that will remove the IBAT printout
you mentioned.
james
On Thu, May 19, 2005 at 12:46:04PM -0700, Tom Duffy wrote:
> > The article states: 'InfiniPath will also support the OpenIB software stack
> > providing full InfiniBand compliance.'
>
> Also interesting that OpenIB is suddenly an "industry standard." ;-)
Tom,
There's a reason for that -- when
at: Change normal message from WARN to DEBUG
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: at.c
===
--- at.c(revision 2379)
+++ at.c(working copy)
@@ -737,13 +737,13 @@
arp = (struct ib_arp *)skb-
Title: RE: [openib-general] performance counters in /sys
> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 19, 2005 6:48 PM
> To: Yaron Haviv
> Cc: Mark Seger; openib-general@openib.org
> Subject: RE: [openib-general] performance counters in
On Thu, 2005-05-19 at 16:45, Yaron Haviv wrote:
> I believe you can use the per VL counters for that
> (IB allows counting traffic on a specific VL)
> By matching ULPs to VLs (e.g. through the ib_at lib we suggested)
> You can get both congestion isolation per traffic type as well as the
> ability
On Wed, 2005-05-18 at 19:04, Roland Dreier wrote:
> This looks OK to check in with one small comment on the following:
>
> - if (copy_to_user(buf, &packet->mad, sizeof packet->mad))
> + if (copy_to_user(buf, &packet->mad,
> + min(count, packet->length +
> +
user_mad: Support RMPP on send side
Note that this change will need a coordinated change to OpenSM and some
userspace/management libraries which will be done as soon as possible
once this patch is accepted.
Receive side support for RMPP will be added separately.
Signed-off-by: Hal Rosenstock <[E
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of Hal Rosenstock
> Sent: Thursday, May 19, 2005 11:22 PM
>
> On Thu, 2005-05-19 at 16:11, Mark Seger wrote:
> >
> > The only other thing that could be useful would be an extra field
for
> >
I am not saying that we need it in OpenIb code because it was in SF code
I said that in OpenIb implementation we need it the same as in SF we need
it.
we must have this lock because for example :
if the same evd will be a CM evd for 2 ep's
each one on different Thread both can try to add an event
I think I figure this out. DAPL was assuming a particular maximum
scatter gather list size. I'm going to change it to query for this
value. Hopefully I'll have a fix shortly.
james
On Thu, 19 May 2005, James Lentini wrote:
For what it's worth, this is the check that we are "failing":
qp->sq.max_
On Thu, 2005-05-19 at 16:11, Mark Seger wrote:
> I've looked through the archives for more details on this topic and
> while there were some interesting discussions during Sept 2004, none of
> them really seemed to touch on this specific topic - programmatic access
> to performance counters. I
I've looked through the archives for more details on this topic and
while there were some interesting discussions during Sept 2004, none of
them really seemed to touch on this specific topic - programmatic access
to performance counters. If this has already been discussed elsewhere a
pointer
On Wed, 2005-05-18 at 22:44 +0300, Itamar Rabenstein wrote:
> "evd producer locking" is something that we need in openib kdapl
> as it was in Source Forge implementation.
This is not a good excuse. OpenIB kdapl is a totally different beast
from the sourceforge implementation and will differ over
For what it's worth, this is the check that we are "failing":
qp->sq.max_gs > dev->limits.max_sg
( qp->sq.max_gs + 2 > dev->limits.max_sg is also true but
qp->transport == MLX is not).
On Thu, 19 May 2005, James Lentini wrote:
I'm looking into this Tom.
The following code was added to hw/mthca/m
On Thu, 2005-05-19 at 20:29 +0100, Paul Baxter wrote:
> I read with interest the PR blurb at
> http://supercomputingonline.com/article.php?sid=8740
> regarding InfiniPath's very low latencies and high throughput for MPI even
> at very modest message sizes.
>
> The article states: 'InfiniPath wil
Paul Baxter wrote:
I read with interest the PR blurb at
http://supercomputingonline.com/article.php?sid=8740
regarding InfiniPath's very low latencies and high throughput for MPI
even at very modest message sizes.
The article states: 'InfiniPath will also support the OpenIB software
stack provi
Paul:
> The article states: 'InfiniPath will also support the OpenIB software stack
> providing full InfiniBand compliance.'
>
> Is this something the OpenIB software developers are working on and
> something that can be commented on in public, or should I speculate/ask
> Pathscale?
Thanks fo
I'm looking into this Tom.
The following code was added to hw/mthca/mthca_qp.c on Friday
(starting on line 1233):
if ((qp->transport == MLX && qp->sq.max_gs + 2 > dev->limits.max_sg) ||
qp->sq.max_gs > dev->limits.max_sg || qp->rq.max_gs > dev->limits.max_sg)
return -EINVAL;
I am not sure when this started, but after updating to top of trunk*, I
can no longer get kdapltest to work properly. Both ipoib and sdp are
working.
Both server and client are returning an error: DAT_INVALID_HANDLE. This
is coming from ib_create_qp(). With debugging turned on:
[EMAIL PROTECTE
This is from latest bits, r2414.
Bringing up interface ib0: stack segment: [1] SMP
CPU 0
Modules linked in: ext3 jbd dm_mod video container button battery ac ohci_hcd
tpm_nsc tpm i2c_amd756 i2c_core ib_mthca ib_ipoib ib_sa ib_mad ib_core tg3
floppy xfs exportfs mptscsih mptbase sd_mod scsi
I read with interest the PR blurb at
http://supercomputingonline.com/article.php?sid=8740
regarding InfiniPath's very low latencies and high throughput for MPI even
at very modest message sizes.
The article states: 'InfiniPath will also support the OpenIB software stack
providing full InfiniBan
All three of these have mechanisms whereby the message can be skipped, in which
case applications should not depend on the private data (IB spec mentions that
apps should not depend on them).
For example, A inbound receive while in RTR state after having sent a REP can
be treated as an RTU, in
On Wed, May 18, 2005 at 08:00:15PM -0700, Felix Marti wrote:
> Hi Roland,
>
> define SMP :)
Anytime a CPU is cache coherent with another CPU.
> at these rates, system architecture comes into place,
Definitely. The architecture puts boundaries on how coherency
can be implemented...and thus avai
On Thu, May 19, 2005 at 06:32:32AM +0100, Paul Baxter wrote:
> Grant, Michael
>
> Great work!
>
> I wanted to point out a recent thread on comp.arch discussing the merits of
> using the geometric mean instead of the arithmetic mean as a basis for
> sampling the timing of a population.
Paul,
th
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 always. It can then, for
Vivek> every connection c
On Thu, May 19, 2005 at 08:51:26AM +0300, Michael S. Tsirkin wrote:
> Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> > Subject: Re: diff-perftest-07 replace pp_get_local_lid()
> > > Should I rather be looking at fixing up netperf to support IB?
> > >
> > > thanks,
> > > grant
> > >
> >
> >
Remove redundant check of pd->uobject in mthca_provider.c
Signed-off-by: James Lentini <[EMAIL PROTECTED]>Index: infiniband/hw/mthca/mthca_provider.c
===
--- infiniband/hw/mthca/mthca_provider.c(revision 2404)
+++ infiniband/hw
Hi Vivek,
On Thu, 2005-05-19 at 12:41, Vivek Kashyap wrote:
>
>
> >
> > The most interesting optimization available is implementing the IPoIB
> > connected mode draft, although I don't think it's as easy as Vivek
> > indicated -- for example, I'm not sure how to deal with having
> > different M
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 19, 2005 9:40 AM
>
> Fab Tillier wrote:
> > I'm still for hiding the RTU private data. I think it's useless because
> > it's unreliable - anything exchanged via private data in the RTU must
> > also be exchanged by other means in
On Thu, May 19, 2005 at 09:34:16AM -0700, Fab Tillier wrote:
> > From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, May 19, 2005 9:25 AM
> >
> > So being predictably unreliable for one implementation
> > stage is certainly something you can get away with.
> > Even when you add sup
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: user_mad::ib_umad_read question
>
> Hi,
>
> In ib_umad_read, there is currently (or soon to be something like) the
> following:
> ...
> packet = list_entry(file->recv_list.next, struct ib_umad_packet,
> list);
> list
Hal Rosenstock wrote:
In ib_umad_read, there is currently (or soon to be something like) the
following:
...
packet = list_entry(file->recv_list.next, struct ib_umad_packet, list);
list_del(&packet->list);
spin_unlock_irq(&file->recv_lock);
if (copy_to_user(bu
>
> The most interesting optimization available is implementing the IPoIB
> connected mode draft, although I don't think it's as easy as Vivek
> indicated -- for example, I'm not sure how to deal with having
> different MTUs depending on the destination.
The draft does allow for a negotiation
Hi,
In ib_umad_read, there is currently (or soon to be something like) the
following:
...
packet = list_entry(file->recv_list.next, struct ib_umad_packet, list);
list_del(&packet->list);
spin_unlock_irq(&file->recv_lock);
if (copy_to_user(buf, &packet->mad
Fab Tillier wrote:
I'm still for hiding the RTU private data. I think it's useless because
it's unreliable - anything exchanged via private data in the RTU must also
be exchanged by other means in case the connection is established before the
RTU is received. Any ULPs that depend on the RTU priva
> From: Caitlin Bestler [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 19, 2005 9:25 AM
>
> So being predictably unreliable for one implementation
> stage is certainly something you can get away with.
> Even when you add support it might be quite acceptable
> to send the private data *only* on th
In that case, I'll point out that no application can rely upon
the final data being delivered because the first data can
easily beat the RTU. When that happens the IT-API
layer declares the connection established, and provides
no private data.
So being predictably unreliable for one implementation
Quoting r. Libor Michalek <[EMAIL PROTECTED]>:
> Subject: Re: sdp_link.c info_list locking question
>
> On Thu, May 19, 2005 at 11:12:38AM +0300, Michael S. Tsirkin wrote:
> > Libor, I'm looking at sdp_link.c, and I dont see any lock
> > protecting the info_list linked list.
> > What prevents sdp_
On Thu, May 19, 2005 at 11:12:38AM +0300, Michael S. Tsirkin wrote:
> Libor, I'm looking at sdp_link.c, and I dont see any lock
> protecting the info_list linked list.
> What prevents sdp_path_info_lookup from being called while
> sdp_path_info_create or sdp_path_info_destroy is in progress?
Micha
Caitlin Bestler wrote:
In any event, if no support is going to be provided for
private data on the second it_ep_accept at the verb
layer then that should be explicitly documented, and
I'd suggest sending a 'heads up' to the IT-API authors,
To clarify, I was only trying to determine when to implemen
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: registering read-only memory
>
> Michael> 2. ibv_reg_mr fails. Why is that?
>
> How does it fail?
>
> R.
>
Returns NULL, naturally.
--
MST - Michael S. Tsirkin
___
openib-general m
Michael> 2. ibv_reg_mr fails. Why is that?
How does it fail?
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-ge
Parks> Is there a branch for 2.6.12? We have noticed that we get
Parks> different performance when built on 2.6.11-5 vs 2.6.12-rc4.
Obviously the drivers/infiniband already in 2.6.12-rc4 should work
fine. Current svn should also work -- I think the only change
required is for SDP, and To
2. I suggest you make sure the kernels are built with all the same options,
especially regarding security, networking and cpu type options.
This is on the same box, but I have to check the .config files.
___
openib-general mailing list
openib-general@
On Thu, 2005-05-19 at 09:24, Michael S. Tsirkin wrote:
> Management libraries leak resources (memory, file/directory handles).
> Also a trailing whitespace fix in one place in libibcommon.
>
> Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Thanks. Applied.
-- Hal
Quoting r. Parks Fields <[EMAIL PROTECTED]>:
> Subject: 2.6.12 question
>
> Hello
>
> Is there a branch for 2.6.12?
> We have noticed that we get different performance when built on 2.6.11-5 vs
> 2.6.12-rc4.
>
> thanks
>
1. Could you elaborate please?
2. I suggest you make sure the kernels ar
Hello
Is there a branch for 2.6.12?
We have noticed that we get different performance when built on 2.6.11-5 vs
2.6.12-rc4.
thanks
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe
Management libraries leak resources (memory, file/directory handles).
Also a trailing whitespace fix in one place in libibcommon.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: libibumad/src/umad.c
===
--- libibumad/src
With a two-way handshake only the passive side accepts the
connection request (it_ep_accept() or dat_cr_accept()). IT-API
defines an optional *three-way* handshake where the active
side must *also* call it_ep_accept() before the final connection
establishment can proceed.
This does not map to iWA
On Thu, 2005-05-19 at 03:23, Michael S. Tsirkin wrote:
> Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > Subject: Re: [RFC] [PATCH] user_mad: Support RMPP on send side
> >
> > This looks OK to check in with one small comment on the following:
> >
> > - if (copy_to_user(buf, &packet->mad, size
Caitlin> I believe that an IT-API it_ep_accept() supplies private data
that it expects to be delivered to its peer when the three-way handshake
option is selected.
Both IT-API it_ep_accept() and DAT dat_cr_accept() cause the provider at
the passive side to send a --REP--,
so how --RTU-- is relat
Roland, the following code snippet:
const char foo[]="Michael Tsirkin";
ibv_reg_mr(ctx->pd, foo, strlen(foo), 0);
exposes two problems with ibv_reg_mr:
1. Compiling this code I get a warning:
warning: passing arg 2 of `ibv_reg_mr' discards qualifiers
from pointer target type.
Same if foo is dec
Libor, I'm looking at sdp_link.c, and I dont see any lock
protecting the info_list linked list.
What prevents sdp_path_info_lookup from being called while
sdp_path_info_create or sdp_path_info_destroy is in progress?
Thanks,
--
MST - Michael S. Tsirkin
___
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [RFC] [PATCH] user_mad: Support RMPP on send side
>
> This looks OK to check in with one small comment on the following:
>
> - if (copy_to_user(buf, &packet->mad, sizeof packet->mad))
> + if (copy_to_user(buf, &packet->mad,
> +
Quoting r. Grant Grundler <[EMAIL PROTECTED]>:
> Subject: diff-perftest-07 replace pp_get_local_lid()
>
> Hi Michael,
>
> Following patch to rdma_lat.c:
> o replaces pp_get_local_lid with code from ibv_pingpong.
> This calls into libibverbs instead of fishing around in /sys FS.
>
> o makes two
Quoting r. Grant Grundler <[EMAIL PROTECTED]>:
> Subject: [PATCH] rewrite perftest/README
>
> Michael,
> Here's a complete rewrite of the README file.
> Should make it easier for people to understand
> o how to build
> o run
> o interpret results
>
>
> I'd still like to add abi
64 matches
Mail list logo
