2011/12/20 Or Gerlitz :
>
> Beep, I'd like to better/understand the problem before looking on your
> struggle for solution...
> I understand that your Debian system runs kernel 3.0 - however, you didn't
> say what version of the iscsi initiator utils is provided with that distro
> nor what were the
On Mon, Dec 19, 2011 at 10:51 PM, David Dillow wrote:
> I haven't parsed it all out from your changes just yet, but I think part
> of the reason you may have had problems with req->scmd being null in
> srp_handle_recv() is due to a new race between the tear down of the
> connection and continuing
Sorry for late reply...
On 15:30 Fri 16 Dec , Hal Rosenstock wrote:
> On 12/16/2011 2:51 PM, Ira Weiny wrote:
> > On Fri, 16 Dec 2011 11:24:54 -0800
> > Hal Rosenstock wrote:
> >
> >>
> >> Also, make log_send_error into a routine and also call when MAD is
> >> cancelled.
> >>
> >> This patc
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow wrote:
> I still think this is already solved in user space, but the new
> reconnect model you've implemented doesn't match up with the expected
> semantics. It'd be better to match the rest of the SCSI stack for this.
Sorry, but I'm afraid there is
On Mon, Dec 19, 2011 at 12:07 AM, David Dillow wrote:
> On Thu, 2011-12-01 at 20:08 +0100, Bart Van Assche wrote:
>> Eliminate the private_rport_attrs[] array and the SETUP_*() macros
>> used to set up that array since the information in that array
>> duplicates the information in the static devic
On Mon, Dec 19, 2011 at 10:32 PM, David Dillow wrote:
> Part of the problem is introduced by allowing for permanent connections
> rather than using the familiar dev_loss_tmo and fast_io_fail_tmo
> parameters from other SCSI transports. For instance, in the FC
> transport, rports are allowed to dis
Any news on this one?
Regards
Albert
On Thu, Dec 8, 2011 at 8:31 PM, Albert Strasheim wrote:
> On Thu, Dec 8, 2011 at 8:29 PM, Roland Dreier wrote:
>> On Thu, Dec 8, 2011 at 9:56 AM, Albert Strasheim wrote:
>>> I think the BIOS has VT-d enabled. dmesg says:
>>> PCI-DMA: Intel(R) Virtualizatio
Sebastian Riemer wrote:
Debian Squeeze (in general 2.6.32 based) comes with open-iscsi
2.0.871.3-2squeeze1. We've used that version together with the in-tree
mainline kernel 3.0 OFA kernel modules and Debian Squeeze OFED-1.4
user-space. But there were lots of iSER connection aborts (and even
l
Ira Weiny wrote:
Jason Gunthorpe wrote:
How do you feel about having counters_ext appear in ethernet mode and
disappear in IB mode?
That might get complicated with ports which can be either mode.
Ira (reviving this thread),
At the ib core level, the link layer sysfs attribute is read only.
Ira Weiny wrote:
Jason Gunthorpe wrote:
How do you feel about having counters_ext appear in ethernet mode and
disappear in IB mode?
That might get complicated with ports which can be either mode.
Ira (reviving this thread),
At the ib core level, the link layer sysfs attribute is read only.
On 11/8/2011 3:09 AM, Jason Gunthorpe wrote:
Roland Dreier wrote:
Let's make sure we learn from our mistakes. Let's say we create a
new "ext_counters" directory. What should the format of those files
be? Should they be assumed to be 64-bit quantities? Do we want to
allow some way of indicat
On Tue, Dec 20, 2011 at 02:03:31PM +0200, Or Gerlitz wrote:
> >That is a good idea. Let's require counters_ext to be sane:
> >
> > 1 Hex quantity of unspecified size
> > 2 Prefixed with 0x and leading zeros to fill out to size and allow
> >userspace discovery of size
> > 3 Size must be a mu
Jason Gunthorpe wrote:
> The netdev counters are all the same size and there is some other way
> to discover what the size is. I'd like to see that for IB counters
> too, but it is probably infeasible. So if we have counters that are
> not the same size as netdev counters then some kind of size in
On Tue, Dec 20, 2011 at 09:40:09PM +0200, Or Gerlitz wrote:
> Jason Gunthorpe wrote:
> > The netdev counters are all the same size and there is some other way
> > to discover what the size is. I'd like to see that for IB counters
> > too, but it is probably infeasible. So if we have counters that
Jason Gunthorpe wrote:
>> We're talking now only on the IB extended counters who are all 64 bits
> netdev counters are 32 bit or 64 bit, depending on how the kernel was
> compiled. I think indicating the size explicitly, or always being 64
> bit (and extending all the lessor counters in future) i
Also, make log_send_error routine and call when MAD is cancelled
This patch is an alternative to Ira's v4 patch entitled
"opensm: Move Error printing to MAD error call back functions"
which pushes this functionality up into the send error callbacks.
This patch is currently compile tested only.
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/osm_sa_mad_ctrl.c b/opensm/osm_sa_mad_ctrl.c
index bde88fa..ddf0bb1 100644
--- a/opensm/osm_sa_mad_ctrl.c
+++ b/opensm/osm_sa_mad_ctrl.c
@@ -398,9 +398,6 @@ static void sa_mad_ctrl_send_err_callback(IN void *context,
OSM_LOG_ENTER(p_
Signed-off-by: Hal Rosenstock
---
diff --git a/opensm/osm_perfmgr.c b/opensm/osm_perfmgr.c
index ded5a5e..41ef08b 100644
--- a/opensm/osm_perfmgr.c
+++ b/opensm/osm_perfmgr.c
@@ -212,7 +212,10 @@ static void perfmgr_mad_send_err_callback(void
*bind_context,
p_mon_node = (monitored_node_t
Signed-off-by: Hal Rosenstock
---
diff --git a/include/opensm/osm_switch.h b/include/opensm/osm_switch.h
index a0dfbfc..de567ad 100644
--- a/include/opensm/osm_switch.h
+++ b/include/opensm/osm_switch.h
@@ -575,7 +575,7 @@ boolean_t osm_switch_get_lft_block(IN const osm_switch_t *
p_sw,
*
*
rather than in hex
Signed-off-by: Hal Rosenstock
---
diff --git a/osmeventplugin/src/osmeventplugin.c
b/osmeventplugin/src/osmeventplugin.c
index 9caf184..e4e51a0 100644
--- a/osmeventplugin/src/osmeventplugin.c
+++ b/osmeventplugin/src/osmeventplugin.c
@@ -141,13 +141,13 @@ static void handle_
2011/12/20 Or Gerlitz :
>
> Beep(2), so your system has distro which is based on kernel 2.6.32 and iscsi
> initiator tools version 2.0.871 and per your needs, you've booted it with
> kernel 3.0 .
>
> At this point should you have stop and make sure that this combo works,
> iscsi wise (simpler to te
On 12/20/2011 03:33 PM, Sebastian Riemer wrote:
Now I know why everybody has his own OFED - so do we now. E.g. the
QLogic stuff isn't even compilable without the QLogic OFED, because
they only put their patches in there. Luckily, we have only Mellanox
HCAs in our productive environment.
Actual
Enhance checks for loopback and any address to support AF_IB
in addition to AF_INET and AF_INT6. This will allow future
patches to use AF_IB when binding and resolving addresses.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 40
1 files
The AF_IB uses a 64-bit service id (SID), which the
user can control through the use of a mask. The rdma_cm
will assign values to the unmasked portions of the SID
based on the selected port space and port number.
Because the IB spec divides the SID range into several regions,
a SID/mask combinati
Modify rdma_bind_addr to allow the user to specify AF_IB when
binding to a device. AF_IB indicates that the user is not
mapping an IP address to the native IB addressing. (The mapping
may have already been done, or is not needed.)
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c |
Provide inline helpers to extract source and destination address
data from the rdma_cm_id.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 143 +
1 files changed, 72 insertions(+), 71 deletions(-)
diff --git a/drivers/infiniband/core/cma.c
cma_resolve_loopback is called after an rdma_cm_id has been
bound to a specific sa_family and port. Once the
source sa_family for the id has been set, do not modify it.
Only the actual IP address portion of the source address
needs to be set.
As part of this fix, we can simplify setting the sourc
Allow rdma_resolve_route to handle the case where the user
specified the source and destination addresses using AF_IB.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b
Define AF_IB and sockaddr_ib to allow the rdma_cm to use native IB
addressing.
Signed-off-by: Sean Hefty
---
include/linux/socket.h |2 +
include/rdma/ib.h | 89
2 files changed, 91 insertions(+), 0 deletions(-)
create mode 100644 incl
If a user specifies AF_IB as the source address for a loopback
connection, limit the resolution to IB devices only.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 11915bf..d164b19 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core
Add support for AF_IB to ip_addr_size, and rename the function
to account for the change. Give the compiler more control over
whether the call should be inline or not by moving the definition
into the .c file, removing the static inline, and exporting it.
Signed-off-by: Sean Hefty
---
drivers/i
Allow the user to specify the remote address using AF_IB format.
When AF_IB is used, the remote address simply needs to be recorded,
and no resolution using ARP is done. The local address may still
need to be matched with a local IB device.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/
If the source or destination address is AF_IB, then do not
reserve a portion of the private data in the IB CM REQ or SIDR
REQ messages for the cma header. Instead, all private data
should be exported to the user. When AF_IB is used, the
rdma cm does not have sufficient information to fill in the
Allow the user to specify the qkey when using AF_IB. The
qkey is added to struct rdma_ucm_conn_param in place of a reserved
field, but for backwards compatability, is only accessed if the
associated rdma_cm_id is using AF_IB.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 35 +
If an rdma_cm_id is bound to AF_IB, with a wild card address,
only listen on IB devices.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 006
cma_get_service_id forms the service ID based on the port space
and port number of the rdma_cm_id. Extend the call to support
AF_IB, which contains the service ID directly. This will
be needed to support any arbitrary SID.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c |3 +++
Allow converting from struct ib_sa_path_rec to the IB defined
SA path record wire format. This will be used to report path
data from the rdma cm into user space.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/sa_query.c |6 ++
include/rdma/ib_sa.h |6 ++
2 f
The sockaddr structure for AF_IB is larger than sockaddr_in6.
The rdma cm user space ABI uses the latter to exchange address
information between user space and the kernel.
To support querying for larger addresses, define a new query
command that exchanges data using sockaddr_storage, rather
than s
Allow the rdma_ucm to query the IB service ID formed or
allocated by the rdma_cm by exporting the cma_get_service_id
functionality.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 13 +++--
include/rdma/rdma_cm.h|7 +++
2 files changed, 14 insertions(+), 6
The current query_route call can return up to two path records.
The assumption being that one is the primary path, with optional
support for an alternate path. In both cases, the paths are
assumed to be reversible and are used to send CM MADs.
With the ability to manually set IB path data, the rd
Support user space binding to addresses using AF_IB. Since
sockaddr_ib is larger than sockaddr_in6, we need to define
a larger structure when binding using AF_IB. This time we
use sockaddr_storage to cover future cases.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/ucma.c | 27 ++
Part of address resolution is mapping IP addresses to IB GIDs.
With the changes to support querying larger addresses and more
path records, also provide a way to query IB GIDs after
resolution completes.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/ucma.c | 50
Several commands into the RDMA CM from user space are
restricted to supporting addresses which fit into a sockaddr_in6
structure: bind address, resolve address, and join multicast.
With the addition of AF_IB, we need to support addresses
which are larger than sockaddr_in6. This will be done by
ad
Allow user space applications to call resolve_addr using
AF_IB. To support sockaddr_ib, we need to define a new
structure capable of handling the larger address size.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/ucma.c | 30 +-
include/rdma/rdma_user_cm.h
Report AF_IB source and destination addresses through
netlink interface.
Signed-off-by: Sean Hefty
---
drivers/infiniband/core/cma.c | 37 ++---
1 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/c
Allow user space applications to join multicast groups using MGIDs
directly. MGIDs may be passed using AF_IB addresses. Since the
current multicast join command only supports addresses as large as
sockaddr_in6, define a new structure for joining addresses specified
using sockaddr_ib.
Since AF_IB
This is the full patch series for adding the ability to handle native
Infiniband addressing to the rdma_cm. It is also available from:
git://git.openfabrics.org/~shefty/rdma-dev.git af-ib
Adding support for native IB addressing allows us to offload name and/or
address translation servi
Sebastian Riemer wrote:
> 2011/12/20 Or Gerlitz :
>> Beep(2), so your system has distro which is based on kernel 2.6.32 and iscsi
>> initiator tools version 2.0.871 and per your needs, you've booted it with
>> kernel 3.0 .
>> At this point should you have stop and make sure that this combo works
On Tue, 20 Dec 2011 12:08:14 -0800
Hal Rosenstock wrote:
>
> Also, make log_send_error routine and call when MAD is cancelled
>
> This patch is an alternative to Ira's v4 patch entitled
> "opensm: Move Error printing to MAD error call back functions"
> which pushes this functionality up into t
> @@ -1910,12 +1911,15 @@ ssize_t ib_uverbs_attach_mcast(struct ib_uverbs_file
> *file,
>
> obj = container_of(qp->uobject, struct ib_uqp_object, uevent.uobject);
>
> + spin_lock(&qp->mcast_lock);
> list_for_each_entry(mcast, &obj->mcast_list, list)
> if (cmd.mlid ==
On Mon, Dec 19, 2011 at 11:19 PM, Eli Cohen wrote:
> I considered this but that means that you serialize attach/detach
> operations at ib core. Using a spinlock to protect the list allows
> more concurrency. After all, we hit this bug since concurrency of such
> operations occur in real life appli
This series fixes compiler warnings on some architectures about implicit
conversions and narrowing conversions between pointer and integer types.
Please apply these to the appropriate trees.
Ben.
Ben Hutchings (8):
IB/cxgb4: Fix formatting of physical address
farsync: Fix confusion about DMA
Physical addresses may be wider than virtual addresses (e.g. on i386
with PAE) and must not be formatted with %p.
Signed-off-by: Ben Hutchings
---
The resource could alternately be formatted with %Pr.
Ben.
drivers/infiniband/hw/cxgb4/device.c |4 ++--
1 files changed, 2 insertions(+), 2 de
On Tue, 2011-12-20 at 10:13 +, Bart Van Assche wrote:
> On Mon, Dec 19, 2011 at 10:32 PM, David Dillow wrote:
> > I still think this is already solved in user space, but the new
> > reconnect model you've implemented doesn't match up with the expected
> > semantics. It'd be better to match the
On Wed, 2011-12-21 at 01:32 +, Ben Hutchings wrote:
> Physical addresses may be wider than virtual addresses (e.g. on i386
> with PAE) and must not be formatted with %p.
[]
> The resource could alternately be formatted with %Pr.
> diff --git a/drivers/infiniband/hw/cxgb4/device.c
> b/drivers/i
On Tue, 2011-12-20 at 18:35 -0800, Joe Perches wrote:
> On Wed, 2011-12-21 at 01:32 +, Ben Hutchings wrote:
> > Physical addresses may be wider than virtual addresses (e.g. on i386
> > with PAE) and must not be formatted with %p.
> []
> > The resource could alternately be formatted with %Pr.
>
On Tue, 2011-12-20 at 10:27 +, Bart Van Assche wrote:
> On Mon, Dec 19, 2011 at 10:32 PM, David Dillow wrote:
> > Part of the problem is introduced by allowing for permanent connections
> > rather than using the familiar dev_loss_tmo and fast_io_fail_tmo
> > parameters from other SCSI transpor
On Tue, 2011-12-20 at 10:21 +, Bart Van Assche wrote:
> On Mon, Dec 19, 2011 at 12:07 AM, David Dillow wrote:
> > They use a BUG_ON instead of WARN_ON, which
> > seems more appropriate, since we just overran a buffer...
>
> Sorry, but I disagree. The guideline for Linux kernel code is to use
On Tue, 2011-12-20 at 09:01 +, Bart Van Assche wrote:
> On Mon, Dec 19, 2011 at 10:51 PM, David Dillow wrote:
> > I haven't parsed it all out from your changes just yet, but I think part
> > of the reason you may have had problems with req->scmd being null in
> > srp_handle_recv() is due to a
On Tue, Dec 20, 2011 at 04:36:35PM -0800, Roland Dreier wrote:
> On Mon, Dec 19, 2011 at 11:19 PM, Eli Cohen wrote:
> > I considered this but that means that you serialize attach/detach
> > operations at ib core. Using a spinlock to protect the list allows
> > more concurrency. After all, we hit t
>
>> Would it help, if we provide our patches for open-iscsi and IB/iSER>
>> 2.6.32 to bring that into mainline OFED?
>
> As Or notes, OFED is providing the kernel modules more than the iscsi code
> drop. Would be better for all (cough cough) to push changes back to the
> iscsi initiator maintai
2011/12/20 Or Gerlitz :
>
> horses, please, stay at home, or at least run a little bit slower,
> just for you - from 2 minutes
> ago - iser works well with 3.2.0-rc5 (its say -dirty b/c its a
> development system and the kernel has some patches, but not iser ones)
> and iscsi-initiator-utils of 6.2
63 matches
Mail list logo
