I am using the system level queue. If we think that using our own MAD queue
is better, I will do that. I was thinking more along the lines of a single
workqueue for all MAD services, with one per processor, rather than a
workqueue per port, however.
I don't think the system keventd queue is
On Wed, 2004-10-06 at 13:23, Sean Hefty wrote:
The only byte swapping is done by the HCA not in the MAD layer or
client.
Mthca performs byte-swapping on the qkey in both of these cases.
Oops. Forgot about the driver :-(
At this point, I think the openib stack needs byte-ordering reworked,
On Wed, 2004-10-06 at 19:01, Sean Hefty wrote:
Here are some modifications to support timing out send MADs in
the access layer. I haven't tested this code beyond building it,
Is this still the case ? I noticed you burning the midnight oil last
night :-)
but wanted to make it available for
On Thu, 2004-10-07 at 10:19, Roland Dreier wrote:
I think it's OK to have a single workqueue for the whole MAD layer;
it's probably
not scalable to systems with a huge number of HCAs,
Any idea on where the cutoff for huge is or is this likely to be a
matter of experience ? Is it at least 2 ?
Any idea on where the cutoff for huge is or is this likely to be a
matter of experience ? Is it at least 2 ? What about 4 ?
Depends on the number of CPUs and the workload. The single workqueue
design starts being inefficient when you start getting idle time because every
workqueue thread is
On Wed, 2004-10-06 at 19:01, Sean Hefty wrote:
but wanted to make it available for review. There are a few race
conditions that need to be avoided when handling timeouts, so if
it looks like something was missed, let me know.
If it is not too much work, I would prefer this broken into 2
ib_smi: Trim methods needed to Get, Set, and TrapRepress
Also, eliminate some compiler warnings
Index: ib_smi.c
===
--- ib_smi.c(revision 947)
+++ ib_smi.c(working copy)
@@ -319,7 +319,7 @@
}
Only purpose of patch is to reformat code to keep it within 80 columns. The resulting
code highlights some areas where we may want to look at restructing it.
- Sean
Index: access/ib_mad.c
===
--- access/ib_mad.c (revision
On Thu, 7 Oct 2004 11:49:43 -0700
Sean Hefty [EMAIL PROTECTED] wrote:
Only purpose of patch is to reformat code to keep it within 80 columns. The
resulting code highlights some areas where we may want to look at restructing it.
- Sean
Same purpose - different file... SMI code, which was
On Thu, 2004-10-07 at 14:49, Sean Hefty wrote:
Only purpose of patch is to reformat code to keep it within 80 columns.
Thanks. Applied.
-- Hal
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To
On Thu, 2004-10-07 at 14:55, Sean Hefty wrote:
On Thu, 7 Oct 2004 11:49:43 -0700
Sean Hefty [EMAIL PROTECTED] wrote:
Only purpose of patch is to reformat code to keep it within 80 columns. The
resulting code highlights some areas where we may want to look at restructing it.
- Sean
Here's a patch that just renames a few structure members related to MADs. The renamed
variables will be used when handling MAD timeouts.
- Sean
-- Index: access/ib_mad_priv.h
===
--- access/ib_mad_priv.h(revision 955)
+++
ib_smi: Support LID routed Gets and Sets in SMA
Index: ib_smi.c
===
--- ib_smi.c(revision 955)
+++ ib_smi.c(working copy)
@@ -125,7 +125,7 @@
case IB_MGMT_CLASS_SUBN_DIRECTED_ROUTE:
return
13 matches
Mail list logo
