There is no way to enable this option via make menuconfig. It is only
enabled if some other subsystem requires it by adding this to their
Kconfig:
select GENERIC_ALLOCATOR
I know, but what I'm saying is that distros tend to enable all drivers
so in practice it will be
I'm not yet convinced the problem exists. I would suggest look at RHEL5.
If that has genalloc enabled its a good indication that you don't
need to put a copy of it in OFED.
Since genalloc is there since 2.6.13, you can also look at SLES10 -
most distros have it in I imagine.
the GPL only code from GPL/BSD code so
that people will know what is GPL/BSD and what is truely GPL only.
-Original Message-
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 11, 2007 2:56 PM
To: Woodruff, Robert J
Cc: Chet Mehta; Steve Wise; Betsy Zeller
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: ipoib ipv6 multicast joins, was: multicast code/merge status
Hal Rosenstock wrote:
(*) there are some more issues here which need to be addressed, see
for example the Some SMs don't support send-only yet weird comment
at
Subject: Re: [PATCHv4] IPoIB CM Experimental support
Roland, can we queue this for 2.6.21?
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCHv4] IPoIB CM Experimental support
- Using path MTU discovery, multicast and UDP traffic to UD mode now work,
only a small number of packets is dropped.
How does this work? What happens if I set my MTU to 8K and send a
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCHv4] IPoIB CM Experimental support
Also, I haven't really looked yet, but how does the connected mode
patch interact with the NAPI patches?
The latest version uses prov-cq for all RX packets, so
it's trivial to merge it with NAPI if
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCHv4] IPoIB CM Experimental support
Roland, can we queue this for 2.6.21?
Yes, once I have a chance to really read it over.
Maybe for-mm for now?
--
MST
___
openib-general mailing
Quoting Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: multicast code/merge status
Sean Hefty wrote:
Other then that, as we discussed in SC06 there are some changes that
need to be integrated in the code to allow for interoperability
between a multicast rdma cm based app to IPoIB,
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH/RFC] IB/ipoib: add selective tx signaling
I played with this idea too a long time ago, but I don't think this
sort of naive implementation is acceptable. Having packets that take
a potentially unbounded amount of time before the
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [PATCH 1/2] OpenSM: Add socket support to OpenSM console
diff --git a/osm/opensm/configure.in b/osm/opensm/configure.in
index 1ccf5c6..2d52675 100644
--- a/osm/opensm/configure.in
+++ b/osm/opensm/configure.in
@@ -62,6 +62,22
On 1/10/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: multicast code/merge status
Since Voltaire requested this code to be in OFED 1.2, could you please
clarify
whether the code in Sean's branch is in the shape you want
We kind of do it together :)
I try to review everything, Vlad does the final build/integration.
The Cc does not matter much, I read openib-general.
Quoting Steve Wise [EMAIL PROTECTED]:
Subject: [Fwd: [openib-general] ofed_1_2 / Chelsio Question]
Hey Michael,
I didn't CC you directly on this. I
Subject: Re: [PATCH 7/7] libcxgb3: Update libcxgb3 for new libibverbs driver
handling
So libibverbs 1.1 will be part of ofed 1.2?
That's the goal, and I guess you're counting on it for libcxg3
BTW, you can now drop d5b9ab3d7009b77ee45e98827e803205d322ce7d
since latest version of
This patch implements selective tx signaling for IPoIB.
Let's assume that the last tx packet you have sent is marked unsignalled.
Since you never free the skb, won't the TX watchdog get triggered?
--
MST
___
openib-general mailing list
Tests with iperf and netperf for unicast and multicast destinations show
an improvement in the ability of user applications to xmit packets.
Examples: Number of successful writes as reported by 30 seconds UDP_STREAM of
100 byte packets.
Tested with netperf on Dual CPU (64bit Intel Xeon
diff --git a/osm/opensm/configure.in b/osm/opensm/configure.in
index 1ccf5c6..2d52675 100644
--- a/osm/opensm/configure.in
+++ b/osm/opensm/configure.in
@@ -62,6 +62,22 @@ AC_ARG_ENABLE(debug,
esac],[debug=false])
AM_CONDITIONAL(DEBUG, test x$debug = xtrue)
+dnl Console over a socket
I don't think that holding the skb too long is a trigger for somethink.
Are you sure? We are not talking about too long here - unsignalled TX packet
will never get a completion. As far as I can see, __kfree_skb will
1. call dst_release - so this patch might keep a reference on dst
Further, could you please clarify: when compiled in, is opensm listening on
a socket
by default or does it need to be enabled with a run-time option?
I hope it's the later.
Not currently but I think that is also easily changed as well.
Probably a good idea - opening a port involves a
Further, could you please clarify: when compiled in, is opensm
listening on a socket
by default or does it need to be enabled with a run-time option?
I hope it's the later.
Not currently but I think that is also easily changed as well.
Probably a good idea - opening a
Tests with iperf and netperf for unicast and multicast destinations show
an improvement in the ability of user applications to xmit packets.
Examples: Number of successful writes as reported by 30 seconds UDP_STREAM
of 100 byte packets.
Tested with netperf on Dual CPU (64bit Intel Xeon
2. call skb-destructor if not NULL - this is responsible for socket buffer
accounting
I addressed the issue of the socket buffer accounting in the openning message.
I don't see it as a problem but more than an note to the user. Don't you
think?
No, I actually think this is a severe
+/*
+ * Limit CM msg timeouts to something reasonable.
+ * 8 seconds, with up to 15 retries, gives per msg timeout of 2 min.
+ */
+#define IB_CM_MAX_TIMEOUT 21
OK... (although 8 seconds seems a little short -- it seems a somewhat
longer timeout could be legitimate on a
We also need to decide on the ib_req_notify_cq() issue.
Let's clarify - do you oppose doing copy_from_user from a fixed
address passed in during setup?
If OK with you, this seems the best way as it is the least controversial
and least disruptive one.
--
MST
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH RFC] return qp pointer as part of ib_wc
Looking at this in depth, I see one very iffy part:
@@ -652,7 +653,7 @@ static void build_smp_wc(u64 wr_id, u16 slid, u16
pkey_index, u8 port_num,
wc-pkey_index = pkey_index;
this is now returning a pointer to the MAD layer's internal QP. I
guess this is OK -- the only user of the pointer seems to be the mthca
MAD_IFC command, which just grabs the QP number anyway. But I just
wanted to point out this wart...
What's the problem with this?
Thank you for the information, I may change my mind to require
IPoIB to run newer version of HP-MPI on OFED 1.2, if I don't find other
way to easily establish IB connection dynamically between two process
groups with dynamic size.
I'm not really sure what your needs are, but it's not
What I need is that, without IPoIB, how do I wire IB connection ?
Currently with Verbs API, it is an alltoall QP number exchange. I want
to remove the alltoall
QP number exchange in MPI dynamic process.
Well, does your MPI implementation currently use librdmacm?
If not, you don't currently
If not, you don't currently have a dependency on IPoIB and
probably have no reason to introduce one.
As I said, the problem is the alltoall QP number exchange. I hope that a
process can only provide one piece of information(such as ip/port in
TCP/IP) so that all other processes have the
, and it solves real problem with
misbehaved remote. I did say this works for us, did I not?
Let's have this in 2.6.20 - is there need to resend?
Acked-by: Michael S. Tsirkin [EMAIL PROTECTED]
There are 3 Sean's patches I think we need
rdma_ucm: fix reporting events with invalid user context
FYI.
The infinite loop fix looks potentially relevant, so I guess
we should update staging. Sasha?
- Forwarded message from Junio C Hamano [EMAIL PROTECTED] -
Subject: [ANNOUNCE] GIT 1.4.4.4
Date: Mon, 8 Jan 2007 05:30:50 +0200
From: Junio C Hamano [EMAIL PROTECTED]
The latest
into 2.6.20?
Arbel does not actually have a concept of MTT segment.
So we should set MTT segment size to 64 bit (1 entry) for memfree,
otherwise we might be wasting as much as 87% of MTT entries.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
diff --git a/drivers/infiniband/hw/mthca
- modified the qp_num - qp ptr patch to include cxgb3.
If you don't mind, this might be better as a separate patch - it's just easier
for me to continue pushing this upstream if I can just copy it from OFED
sources.
--
MST
___
openib-general mailing
a large
value ( 1 hour) as a service timeout.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
A very similiar code is in OFED 1.1 (we chickened out and had a module parameter
to disable this just in case, but I don't think its really needed upstream).
Acked-by: Michael S. Tsirkin [EMAIL PROTECTED
Core changes are required for the T3 driver. This includes the addition
of a udata pointer parameter to the ib_req_notify_cq() provider method.
This is still being discussed on the openib-general list and I'll update
it accordingly once we finalize the solution.
So what I plan to do is,
Subject: Re: [PATCH untested] IB/mthca: avoid wasting MTT enties on memfree
Have you tested this?
No, didn't I make this clear? Sorry. I'm not in the lab at the moment,
and my laptop does not have infiniband.
That's why it says untested in the subject :).
I think it increases the amount of
what is a network library?
openpgm, openib are some but but I am looking for one that is a few
levels higher or abstracted. I am looking for around 3 or 4 calls to
send a message, something like connection, disconnect send and receive.
PGM is transport level, isn't it?
So a few levels
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH RFC] return qp pointer as part of ib_wc
This change makes sense to me. Does anyone object to queueing this
for 2.6.21?
And for-mm, pls: last version of IPoIB CM patch needs this.
--
MST
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: 2.6.20: outstanding patches and issues
fix_query_qp_in_reset.patch
will merge
ib_verbs_h_missing_kref.patch
does this actually fix any compilation problems? if not I think it's
better for 2.6.21.
2.6.21 then.
probably
gives this to us for free, but the following patch makes this assumption
explicit.
Pls review.
Warning: untested patch.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
I see now this is broken. Working on an updated patch.
--
MST
Subject: [PATCHv5 5 of 5] IB/mthca: reserved MTTs and memory alignment issues
This should have been [PATCHv2 5 of 5], but oh well.
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
with values that are all high powers of
2, but with new module option code this might not be the case anymore).
And since we access some of them from CPU and some from hardware, we
really want to give different tables separate dma cache lines too.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED
Fix compilation errors on ia64 that are caused by the definition of
sg_dma_address and sg_dma_len in asm-ia64/pci.h instead of in
asm/scatterlist.h, as in other architectures.
tested on: ia64[sles10]; x86_64 [sles10,rh4]
Signed-off by: Yosef Etigin [EMAIL PROTECTED]
Looked at this again
Tziporet,
I'm in the process of adding the Chelsio T3 drivers to the OFED
repository and I have a question:
The HowTo kernel section you posted on the wiki sez to add the new files
to the repos directly via a git commit, but create patches for
modifications to existing files and put the
cache line at the same time.
2. reserved_mtts field has different meaning in Tavor and Arbel,
so we are wasting mtt entries on memfree. fix the Arbel case to match
Tavor semantics.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/infiniband/hw/mthca/mthca_main.c
,
and helps applications that want to bind to the same port
number for both IB and TCP/IP socket connection.
Acked-by: Michael S. Tsirkin [EMAIL PROTECTED]
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman
into the same cache line at the same time.
2. reserved_mtts field has different meaning in Tavor and Arbel,
so we are wasting mtt entries on memfree. fix the Arbel case to match
Tavor semantics.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/infiniband/hw/mthca
and Arbel,
so we are wasting mtt entries on memfree. fix the Arbel case to match
Tavor semantics.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
This works for me. OK to apply the series now?
Index: linux-2.6/drivers/infiniband/hw/mthca/mthca_main.c
Thanks, queued for 2.6.20. (And thanks for letting me know that this
patch should go for 2.6.20)
BTW, there were 3 Sean's patches that I think we need in 2.6.20
rdma_ucm: fix reporting events with invalid user context
rdma_ucm: fix struct ucma_event
rdma_cm: avoid port reuse after close
I
List of patches in OFED:
http://git.openfabrics.org/git/?p=~vlad/ofed_1_2/.git;a=history;f=kernel_patches/fixes/kernel_patches/fixes;hb=HEAD
Probably 2.6.20 material - Roland, could you please approve you got all these?
fix_query_qp_in_reset.patch
ib_verbs_h_missing_kref.patch
[Felix Marti] In addition, is arming the CQ really in the performance
path? - Don't apps poll the CQ as long as there are pending CQEs and
only arm the CQ for notification once there is nothing left to do? If
this is the case, it would mean that we waste a few cycles 'idle'
cycles.
, but the following patch makes this assumption
explicit.
Pls review.
Warning: untested patch.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/infiniband/hw/mthca/mthca_profile.c
===
--- linux-2.6.orig
/
mailto:[EMAIL PROTECTED]
-Original Message-
From: Moshe Kazir
Sent: Monday, October 30, 2006 4:00 PM
To: 'Michael S. Tsirkin'
Cc: openib-general@openib.org; [EMAIL PROTECTED]
Subject: mstflint error on ppc64
Hi
-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 1eaf00e..cdc98b1 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -49,6 +49,8 @@ #include linux/in.h
ipoib_neigh_free is sometimes called while neighbour is still alive,
so it might have queued skbs. Fix skb leak in this case.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Hi, Roland!
I saw this potential issue when I went over the code.
What do you think?
diff --git a/drivers
Quoting r. [EMAIL PROTECTED] [EMAIL PROTECTED]:
I was going through the code send_bw.c(
https://openfabrics.org/svn/gen2/tags/openib-1.0-rc1/src/userspace/perftest/send_bw.c
).
This test is a pingpong test
I think that there's no ping pong in send_bw - it measures one way streaming
Quoting r. Chevchenkovic Chevchenkovic [EMAIL PROTECTED]:
Subject: Send_bw in UD
Hi,
Infiniband specification says that the completion notification in case of RC
occurs when the data has actually reached the destination buffer. Whereas for
UD it is given when the data is placed on the
diff --git a/libibcommon/include/infiniband/common.h
b/libibcommon/include/infiniband/common.h
index 83c0679..66afab0 100644
--- a/libibcommon/include/infiniband/common.h
+++ b/libibcommon/include/infiniband/common.h
@@ -114,11 +114,16 @@ #endif
#define ENUM_STR_DEF(enumname, last, val)
Quoting r. Roland Dreier [EMAIL PROTECTED]:
I would really like to understand why ehca does worse with NAPI. In
my tests both mthca and ipath exhibit various degrees of improvement
depending on the test -- but I've never seen performance get worse.
This is the main thing holding back merging
Subject: What could prevent a gen2 x86 client qp from doing RDMA_READ on a
gen1 PowerPC client?
Here is my next and hopefully last problem.
As described earlier I’m connecting a gen2 x86 clients to a gen1 PowerPC
server
Endian-ness issues?
FYI
A usual number of gitweb enhancements.
git-blame is probably the most interesting.
--
MST
---BeginMessage---
The latest feature release GIT 1.4.4 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.tar.{gz,bz2}(tarball)
With RC, you can send larger messages and hardware will perform the
fragmentation.
BTW, ibv_rc_pingpong/ibv_ud_pingpong are pingpong examples - they do not
attempt to measure maximum streaming bandwidth.
Look under the perftests directory for some benchmarks:
e.g. send_bw can measure bandwidth
ib_ucm_cleanup_events has file_mutex while calling ib_destroy_cm_id.
It seems this can deadlock since ib_destroy_cm_id flushes event
handlers, and ib_ucm_event_handler needs file_mutex, too.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
I'll be testing the following the next night
Quoting Sean Hefty [EMAIL PROTECTED]:
Subject: RE: IPoIB new multicast API patches oops
I have not been able to reproduce this crash on my systems, and even
instrumenting the code isn't helping me to locate the issue. Can you
apply the following patch on top of the previous patches, and let
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH] IB/ipoib: DMA alignment on ppc64
I don't think this is what's needed. The GRH leaves a gap of 40, so
getting rid of the skb_reserve() just means that DMA will start at an
offset of 40 rather than 44.
Ugh. Correct - unless the
Shouldn't ipoib_ib_dev_stop be void?
--
MST
___
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
Quoting Todd Rimmer [EMAIL PROTECTED]:
req_param.responder_resources= 4;
req_param.initiator_depth= 4;
These should not be hardcoded, but should come from a query of the CA
capabilities.
Whether is makes sense to query adapter or hard-code these fields depends
Quoting r. zhu shi song [EMAIL PROTECTED]:
Subject: Re: compile error
I download OFED-1.1.1.tar.gz and try to compile it
under FC5 with kernel 2.6.18. But there are errors
when compile ipoib_fs.c. see below:
Right. FC5 has a patched kernel, not a mainline 2.6.18 that OFED 1.1
supports.
Unaligned DMA is slow ppc64 systems - that's why this architecture
overrides NET_IP_ALIGN. IPoIB should take this into account and align
DMA on this platform.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Roland, what do you think?
This comes from reading linux/skbuff.h and asm
FYI
I don't see any updates openfabrics server needs.
--
MST
---BeginMessage---
The latest maintenance release GIT 1.4.3.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.3.5.tar.{gz,bz2} (tarball)
Following Sean's suggestion, I have let the nightly tests run with Roland's mad
patch
in addition to Sean's new multicast interface patches (v2), and got the
following crash:
Nov 9 10:59:43 sw084 kernel: NET: Unregistered protocol family 27
Nov 9 10:59:46 sw084 net.agent[25786]: remove event
Quoting Or Gerlitz [EMAIL PROTECTED]:
the CMA API addressing is based on **IP** addresses, so when
a client connects it provides the IP address of the server and
optionally the its src IP as well.
Once we get the GID that matches the IP, we can locate an extra path and arm it.
Read up on how
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: [openib-general] [RFC] [PATCH v2] rdma/ib_cm: fix APM support
Michael S. Tsirkin wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Protocols that rely on RC ACK for reliability guarantees (like SDP),
basically
do not make it possible
Quoting Or Gerlitz [EMAIL PROTECTED]:
I am using this patch series on top of Roland git
tree of few weeks ago (eg more or less as 2.6.19-rc3) and have not got
this crash.
Did you enable kernel debugging options?
The crash is much harder to reproduce without them.
We have these set:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Following the above suggestion would enable to print the
avg,min,max,median,std
statistics where now there is this delta approximation which i find less
informative.
I'm not very interested in adding the average/std statistics - our measurements
have
Quoting Or Gerlitz [EMAIL PROTECTED]:
Whouldn't it make more sense to get one time stamp before the i'th posting
and one tstamp after the i'th completion is reaped from the cq?
That's what we do, anyway - look how this works:
stamp[0]
post
poll
stamp[1]
post
poll
stamp[2]
so stamp[i] is
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: questions and a comment on the perftest package
Michael S. Tsirkin wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Whouldn't it make more sense to get one time stamp before the i'th posting
and one tstamp after the i'th completion
I don't see who does the -pong here, its a client doing rdma read from
(rdma write to) a server.
Correct for rdma read.
Rdma write is a bit more involved - although merging lat/bw tests there
is also a good idea IMO. Basically, I think we'll need to do polling at
the server side, and do a
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: [RFC] [PATCH v2] rdma/ib_cm: fix APM support
Memo to me: read comments about missing functionality...
Fixed an issue with the previous patch not having the right pkey
when forwarding LAP messages to the user.
With this patch, I'm able to
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: RE: [RFC] [PATCH v2] rdma/ib_cm: fix APM support
BTW, just to clarify, in CMA pieces are still missing for APM support.
Is that right?
Correct - the CMA does not provide path failover capabilities.
Is this something that you're wanting
Quoting Sean Hefty [EMAIL PROTECTED]:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 3faa182..d90f804 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -60,14
I tried using ifconfig to limit the ipoib mtu.
Once I do this on *either* both server and client, or only on the client side,
UDP seems to stop working:
#ifconfig ib0 mtu 512
#netperf -c -C -H 11.4.3.68 -f M -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH 3/7] IB/ipoib - Use the new verbs DMA mapping functions
For example, ib_send_wr/ib_recv_wr could have an *optional* void *data
field. And we could have a rule that ULP must *either* pass in the void
*data, and do dma
Quoting r. Eitan Zahavi [EMAIL PROTECTED]:
But you can check out just the infiniband part of the tree:
git checkout master `git-ls-tree -r --name-only master \
include/rdma include/scsi/srp.h drivers/infiniband \
Documentation/infiniband ofed_scripts
Quoting r. Ralph Campbell [EMAIL PROTECTED]:
diff -r f37bd0e41fec drivers/infiniband/ulp/ipoib/ipoib_ib.c
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c Thu Oct 26 21:44:41 2006 +0700
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c Thu Oct 26 12:37:09 2006 -0800
@@ -109,9 +109,8 @@ static int
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: static ARP entries for IPoIB?
I'd like to create static ARP entries for some IPoIB
devices. The arp (8) command that I'm using doesn't
know about ARPHRD_INFINIBAND (this is arp version 1.88
from net-tools-1.60-583.4.src.rpm,
FYI.
I don't see anything significant here.
- Forwarded message from Junio C Hamano [EMAIL PROTECTED] -
Subject: [ANNOUNCE] GIT 1.4.3.4
Date: Sun, 5 Nov 2006 11:01:45 +0200
From: Junio C Hamano [EMAIL PROTECTED]
The latest maintenance release GIT 1.4.3.4 is available at the
usual
Quoting r. Eitan Zahavi [EMAIL PROTECTED]:
Subject: git: cloning partial tree
A newbie question:
What is the easiest/simplest way for me to clone only the infiniband
part of the kernel tree?
Thanks
Eitan
You can't do that with git.
But you can check out just the infiniband part of
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: [PATCH] for 2-6-19 rdma/addr: use client registration to fix
module unload race
I think this is actually a good point for the CM case at least.
Clients already have something registered with the CM (namely the CM
ID itself), so if we
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [openib-general] Static linking with libibverbs
static linking actually can be made to work even with older library
versions.
See this HowTo (written on 02 of November, 2005).
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH repost] IB/srp: destroy/recreate qp/cq at reconnect
Roland, what do you think about this patch?
Seems like a good idea, to me.
Sorry, I haven't made this a high priority. It seems a little like
fiddling with the code
Quoting r. Moni Levy [EMAIL PROTECTED]:
AFAIK Module.symvers is used in compile time only so the same logic
that is used for .h files (the devel package) seems reasonable for it.
I agree. It would be nice however for all devel files to go under prefix/.
--
MST
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: [PATCH] for 2-6-19 rdma/addr: use client registration to fix
module unload race
All active side users are fine I think. But any client on the passive side
currently might destroy the new ID by returning error from the callback,
and
Quoting r. Sean Hefty [EMAIL PROTECTED]:
I use the callback method of destruction for new cm_id's in the ucm and ucma
modules, so I want to keep this feature myself. However, this method is
unused, and likely unneeded, for events other than connection requests. If
this is the case, we can
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Does SDP use this feature for events other than for connection requests?
Yes, it does. But as I said, since SDP is out of tree, for now we
can just ignore the module unloading race.
--
MST
___
openib-general
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: scaling issues, was: uDAPL cma: add support for address and route
retries, call disconnect when recving dreq
Or Gerlitz wrote:
Can be very nice if you share with the community the IB stack issues
revealed under scale-out testing...
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH] use mmiowb after doorbell ring
By the way, what's up with this project?
It's still planned for libibverbs 1.1, isn't it?
I working on it along with other things.
Where are your patches for using multiple EQs for CQ
Quoting r. Arlin Davis [EMAIL PROTECTED]:
Subject: Re: [openib-general] scaling issues, was: uDAPL cma: add support for
address and route retries, call disconnect when recving dreq
Sean Hefty wrote:
One option is having the SA (or ib_umad?) return a busy status in response
to a
MAD,
Quoting r. Ralph Campbell [EMAIL PROTECTED]:
Subject: [PATCH 1/7] IB/core - Add DMA mapping functions to allow device
drivers to interpose
IB/core - Add DMA mapping functions to allow device drivers to interpose
The QLogic InfiniPath HCAs use programmed I/O instead of HW DMA.
This patch
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: scaling issues, was: uDAPL cma: add support for address and
route retries, call disconnect when recving dreq
On Thu, 2006-11-02 at 17:54, Michael S. Tsirkin wrote:
Quoting r. Arlin Davis [EMAIL PROTECTED]:
Subject: Re: [openib
301 - 400 of 2913 matches
Mail list logo
