Hello!
I was looking at IB spec rev 1.2 and I noted a difference with
how gen2 behaves.
11.4.2 COMPLETION QUEUE OPERATIONS
11.4.2.1 POLL FOR COMPLETION
The following appeared in IB spec rev 1.1 first, actually:
The number of bytes transferred.
The number of bytes transferred is returned in Work
On Mon, 2005-01-03 at 12:12, Grant Grundler wrote:
> Some workloads that Jamal cares about (routing) only need 2 cpus.
What bothers me is more the complexity this has introduced more than
the workload. OTOH, 1-2% improvement posted by Roland is good
justification.
cheers,
jamal
___
The server housing openib.org will be moving to its new location on
Wednesday, 1/5/2004 @ 3PM PST. The expected down time will be 60
minutes. All services on openib.org (http, subversion, mail lists) will
be down for the one-hour period.
--
Michael Lee <[EMAIL PROTECTED]>
HPCN Sandia
_
Michael> By the way,
Michael> http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]
Michael> already has Roland's patches, and I thought that was what
Michael> Linus uses for kernel releases, right, Roland?
Yes, the core kernel drivers are all merged in Linus's kernel
already.
Hello!
Quoting r. Roland Dreier ([EMAIL PROTECTED]) "[openib-general] Re: [2.6 patch]
infiniband: possible cleanups":
> Adrian> Is there an ETA when the debugging modules and the modules
> Adrian> in development will be merged into the kernel?
>
> Once they're ready and pass review on lkm
Adrian> Is there an ETA when the debugging modules and the modules
Adrian> in development will be merged into the kernel?
Once they're ready and pass review on lkml.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.
Hello!
Quoting r. Adrian Bunk ([EMAIL PROTECTED]) "[openib-general] Re: [2.6 patch]
infiniband: possible cleanups":
> On Mon, Jan 03, 2005 at 11:45:53AM -0800, Roland Dreier wrote:
> > Thanks, I've applied the changes adding "static" to our tree. I'm
> > holding off on the "#if 0" changes since s
Hello!
Quoting r. Hal Rosenstock ([EMAIL PROTECTED]) "Re: [openib-general] Re: tvflash
HCA numbering with multiple HCAs":
> On Mon, 2005-01-03 at 16:31, Michael S. Tsirkin wrote:
> > Or use mstflint for flashing which already does exactly that.
> > Check it out from https://openib.org/svn/trunk/co
On Mon, Jan 03, 2005 at 11:45:53AM -0800, Roland Dreier wrote:
> Thanks, I've applied the changes adding "static" to our tree. I'm
> holding off on the "#if 0" changes since some is code useful for
> debugging modules and other code is used by modules in development.
Is there an ETA when the debu
On Mon, 2005-01-03 at 16:31, Michael S. Tsirkin wrote:
> Or use mstflint for flashing which already does exactly that.
> Check it out from https://openib.org/svn/trunk/contrib/mellanox/mstflint/
Does mstflint handle .mlx files or .bin files (or both) for the firmware
?
-- Hal
__
On Thu, Dec 23, 2004 at 11:52:28AM -0800, Tom Duffy wrote:
> I have seen a lot of projects who have only autogen.sh in the source
> control, but then have a tarball available that has a generated
> configure script for the user to run.
Yes, automate the downloadable stuff.
e.g.:
http://cvs
Hello!
Quoting r. Ronald G. Minnich (rminnich@lanl.gov) "Re: [openib-general] Re:
tvflash HCA numbering with multiple HCAs":
>
>
> On Mon, 3 Jan 2005, Michael S. Tsirkin wrote:
>
> > Or use mstflint for flashing which already does exactly that.
>
> I have not used this, does it still require t
On Mon, 3 Jan 2005, Michael S. Tsirkin wrote:
> Or use mstflint for flashing which already does exactly that.
I have not used this, does it still require that you insmod three modules
to work?
ron
___
openib-general mailing list
openib-general@openi
On Mon, 2005-01-03 at 16:12, Johannes Erdfelt wrote:
> Why not just append to the previous log file? That's what pretty much
> every other daemon I've used does and what I would expect.
That seems like a better way to handle it. Any objections ?
OpenSM also creates some other files in /tmp. Shoul
Hello!
Quoting r. Roland Dreier ([EMAIL PROTECTED]) "Re: [openib-general] Re: tvflash
HCA numbering with multiple HCAs":
> Johannes> Or we can fix the order you see here as well as add
> Johannes> specifying devices by the domain, bus, device.
>
> That's my current plan.
>
> - R.
Or us
On Mon, 2005-01-03 at 16:03 -0500, Hal Rosenstock wrote:
> On Mon, 2005-01-03 at 14:48, Tom Duffy wrote:
> > It would be cool if the log file was saved with the pid in the name as
> > well since then it wouldn't delete the old one when you restarted the
> > sm.
>
> Dealing with the too many log fi
On Mon, Jan 03, 2005, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-03 at 14:48, Tom Duffy wrote:
> > It would be cool if the log file was saved with the pid in the name as
> > well since then it wouldn't delete the old one when you restarted the
> > sm.
>
> Dealing with the too many
On Mon, 2005-01-03 at 14:48, Tom Duffy wrote:
> It would be cool if the log file was saved with the pid in the name as
> well since then it wouldn't delete the old one when you restarted the
> sm.
Dealing with the too many log files (and space) issue is probably better
than deleting the old log fi
On Mon, Jan 03, 2005, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> Couldn't tvflash still determine the same order mthca would regardless
> of whether it is loaded or not ? That number wouldn't be terribly
> meaningful unless mthca were loaded previously (and subsequently
> removed) or the machine r
On Mon, 2005-01-03 at 14:46, Johannes Erdfelt wrote:
> Or we can fix the order you see here as well as add specifying devices
> by the domain, bus, device.
>
> The problem here is that the 2.6 version of libpci returns devices in
> reverse order to the 2.4 version which is causing tvflash to creat
On Mon, 2005-01-03 at 14:53, Johannes Erdfelt wrote:
> Check my other reply, but the short answers are: The numbering for mtcha
> is decided by the PCI core and how it scans PCI devices and calls the
> mtcha callback. tvflash can't use the same numbering scheme because that
> would require the IB d
On Mon, Jan 03, 2005, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-03 at 14:40, Roland Dreier wrote:
> > It is true that the PCI device order
> > may be different between the kernel and tvflash. Maybe the best
> > solution is to specify devices by PCI domain, bus, device rather than
On Mon, 2004-12-27 at 12:55 +0200, shaharf wrote:
> Tom,
> I debugged the opensm a little, and it seems like a simple
> opensm bug. Somehow the destination lid of the report target was not
> found, and as there were no checks for that, the opensm faulted. I added
> the missing checks. I don't
On Mon, 2005-01-03 at 14:40, Roland Dreier wrote:
> Hal> Hi, Has flashing HCAs when there are multiple HCAs in the
> Hal> host been tried ? There seems to be some confusion on the
> Hal> HCA numbering in tvflash as shown by the GUIDs below. I
> Hal> needed to tvflash -h 1 to update
Johannes> Although I guess that would require the IB drivers to be
Johannes> loaded to be able to flash a device.
Right, that's why I would prefer not to tie tvflash in with
/sys/class/infiniband (because we may be flashing an HCA with firmware
too corrupted for the driver to load).
J
Adrian> Is it planned to add other objects to ib_sa and/or
Adrian> ib_umad, or would you accept a patch to rename the source
Adrian> files?
I think both modules are very close to the point where it would make
sense to split into multiple files, so I would prefer to leave things
as they
On Mon, Jan 03, 2005, Roland Dreier <[EMAIL PROTECTED]> wrote:
> Hal> Hi, Has flashing HCAs when there are multiple HCAs in the
> Hal> host been tried ? There seems to be some confusion on the
> Hal> HCA numbering in tvflash as shown by the GUIDs below. I
> Hal> needed to tvflash -
Thanks, I've applied the changes adding "static" to our tree. I'm
holding off on the "#if 0" changes since some is code useful for
debugging modules and other code is used by modules in development.
Thanks,
Roland
___
openib-general mailing list
open
Hal> Hi, Has flashing HCAs when there are multiple HCAs in the
Hal> host been tried ? There seems to be some confusion on the
Hal> HCA numbering in tvflash as shown by the GUIDs below. I
Hal> needed to tvflash -h 1 to update mthca0.
Yes, I've tried it and it works. It is true tha
Tom> Remove debug printk.
Thanks, applied to subversion.
- 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-genera
On Mon, 2005-01-03 at 13:36, Tom Duffy wrote:
> On Thu, 2004-12-23 at 13:46 -0800, Tom Duffy wrote:
> > Increase the size of ca_type to accommodate string printed out of ARBEL
> > in TAVOR compat mode.
>
> Any reason not to take this patch?
>
> > Index: gen2/trunk/src/userspace/include/umad.h
> >
Remove debug printk.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: drivers/infiniband/core/sysfs.c
===
--- drivers/infiniband/core/sysfs.c (revision 1447)
+++ drivers/infiniband/core/sysfs.c (working copy)
@@ -188,8 +18
On Thu, 2004-12-23 at 13:46 -0800, Tom Duffy wrote:
> Increase the size of ca_type to accommodate string printed out of ARBEL
> in TAVOR compat mode.
Any reason not to take this patch?
> Index: gen2/trunk/src/userspace/include/umad.h
> =
drivers/infiniband/core/Makefile contains the following:
<-- snip -->
...
ib_sa-y := sa_query.o
ib_umad-y :=user_mad.o
<-- snip -->
Is it planned to add other objects to ib_sa and/or ib_umad, or would you
accept a patch to rename the source files?
The patch below contains the following possible cleanups for the current
infiniband code:
- make needlessly global code static
- don't build the completely unused core/fmr_pool.c
- #if 0 the following EXPORT_SYMBOL'ed but unused functions:
- core/device.c: ib_modify_device
- core/device.c: ib_
On Mon, Jan 03, 2005 at 06:07:00PM +0100, Eric Lemoine wrote:
> If I understand correctly, LLTX aims at avoiding cache misses on lock
> variables (because of cacheline bouncing). So the effect of LLTX
> should increase as the number of CPUs not sharing the same cache
> increases. And two CPUs might
On Mon, 03 Jan 2005 08:54:59 -0800, Roland Dreier <[EMAIL PROTECTED]> wrote:
> Eric> What are your machines? In particular, how many CPUs do they have?
>
> Dual Xeons with HT on, so they look like 4 CPUs.
If I understand correctly, LLTX aims at avoiding cache misses on lock
variables (because
Eric> What are your machines? In particular, how many CPUs do they have?
Dual Xeons with HT on, so they look like 4 CPUs.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscri
On Mon, 03 Jan 2005 07:57:14 -0800, Roland Dreier <[EMAIL PROTECTED]> wrote:
> jamal> Andi or anyone else - has anyone really done perfomance
> jamal> analysis of LLTX (with anything other than loopback) and
> jamal> shown it has any value? Maybe time to just shoot the damn
> jamal>
this piece:
-
+
+ /* And release queue */
+ spin_unlock(&dev->queue_lock);
}
-
Isnt there a possibility (higher as you increase number of processors)
that you will spin for a long time in _the driver_ waiting for the queue
loc
jamal> Andi or anyone else - has anyone really done perfomance
jamal> analysis of LLTX (with anything other than loopback) and
jamal> shown it has any value? Maybe time to just shoot the damn
jamal> thing.
For the IPoIB driver, it seems to be worth a couple percent. It's
hard to g
On 03 Jan 2005 10:04:21 -0500, jamal <[EMAIL PROTECTED]> wrote:
> this piece:
> -
> +
> + /* And release queue */
> + spin_unlock(&dev->queue_lock);
> }
> -
>
> Isnt there a possibility (higher as you increase number of proces
42 matches
Mail list logo
