Hi
all,
I
know I am new to this project and I must be naïve but I want to understand few
things concerning the openib architecture. In the course of learning the openib
gen 2 stack and preparing to port the opensm to it (which is my current task),
I have encountered few
shaharf It seems to me that the major design approach is to do
shaharf everything in the kernel but let user mode staff access
shaharf to the lower levels to enable performance sensitive
shaharf applications override all kernel layers. Am I right?
No. The reason everything is in
On Tue, 2004-11-09 at 12:07, Roland Dreier wrote:
multiport bonding/failover
(although my feeling is that it would be better to extend the existing
bonding driver rather than trying to put this in the IPoIB driver),
I'm not clear what the tradeoffs / pros / cons of the two approaches
(use
mad: Add port number to MAD thread names
Index: mad.c
===
--- mad.c (revision 1259)
+++ mad.c (working copy)
@@ -1843,6 +1843,7 @@
int ret, cq_size;
struct ib_mad_port_private *port_priv;
unsigned
Nitin Hande wrote:
Hal/Roland,
Hal Rosenstock wrote:
On Tue, 2004-11-09 at 12:07, Roland Dreier wrote:
multiport bonding/failover
(although my feeling is that it would be better to extend the existing
bonding driver rather than trying to put this in the IPoIB driver),
I'm not clear
At 09:41 AM 11/18/2004, Grant Grundler wrote:
On Thu, Nov 18, 2004 at
06:14:47PM +0200, shaharf wrote:
Personally, I think that IB verbs (vapi) are so complicated
that
another level of abstraction is required. PDs, MRs, QPs QP state
machine,
PKEYs, MLIDs and other curses, why should a module
When starting ib_mthca, I got the following log messages. I am running with the
latest
bits. It may also have been related to the startup of a switch or SM at the
same
instant in time.
-- Hal
Nov 18 13:32:06 localhost kernel: ib_mthca: Mellanox InfiniBand HCA driver
v0.06-pre (November 8,
I'm about to send out a draft version of the kernel submission
patches. I am using the same script I'll use to send the patches to
linux-kernel, so look for the thread starting
[PATCH][RFC/v1][0/12] Initial submission of InfiniBand patches for review
All comments/corrections/criticisms,
I'm very happy to be able to post an initial version of InfiniBand
patches for review. Although this code should be far closer to kernel
coding standards than previous open source InfiniBand drivers, this
initial posting should be treated as a request for comments and not a
request for inclusion;
I'm very happy to be able to post an initial version of InfiniBand
patches for review. Although this code should be far closer to kernel
coding standards than previous open source InfiniBand drivers, this
initial posting should be treated as a request for comments and not a
request for inclusion;
Add the appropriate lines to drivers/Kconfig and drivers/Makefile so
that the kernel configuration and build systems know about drivers/infiniband.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Index: linux-bk/drivers/Kconfig
===
Spam detection software, running on the system openib.ca.sandia.gov, has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or block
similar future email. If you have any questions, see
[EMAIL PROTECTED] for
Add the 0x1b ioctl magic number used by ib_umad module to
Documentation/ioctl-number.txt.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Index: linux-bk/Documentation/ioctl-number.txt
===
---
Add ipv6_ib_mc_map() to convert IPv6 multicast addresses to IPoIB
hardware addresses, and add support for autoconfiguration for devices
with type ARPHRD_INFINIBAND.
The mapping for multicast addresses is described in
http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-07.txt
Add OpenIB maintainers information to MAINTAINERS.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Index: linux-bk/MAINTAINERS
===
--- linux-bk.orig/MAINTAINERS 2004-11-17 19:52:19.0 -0800
+++ linux-bk/MAINTAINERS
Johannes You mean
Johannes char name[sizeof ib_mad123 + 1];
Johannes right? :)
No, actually sizeof a string includes the trailing nul. Try the
following program:
int main() { printf(%d\n, (int) sizeof 123); }
I bet it prints 4 :)
- R.
Hmm... looks like our spamassassin is a little trigger happy :)
- R.
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
modprobe: page allocation failure. order:6, mode:0x20
[d09098cc] mthca_alloc_sqp+0x6c/0x420 [ib_mthca]
It's not actually a crash. It's just failing to allocate 2048 * 72
bytes of bus-coherent memory (send queue depth time size of a UD
header) while creating a special QP. The system
On Thu, Nov 18, 2004, Roland Dreier [EMAIL PROTECTED] wrote:
Johannes You mean
Johannes char name[sizeof ib_mad123 + 1];
Johannes right? :)
No, actually sizeof a string includes the trailing nul. Try the
following program:
int main() { printf(%d\n, (int)
Peter why not make this change to IPOIB_HW_ADDR_LEN now?
Not a bad idea (although I guess it should be IPOIB_ALEN to match the
rest of the kernel). I wonder where to put the value though... is it
really worth creating a linux/if_ipoib.h for this value?
- R.
On Thu, 2004-11-18 at 14:00, Roland Dreier wrote:
Johannes You mean
Johannes char name[sizeof ib_mad123 + 1];
Johannes right? :)
No, actually sizeof a string includes the trailing nul. Try the
following program:
int main() { printf(%d\n, (int) sizeof 123); }
Tom Yeah, I think since everything else has one, ipoib should as
Tom well. There are some pretty short files in there like
Tom if_cablemodem.h or if_strip.h.
Good point. It's pretty hard to beat if_strip.h for brevity...
OK, I'll update the patches.
Thanks,
Roland
I committed this change, which should help a little
(pci_alloc_consistent() is implicitly GFP_ATOMIC).
- R.
Index: infiniband/hw/mthca/mthca_qp.c
===
--- infiniband/hw/mthca/mthca_qp.c (revision 1265)
+++
On Thu, 2004-11-18 at 14:55, Roland Dreier wrote:
Hal Is it also worth pointing out about multicast vis a vis IB ?
I didn't think so, because having to join a multicast group with the
SA is conceptually similar to having to program a multicast hash table
for an ethernet NIC or something
Hal Yes and no. While it is the appears the same in terms of the
Hal host (and Linux already handles part of the problem, the
Hal semantics are not as rich as they need to be for IB. I am
Hal referring to knowing whether to join as a send only member,
Hal non member, or full
On Thu, 2004-11-18 at 15:41 -0500, Hal Rosenstock wrote:
One more thing:
Do we also want to say something about no SM right now ? Or is that
putting a cosmic kick me sign on ?
Actually, I thought we agreed that this was necessary to have before we
submit to lkml. At least for inclusion. How
Hal Rosenstock wrote:
Anyhow, we are within days of starting on this.
There are 2 main portions of this:
1. Port to gen2 API
2. Fix build
The other aspects can wait if necessary.
How long before we need the first part ? Is there any expectation on how
long code review would last ? Or would they
Hal Although IB has a special join mode intended to support IP
Hal multicast routing (non member), as no means to identify
Hal different multicast styles has yet been determined, all joins
Hal are currently full member. We are looking for guidance in how
Hal to solve this.
OK,
On Thu, Nov 18, 2004 at 10:58:50AM -0800, Roland Dreier wrote:
Add ip_ib_mc_map() to convert IPv$ multicast addresses to IPoIB
hardware addresses.
...
+ addr= ntohl(addr);
...
+ buf[19] = addr 0xff;
+ addr = 8;
+ buf[18] = addr 0xff;
+ addr = 8;
+ buf[17] =
Grant Can the same be done instead with the following?
I think only your second proposal is correct (since addr is in network
byte order). However, the existing ip_eth_mc_map() function in
net/ip.h uses the one byte at a time method, so I thought we might
as well follow existing practice.
On Thu, 2004-11-18 at 11:01 -0800, Roland Dreier wrote:
Hmm... looks like our spamassassin is a little trigger happy :)
Well since Roland is sending us all spam I can either boot him off the
list or increase the spamassassin threshold. :) I decide to increase
the threshold to 7.5 (all the
On Thu, Nov 18, 2004 at 02:25:46PM -0800, Matt Leininger wrote:
On Thu, 2004-11-18 at 11:01 -0800, Roland Dreier wrote:
Hmm... looks like our spamassassin is a little trigger happy :)
Well since Roland is sending us all spam I can either boot him off the
list or increase the
32 matches
Mail list logo
