to 128 bytes,
assuming this is reasonable upper limit to header length.
Also, this patch will cause IB_DEVICE_UD_TSO to be set only of FW versions that
set MLX4_DEV_CAP_FLAG_BLH; e.g. FW version 2.6.000 and higher.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/main.c
ConnectX can work more efficiently if the CPU cache line size is configured to
it at INIT_HCA. This patch configures the CPU cache line size.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
As per Roland's comments, the following changes were made:
1. Remove #ifdef cache_line_size and include
Hi Sean,
one of our customers experiences problems when running ibnetdiscover.
The problem happens from time to time.
Here is the call stack the he gets:
ibnetdiscover D 80149b8d 0 26968 26544
(L-TLB)
8102c900bd88 0046 81037e8e 81037e8e02e8
On Wed, Sep 23, 2009 at 09:08:28AM -0700, Sean Hefty wrote:
Roland just submitted a patch in this area yesterday. I don't know if the
patch
would fix their issue, but it may be worth trying. What kernel does 1.4.2 map
to?
I think OFED 1.4.2 is based on kernel 2.6.27 but they're using RHEL
On Tue, Sep 22, 2009 at 10:51:10AM -0700, Roland Dreier wrote:
I agree with you on both comments. Would you like me to resend or will
you make the necessary changes?
+#if defined(cache_line_size)
Why the #if here? Do we just need to include linux/cache.h explicitly
to make sure we get
ConnectX can work more efficiently if the CPU cache line size is confiugred to
it at INIT_HCA. This patch configures cache line size for systems that report
it.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/net/mlx4/fw.c |7 +++
1 files changed, 7 insertions(+), 0 deletions
On Thu, Aug 20, 2009 at 02:33:41PM -0700, Roland Dreier wrote:
Eli, it occurs to me that since we're doing more than one page for EQ
context now, we might as well use the normal ICM table stuff that
everything else uses. Seems the code becomes much simpler and I don't
think there's any real
Roland,
what about this series of patches? Would you like me to re-create them
over your xrc branch or would you rather take them before xrc?
On Wed, Aug 19, 2009 at 08:19:35PM +0300, Eli Cohen wrote:
RDMA over Ethernet (RDMAoE) allows running the IB transport protocol using
Ethernet frames
APIs. Also,
ib_port_attr is extended to contain enum rdma_transport_type.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from previous version:
Define and make use of rdma_is_transport_supported(), an API that
allows the caller to check if a given device supports a given
transport
Since RDMAoE is using Ethernet as its link layer, there is no need for QP0. QP1
is still needed since it handles communications between CM agents. This patch
will create only QP1 for RDMAoE ports.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from previous version:
1. Instead
.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from last version:
1. Patch title changed from to Enable support for RDMAoE ports to
Enable support only for IB ports.
2. Do not allow userspace MADs to RDMAoE ports.
drivers/infiniband/core/user_mad.c | 15 +++
1 files
CM messages can be transported on RDMAoE protocol ports so they are enabled
here.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from last version:
Make use of rdma_is_transport_supported()
drivers/infiniband/core/cm.c |5 +++--
drivers/infiniband/core/ucm.c | 12
currently. Some helper
functions are added to ib_addr.h.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from last version:
1. Add kref to struct cma_multicast to aid in maintaining reference
count on the object. This is to avoid freeing the object while the
worker thread is still using
-EINVAL is
returned. mlx4 transport packets were changed too to accomodate for RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from previous version:
Call ib_register_mad_agent() for RDMA_TRANSPORT_IB type ports.
drivers/infiniband/hw/mlx4/ah.c | 187
ucma_copy_rdmaoe_route()instead of modifying ucma_copy_ib_route().
10. Bug fix: in PATCH 10/10, call flush_workqueue after unregistering netdev
notifiers
11. Multicast no longer use the broadcast MAC.
12. No changes to patches 2, 7 and 8 from the v4 series.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
b
On Mon, Aug 10, 2009 at 01:30:44PM -0700, Roland Dreier wrote:
Looking at mlx4_write_mtt_chunk() I see that it calls
mlx4_table_find() with a pointer to single dma_addr_t - dma_handle -
while the dma addresses for the ICM memory is actually a list of
different addresses covering
On Tue, Aug 11, 2009 at 11:23:48PM -0700, Roland Dreier wrote:
Maybe I'm missing your point, but mlx4_table_find() does go to some
trouble to find the right DMA address for the object being looked up.
Of course it could be buggy but I still don't see why we would need a
list of DMA addresses
On Mon, Aug 10, 2009 at 12:31:19PM -0700, Sean Hefty wrote:
@@ -576,10 +586,16 @@ static int cma_ib_init_qp_attr(struct rdma_id_private
*id_priv,
{
struct rdma_dev_addr *dev_addr = id_priv-id.route.addr.dev_addr;
int ret;
+u16 pkey;
+
+if
Looking at mlx4_write_mtt_chunk() I see that it calls
mlx4_table_find() with a pointer to single dma_addr_t - dma_handle -
while the dma addresses for the ICM memory is actually a list of
different addresses covering possibly different sizes. I think
mlx4_table_find() should be changed to support
On Mon, Aug 10, 2009 at 09:45:58AM -0400, Hal Rosenstock wrote:
How is port configuration (RDMAoE v. IB) accomplished ? Is it prior to boot
time or dynamic ?
mlx4 allows changing port designation dynamically by writing to the
sysfs.
___
general
On Wed, Aug 05, 2009 at 02:42:59PM -0600, Jason Gunthorpe wrote:
What about multicast though? Switches are going to have trouble with
group membership lists for non IP packets.. Even just sending a ICMPv6
packet (with an IPv6 ethertype) isn't guaranteed to fix it.
In this patch set, all
On Wed, Aug 05, 2009 at 01:43:12PM -0700, Sean Hefty wrote:
Can resources (PDs, CQs, MRs, etc.) between the different transports be
shared?
Does QP failover between transports work?
There is nothing in the architecture that precludes this; we are not
currently focusing on this.
Did you
On Thu, Aug 06, 2009 at 10:34:19AM -0700, Sean Hefty wrote:
Does the implementation allow this? Right now PDs, CQs, etc are allocated per
device, not per port. I'm not immediately concerned about QP failover.
However, I believe there needs to be some level of coordination between the
On Thu, Aug 06, 2009 at 11:05:47AM -0700, Sean Hefty wrote:
Is there a need to expose QP1 to user space? The CM is in the kernel, and
there's not an SA.
Good point. There seems to be no reason to expose it. Will fix.
___
general mailing list
On Thu, Aug 06, 2009 at 10:52:34AM -0700, Sean Hefty wrote:
+/* Validate device and port */
+port_priv = ib_get_mad_port(device, port_num);
+if (!port_priv) {
+ret = ERR_PTR(-ENODEV);
+goto error1;
+}
+
+if (!port_priv-qp_info[qp_type].qp)
+
.
2. SA services are not provided for RDMAoE clients. CMA code is modified to
support RDMAoE transport types.
3. For brevity, GID to MAC resolution is currently restricted to link local
addresses.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
b/drivers/infiniband/core/agent.c | 12
API,
rdma_port_get_transport() which gives the transport protocol of the queried
port. All references to rdma_node_get_transport() are changed to to use
rdma_port_get_transport(). Also, ib_port_attr is extended to contain enum
rdma_transport_type.
Signed-off-by: Eli Cohen e...@mellanox.co.il
Add a new transport protocol, RDMAoE, used for transporting Infiniband traffic
over Ethernet fabrics.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
include/rdma/ib_verbs.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma
Since RDMAoE is using Ethernet as its link layer, there is no need for QP0. QP1
is still needed since it handles communications between CM agents. This patch
will create only QP1 for RDMAoE ports.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/agent.c | 12
CM messages can be transported on RDMAoE protocol ports so they are enabled
here.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/cm.c |2 +-
drivers/infiniband/core/ucm.c | 12 +---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers
the destination MAC
address of the remote port. Multicast GIDs are always mapped to broadcast MAC
(all FFs). Some helper functions are added to ib_addr.h.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/cma.c | 150 ++-
drivers/infiniband
Add support functions to aid in packing RDMAoE packets.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/ud_header.c | 111 +++
include/rdma/ib_pack.h | 26
2 files changed, 137 insertions(+), 0 deletions(-)
diff
Add ib_uverbs_get_mac() to be used by ibv_create_ah() to retirieve the remore
port's MAC address. Port transport is also returned by ibv_query_port().
ABI version is incremented from 6 to 7.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/uverbs.h |1 +
drivers
-EINVAL is
returned. mlx4 transport packets were changed too to accomodate for RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/ah.c | 187 --
drivers/infiniband/hw/mlx4/mlx4_ib.h | 19 +++-
drivers/infiniband/hw/mlx4/qp.c
, each IB port has
a single GID entry in its table and that GID entery equals the link local IPv6
address.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/main.c | 309 +
drivers/net/mlx4/en_main.c| 15 ++-
drivers/net/mlx4
of the remote port that a
UD address vector refers to. Update ibv_rc_pingpong and ibv_ud_pingpong to
accept a remote GID so that they can be used with an RDMAoE port.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changed the reference to a port from link type to protocol type. This
patch is tagged v4
Modify mlx4_create_ah() to check the port's transport protocol, and for the
case of RDMAoE ports, do a system call to retrieve the remote port's MAC
address. Make modifications to address vector data structs and code to
accomodate for RDMAoE.
---
Changed the reference to a port from link type to
On Wed, Aug 05, 2009 at 08:46:43AM -0700, Sean Hefty wrote:
rdma_destroy_id and rdma_leave_multicast call ib_sa_free_multicast. This call
will block until the join callback completes or is canceled. Can you describe
the race with cma_ib_mc_handler in more detail?
That explains it. I was
the join
operation is in progress. This patch uses a kref object to maintain reference
counting to avoid such situation.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
Changes from previous version: I removed the protection of mc list
manipulation using spinlocks becuase -
a. In order to break
On Tue, Aug 04, 2009 at 09:05:13AM -0700, Roland Dreier wrote:
Maybe it's just a loose connection but yet, it seems to me that
operations on id_priv-mc_list should be protected. Should I send a
different patch?
seems ... should be is very weak justification for locking. What
should
the join is in
progress. This patch uses reference counting to to avoid such situation. It
also protects removal from id_priv-mc_list in cma_leave_mc_groups().
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/cma.c | 23 +++
1 files changed, 19
.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/net/mlx4/eq.c | 42 --
drivers/net/mlx4/main.c |1 +
drivers/net/mlx4/mlx4.h |1 +
include/linux/mlx4/device.h |1 +
4 files changed, 27 insertions(+), 18 deletions(-)
diff
On Mon, Jul 13, 2009 at 03:26:06PM -0400, Hal Rosenstock wrote:
+enum ib_port_link_type ib_get_port_link_type(struct ib_device *device, u8
port_num)
+{
+ return device-get_port_link_type ?
+ device-get_port_link_type(device, port_num) : PORT_LINK_IB;
So do iWARP
On Mon, Jul 13, 2009 at 03:26:34PM -0400, Hal Rosenstock wrote:
On Mon, Jul 13, 2009 at 2:14 PM, Eli Cohene...@mellanox.co.il wrote:
Since RDMAoE is using Ethernet as its link layer, there is no need for QP0.
QP1
is still needed since it handles communications between CM agents. This
On Tue, Jul 14, 2009 at 07:15:44AM -0400, Hal Rosenstock wrote:
On Tue, Jul 14, 2009 at 3:46 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Mon, Jul 13, 2009 at 03:26:34PM -0400, Hal Rosenstock wrote:
On Mon, Jul 13, 2009 at 2:14 PM, Eli Cohene...@mellanox.co.il wrote:
Since RDMAoE is
of the
Linux kernel. This new series reflects changes based on feedback from
the community on the previous set of patches. The whole series is
tagged v3.
Signed-off-by: Eli Cohen e...@mellanox.co.il
drivers/infiniband/core/Makefile |2
drivers/infiniband/core/addr.c
address leading to the port whose GID
is spcified. This function is exported to userspace applications.
ABI version is incremented from 6 to 7.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/uverbs.h |1 +
drivers/infiniband/core/uverbs_cmd.c | 33
Since RDMAoE is using Ethernet as its link layer, there is no need for QP0. QP1
is still needed since it handles communications between CM agents. This patch
will create only QP1 for RDMAoE ports.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/agent.c | 12
and comsumenrs
who want to use this API need to be changed.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/Makefile|2 +-
drivers/infiniband/core/multicast.c | 43 +--
drivers/infiniband/core/multicast.h | 79 +++
drivers/infiniband/core/rdmaoe_sa.c | 938
Add support for RDMAoE device binding and IP -- GID resolution. Modify calls
to the SA such that the link type is veirifed first and the appropriate call is
made to either IB SA or RDMAoE SA.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/addr.c | 20 ---
drivers
Add support functions to aid in packing RDMAoE packets.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/ud_header.c | 111 +++
include/rdma/ib_pack.h | 26
2 files changed, 137 insertions(+), 0 deletions(-)
diff
We don't want IPoIB to work over RDMAoE since it will give worse performance
than working directly on Ethernet interfaces which are a prerequisite to RDMAoE
anyway.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/ulp/ipoib/ipoib_main.c |3 +++
1 files changed, 3
to do that. mlx4
transport packets were changed too to accomodate for RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/ah.c | 228 ++-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 30 -
drivers/infiniband/hw/mlx4/qp.c
, each IB port has
a single GID entry in its table and that GID entery equals the link local IPv6
address.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/main.c | 276 +
drivers/net/mlx4/cmd.c|6 +
drivers/net/mlx4
To: Or Gerlitz; Eli Cohen
Cc: rdre...@cisco.com; general@lists.openfabrics.org
Subject: Re: [ofa-general] Write combining support in OFED 1.5
Adding Eli Cohen (author of the huge-page support patch).
Eli, what is missing on the PPC regarding huge page support?
-Jack
On Tuesday 07 July 2009 13:54
Roland,
where can I find your userspace trees with XRC support?
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
On Wed, Jun 17, 2009 at 11:19:04AM -0700, Roland Dreier wrote:
diff --git a/include/rdma/ib_user_verbs.h b/include/rdma/ib_user_verbs.h
index a17f771..5bfa2e6 100644
--- a/include/rdma/ib_user_verbs.h
+++ b/include/rdma/ib_user_verbs.h
@@ -81,7 +81,8 @@ enum {
On Mon, Jun 15, 2009 at 10:32:03AM -0600, Jason Gunthorpe wrote:
On Mon, Jun 15, 2009 at 04:42:36PM +0300, Eli Cohen wrote:
Please use inet_pton(AF_INET6,grh,gid) for this?
I was searching for something like this... Thanks, I'll fix this.
+ if (ctx-dgid.global.interface_id
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
You can't send anything over QP0 because it is not created and so
there are no data structs corresponding to it.
What QP1 sends are allowed ?
Basically, all
On Tue, Jun 16, 2009 at 10:27:33AM -0700, Sean Hefty wrote:
+
+w-member-multicast.rec.qkey = cpu_to_be32(0xc2c);
How can a user control this? An app needs the same qkey for unicast traffic.
In RDMAoE, the qkey has a fixed well-known value, which will be
returned both by multicast and
On Tue, Jun 16, 2009 at 11:16:28AM -0500, Steve Wise wrote:
Hey Eli,
Does this series implement UD/multicast support?
I didn't see it with a quick perusal of the patches.
Hi Steve,
yes UD multicast is supported. Note that in this version of the
pathces I use the broadcast MAC address (all
On Wed, Jun 17, 2009 at 07:14:56AM -0400, Hal Rosenstock wrote:
On Wed, Jun 17, 2009 at 7:10 AM, Eli Cohene...@dev.mellanox.co.il wrote:
On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
You can't send
.
Following is a series of 9 patches based on version 2.6.30 of the
Linux kernel.
Signed-off-by: Eli Cohen e...@mellanox.co.il
drivers/infiniband/core/addr.c| 20 ++-
drivers/infiniband/core/agent.c | 16 +-
drivers/infiniband/core/cma.c | 39 -
drivers
This allows to get the type of a port to be either Ethernet or IB which is
required by following patches for implementing RDMA over Ethernet - RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/verbs.c |7 +++
include/rdma/ib_verbs.h | 11
A few support functions are added to allow the translation from GID to MAC
which is required by hw drivers supporting RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/uverbs.h |1 +
drivers/infiniband/core/uverbs_cmd.c | 34
Since RDMAoE is using Ethernet there is no need for QP0. This patch will create
only QP1 for RDMAoE ports.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/agent.c | 16 -
drivers/infiniband/core/mad.c | 48 ++-
2
Add support for resolving paths and joining multicast group for RDMAoE ports.
The Ethernet specific code will complete immediately but will call the callback
from a workqueue context to avoid deadloks.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/multicast.c | 153
Add support for RDMAoE device binding and IP -- GID resolution.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/addr.c | 20 ---
drivers/infiniband/core/cma.c | 39 ++
include/rdma/ib_addr.h | 51
Add support functions to aid in packing RDMAoE packets.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/ud_header.c | 111 +++
include/rdma/ib_pack.h | 26
2 files changed, 137 insertions(+), 0 deletions(-)
diff
to do that. mlx4
transport packets were changed too to accomodate for RDMAoE.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/ah.c | 228 ++-
drivers/infiniband/hw/mlx4/mlx4_ib.h | 30 -
drivers/infiniband/hw/mlx4/qp.c
vector refers to.
Update ibv_rc_pingpong and ibv_ud_pingpong to accept a remote GID so that they
can be used with an RDMAoE port.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
examples/devinfo.c| 13 ++
examples/pingpong.c | 31 +
examples
-off-by: Eli Cohen e...@mellanox.co.il
---
src/mlx4.c |1 +
src/mlx4.h |3 +++
src/qp.c|2 ++
src/verbs.c | 14 ++
src/wqe.h |3 ++-
5 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/src/mlx4.c b/src/mlx4.c
index 34ece39..d2e32fd 100644
--- a/src
On Mon, Jun 01, 2009 at 09:01:23AM -0500, Mike Heinz wrote:
One of our testers recently reported that he was getting different
performance numbers from IPOIB depending on whether he was using interface
ib0 or a child interface he had created with /sys/class/netib0/create_child.
On Sun, May 31, 2009 at 09:41:54AM +0300, Or Gerlitz wrote:
akep...@sgi.com wrote @
http://lists.openfabrics.org/pipermail/general/2009-May/059730.html
What would prevent a race between a tx completion (with an
error) and the cleanup of a neighbour?
Okay, so maybe this code/design of
On Wed, May 20, 2009 at 08:00:47AM +0200, sebastien dugue wrote:
Well not really, because if we stay below MMAP_THRESHOLD, as we do
with 4K pages, the only overhead is malloc's chaining structure. The
extra space used to align the buffer is released before posix_memalign()
returns, but
of MTT entries
that each segment represents, thus allowing to register more memory with the
same number of segments.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/net/mlx4/main.c | 14 --
drivers/net/mlx4/mr.c |6 +++---
drivers/net/mlx4/profile.c |2
of MTT entries
that each segment represents, thus allowing to register more memory with the
same number of segments.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mthca/mthca_cmd.c |2 +-
drivers/infiniband/hw/mthca/mthca_dev.h |1 +
drivers/infiniband/hw
On Tue, Apr 21, 2009 at 11:08:25AM +0800, Liang Zhen wrote:
In our module, we have per-CPU thread and per-CPU waitq, each thread has
it's own connection list to poll on, completion handler will dispatch
connection to it's scheduler and wake the scheduler.
I'm very sure that scheduler doesn't
On Mon, Apr 13, 2009 at 10:19:08PM +0300, Yossi Etigin wrote:
I see. That surprises me... could you also print vma-vm_start and
vma-vm_end? I would have expected the vma to be streched to fill a
full huge page and return the number of regular pages fitting in it.
Eli Cohen wrote:
On Mon, Apr
On Mon, Apr 06, 2009 at 08:49:43PM +0300, Yossi Etigin wrote:
I don't understand - if all area is huge pages, it does not mean that
it fills full huge pages - I can have just 4096 bytes in huge page memory
and umem-hugetlb will remain 1, right?
You may call ib_umem_get() with a fraction of
On Thu, Apr 02, 2009 at 11:31:42PM +0300, Yossi Etigin wrote:
Hi Eli,
I've placed a printk in the new hugetlb function to print n and j.
While running the mckey test (attached in bugzilla), I got j=0, n=1.
Why do you say that the number of pages must cover HUGE_PAGES?
In ib_umem_get,
On Mon, Mar 30, 2009 at 06:49:37PM +0300, Yossi Etigin wrote:
Yossi,
I wouldn't expect this to matter since handle_hugetlb_user_mr() only
gets called when the memory is huge pages which means the number of
PAGE_SIZE pages cover full HUGE_PAGES. You mention in Bugzilla an
mckey test but I don't
On Thu, Apr 02, 2009 at 11:47:26AM +0300, Or Gerlitz wrote:
mckey is installed with librdmac-utils, has man page, etc. Its source is
under the examples directory of the librdmacm src tree, you can clone
Sean's librdmacm git from ofa to get it - OK?
Thanks Or. I will check this.
On Sun, Mar 29, 2009 at 12:07:09PM +0300, Moni Shoua wrote:
Eli Cohen wrote:
On Wed, Mar 25, 2009 at 09:20:19PM +0200, Yossi Etigin wrote:
Wouldn't this patch break the fast bond+SM failover recovery?
Up till now, in such case neigh-dgid was the old gid until path record
query
:00 2001
From: Eli Cohen e...@mellanox.co.il
Date: Wed, 25 Mar 2009 16:22:28 +0200
Subject: [PATCH] IB/ipoib: set neigh-dgid upon ipoib_neigh creation
If we fail to do that, there can be superfluous calls to
ipoib_neigh_free()/ipoib_neigh_alloc() due to the following if statement in
ipoib_start_xmit
Hi,
I am trying to resolve IPv6 addresses (that is, obtaining the MAC
address of the interface bearing the IP addresses). I am using
rdma_resolve_ip() defined in core/addr.c but I don't get consistent
results.
I get something like this:
fe80::202:c9ff:fe00:1341 dev eth1 FAILED
where I would
On Thu, Mar 05, 2009 at 09:29:48AM -0800, Sean Hefty wrote:
I didn't quite follow this last sentence. Are you saying that it only works
sometimes? Only the first time?
After I run ping6 from the command line, the remote ipv6 address gets
added to the cache and resolution starts working.
Roland,
browsing the code, I see that mlx4_CLOSE_PORT() gets called from,
seemingly, too many places. I would expect it to get called only from
__mlx4_ib_modify_qp() when QP0 gets closed, but mlx4_ib_remove() calls
it too even though it is soon to be called by __mlx4_ib_modify_qp()
due to
Thanks!
On Thu, Feb 19, 2009 at 9:40 PM, Or Gerlitz or.gerl...@gmail.com wrote:
On Thu, Feb 19, 2009 at 6:55 PM, Eli Cohen e...@dev.mellanox.co.il wrote:
I have encountered a kernel crash when running a iSCSI initiator on
IPoIB configured with LRO (if LRO is off it does not happen
Hi,
I have encountered a kernel crash when running a iSCSI initiator on
IPoIB configured with LRO (if LRO is off it does not happen). This
was seen first on Sles10sp2 but then I verified it happens on 2.6.28.2
too. Bellow is a dump of the crash info from 2.6.28.2:
sd 2:0:0:1: Attached scsi
On Mon, Jan 26, 2009 at 10:26:25AM -0800, Roland Dreier wrote:
It is has to be saved either at the low level driver's mr object,
e.g. struct mlx4_ib_mr, or at a common place like struct ib_umem. Do
you prefer that it will be saved in struct mlx4_ib_mr?
I don't see why it has to be
On Thu, Jan 29, 2009 at 07:33:22AM -0800, Roland Dreier wrote:
I see... you're right - no need to stick the address into struct
ib_umem. Following this email is a new patch for mlx4_ib only. I
excluded support for both powerpc and ia64 since I could not find a
way to get HPAGE_SIZE (or
On Mon, Jan 26, 2009 at 09:59:26AM -0800, Roland Dreier wrote:
seems like a really strange thing to do:
+ umem-address = addr;
this value addr is coming from the low-level driver, so I'm not clear
why we need to stick it into umem? What am I missing?
It is has to be saved
On Thu, Jan 22, 2009 at 09:07:41PM -0800, Roland Dreier wrote:
seems this might underestimate by 1 if the region doesn't start/end on a
huge-page aligned boundary (but we would still want to use big pages to
register it).
Looks like we must pass the virtual address through struct ib_umem
add address field to struct ib_umem so low level drivers will have this
information which may be needed in order to correctly calculate the number of
huge pages.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/core/umem.c |1 +
include/rdma/ib_umem.h |1 +
2
segments used
for registering hugetlb memory regions.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
In this version I also took care of the case where the kernel is
compiled without hugetlb support.
drivers/infiniband/hw/mlx4/mr.c | 86 ++-
1 files
hugetlb memory
regions.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
I tried this patch and improves memory scalability. Without it,
increasing the amount of memory used cause caused decrease in
throughput. With this patch there was no drop at all - I used a test
based on MPI with 2 processes
On Wed, Dec 17, 2008 at 11:12:39AM -0800, Roland Dreier wrote:
I don't see why this would be required. When ipoib_mcast_free() runs,
the mcast structure has been removed from all lists and I don't see how
any other context could simultaneously be adding packets to pkt_queue.
What is the race
ipoib_mcast_free() dequeues SKBs pending on the pkt_queue but needs to do that
with netif_tx_lock_bh() acquired.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
I saw the following bug appear in ofed 1.4 on RHAS5.2 but have not yet had the
chance to verify that this patch fixes this particular
On Wed, Nov 05, 2008 at 05:23:07PM -0800, [EMAIL PROTECTED] wrote:
Hi Arthur,
looking a the patch I don't understand why it should fix the problem
you're seeing. I suspect we may be hiding the problem.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
1 - 100 of 553 matches
Mail list logo
