Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [git patch review 2/2] IB: Don't doublefree pages from
scatterlist
Hugh It's now looking like this change won't be needed after all:
Hugh Andi has just posted a patch in the ipr thread which
Hugh should stop x86_64 from
Hi Hal,
The following patch includes some fixes for the windows stack:
1. Add needed __cdecl.
2. Change the default directories/files names.
Thanks,
Yael
Signed-off-by: Yael Kalka [EMAIL PROTECTED]
Index: include/opensm/osm_base.h
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Related to this, the way priv-broadcast is initialized
in ipoib_mcast_join_task() looks somewhat unsafe, since there's no
lock and conceivable a send-only join could complete before
priv-broadcast is fully set up. What do you think?
I agree. Do you
r5329 | ogerlitz | 2006-02-07 11:01:04 +0200 (Tue, 07 Feb 2006) | 5 lines
refined conn term flow, removed two cases from iser_conn_sync_terminate,
made iser_complete_conn_termination and iser_conn_async_terminate void
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: mthca: gid index bug?
Roland, in mthca_qp.c we have
path-mgid_index = ah-grh.sgid_index;
Shouldnt the port number be taken into account, like it
is with mthca_av, where we have
av-gid_index =
bugfix for connect error flow when getting RDMA_CM_EVENT_ADDR_ERROR
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: iser_verbs.c
===
--- iser_verbs.c(revision 5329)
+++ iser_verbs.c(revision 5330)
@@ -626,7 +626,9
Michael I agree. Do you want to fix it or should I?
If you get a chance that would be great. I'm at the OpenIB workshop
now so I probably can't seriously look at it until tomorrow at the
earliest.
- R.
___
openib-general mailing list
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: ipoib_mcast_send.patch
Michael I agree. Do you want to fix it or should I?
If you get a chance that would be great. I'm at the OpenIB workshop
now so I probably can't seriously look at it until tomorrow at the
earliest.
Looks
Sean Hefty wrote:
I am not clear what you are proposing?
A transport specific API?
The current proposal provides on sending side:
single post, and single completion in the error free case.
This is commonality that simplify ULP.
App 1 - transport aware:
if (transport == IB)
Do
And further it is only on the receiving side.
And only if the receiving side cares about the data
(sometimes it only needs the notification).
The send size cares about this check because it must size its SQ appropriately.
I disagree with the assumption that a
But each of the multiple work requests follow the semantic of single
completion per work request. It can be controlled by completion_flags
but it still not a semantic of a single post.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone:
Anyone see this before?
-
vic17:~ # ibstat
ibstat: relocation error: ibstat: symbol argv0, version IBCOMMON_1.0 not
defined in file libibcommon.so.1 with link time reference
vic17:~ # uname -a
Linux vic17 2.6.15.2-kdb #4 SMP PREEMPT Mon Feb 6 17:24:41 CST 2006 i686
i686 i386 GNU/Linux
Why would any Consumer hook itself on proprietary features and
APIs is a different question.
Because it provides a real performance benefit. This is the same reason apps
code to DAPL versus standard sockets.
- Sean
___
openib-general mailing list
Hi Steve,
This looks similar to the ibping problem. Could you update libibcommon.map and
rebuild libibcommon ?
Thanks.
-- Hal
From: [EMAIL PROTECTED] on behalf of Steve Wise
Sent: Tue 2/7/2006 11:01 AM
To: openib-general
Subject: [openib-general] ibstat
I get the following build error when compiling
SVN5330.
CC [M] drivers/infiniband/hw/ipath/ipath_verbs.o
drivers/infiniband/hw/ipath/ipath_verbs.c: In function
`ipath_alloc_fmr':
drivers/infiniband/hw/ipath/ipath_verbs.c:5759: error: structure has no
member named `page_size'
make[3]: ***
On Tue, 2006-02-07 at 09:07 -0800, Woodruff, Robert J wrote:
I get the following build error when compiling
SVN5330.
We'll commit a fix later today. Robert is in Sonoma at the OpenIB
workshop, and he's our svn committer, so it might take a little while.
Thanks for pointing this out.
Thanks, I broke this when I merged Or's FMR patch.
I checked in this fix:
--- infiniband/hw/ipath/ipath_verbs.c (revision 5330)
+++ infiniband/hw/ipath/ipath_verbs.c (working copy)
@@ -5756,7 +5756,7 @@ static struct ib_fmr *ipath_alloc_fmr(st
fmr-mr.offset = 0;
On Tue, 2006-02-07 at 09:29 -0800, Roland Dreier wrote:
Thanks, I broke this when I merged Or's FMR patch.
Thanks.
b
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
All 3 options: proposed APIs, extensions, or IB semantic API
all provide the same performance benefit on IB.
But the last option is the easiest to use.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with immediate
data. A send that follows an RDMA write is not immediate data, and the API
should not be constructed around trying to make it so.
To be clear, I believe that write with immediate should be
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with
immediate data. A send that follows an RDMA write is not immediate
data, and the API should not be constructed around trying to make
it so.
To be clear, I believe that write
+rmpp_mad = (struct ib_rmpp_mad *)seg_buf-mad;
Trivial, but I prefer a space after cast operators.
+static struct ib_umad_packet *alloc_packet(void)
+{
+struct ib_umad_packet *packet;
+int length = sizeof *packet + sizeof(struct ib_mad);
+
+packet =
Caitlin Bestler wrote:
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes with
immediate data. A send that follows an RDMA write is not immediate
data, and the API should not be constructed around trying to make
it so.
To be clear, I
IB does optionally support send_with_invalidate as defined in IBTA 1.2
spec.
OpenIB does not support this yet but this is a different matter.
So this is bad analogy.
The better analogy is socket based CM.
But I am still not clear what you are advocating:
extensions, IB specific API or something
[EMAIL PROTECTED] wrote:
Caitlin Bestler wrote:
Arlin Davis wrote:
Sean Hefty wrote:
The requirement is to provide an API that supports RDMA writes
with immediate data. A send that follows an RDMA write is not
immediate data, and the API should not be constructed around
trying to make
IB does optionally support send_with_invalidate as defined in IBTA 1.2
spec.
OpenIB does not support this yet but this is a different matter.
So this is bad analogy.
The better analogy is socket based CM.
But I am still not clear what you are advocating:
extensions, IB specific API or something
What is proposed in a definition of
'dat_ep_post_rdma_write_with_immediate'
that can be implemented over iWARP using the sequence of messages
that were intended to support the same purpose (i.e., letting the
other side know that an RDMA Write transfer has been fully
received).
No, iWARP
I'm trying to build a system using the openib drivers with a mellanox
hca card. I don't have much information about the card itself, it's
in a server right now...
But I downloaded openib today from the svn source, installed it onto a
fresh copy of Fedora Core 4 with Kernel version 2.6.15.3...
Larsen, Roy K wrote:
Completing a transaction, complete with supplying a transaction
response and releasing the advertised STag associated with the
transaction is something that makes sense in the application domain
and conforms to normal DAT ordering rules.
I don't disagree. And
Michael,
I have seen this problem before..
See following mail thread
http://www.mail-archive.com/openib-general@openib.org/msg13861.html
Commenting out call to mthca_reset() in mthca_main.c worked around the
problem on my system, and as far as I can tell, did not have any
negative impact.
It
Completing a transaction, complete with supplying a transaction
response and releasing the advertised STag associated with the
transaction is something that makes sense in the application domain
and conforms to normal DAT ordering rules.
I don't disagree. And unambiguous immediate data
Feb 7 16:59:48 linux14-ts kernel: ib_mthca :07:00.0: PCI device did not
come back after reset, aborting.
Can you give more details on the system where you saw this?
- R.
___
openib-general mailing list
openib-general@openib.org
What specifically would you like to know?
On 2/7/06, Roland Dreier [EMAIL PROTECTED] wrote:
Feb 7 16:59:48 linux14-ts kernel: ib_mthca :07:00.0: PCI device did
not come back after reset, aborting.
Can you give more details on the system where you saw this?
- R.
We have problem no matter which option we choose.
The current Transport Level Requirement state:
There is a one-to-one correspondence between send operation on one
Endpoint of the Connection and recv operations on the other Endpoint of
the Connection.
There is no correspondence between RDMA
Anyway, I've (finally) applied this patch.
- 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-general
Based on what you've done, I'd like to suggest changing interface similar to
that shown below. I believe that this could be done with minor changes to the
current patches. Detailed comments that led to suggesting this change are
inline in my responses.
struct ib_mad_segments {
u32
+static int data_offset(u8 mgmt_class)
+{
+ if (mgmt_class == IB_MGMT_CLASS_SUBN_ADM)
+ return IB_MGMT_SA_HDR;
+ else if ((mgmt_class = IB_MGMT_CLASS_VENDOR_RANGE2_START)
+ (mgmt_class = IB_MGMT_CLASS_VENDOR_RANGE2_END))
+ return
Hi Everyone,
Now I am using OpenIB Gen2 on SuSE10. I got a strange problem when I
tried to bring up/down ib interface, I put the ib interface startup
script ifcfg-ib0/ifcfg-ib1 under /etc/sysconfig/network directory, when
I use the command 'ifdown ib0', and from the message shown, it will pick
up
-static inline u64 get_seg_addr(struct ib_mad_send_wr_private *mad_send_wr)
+static inline void *get_seg_addr(struct ib_mad_send_wr_private *mad_send_wr)
{
- return mad_send_wr-sg_list[0].addr + mad_send_wr-data_offset +
- (sizeof(struct ib_rmpp_mad) - mad_send_wr-data_offset) *
On Tue, 2006-02-07 at 09:29 -0800, Roland Dreier wrote:
Thanks, I broke this when I merged Or's FMR patch.
I checked in this fix:
--- infiniband/hw/ipath/ipath_verbs.c (revision 5330)
+++ infiniband/hw/ipath/ipath_verbs.c (working copy)
@@ -5756,7 +5756,7 @@ static struct ib_fmr
Ranjit Commenting out call to mthca_reset() in mthca_main.c
Ranjit worked around the problem on my system, and as far as I
Ranjit can tell, did not have any negative impact.
Yes, that should work fine in most cases. The reset is done to get
the HCA into a known state, since it might
Michael What specifically would you like to know?
What kind of CPU, motherboard, PCI host bridge, etc.
lspci -vvv output would be interesting. Maybe /proc/cpuinfo too.
- R.
___
openib-general mailing list
openib-general@openib.org
42 matches
Mail list logo
