linux-next: manual merge of the scsi tree with the infiniband tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/infiniband/ulp/iser/iser_initiator.c between commit b7f04513090c
(IB/iser: Accept session-cmds_max from user space) from the infiniband
tree and commit 6a06a4b8cff8 ([SCSI] IB/iser: Add Discovery support)
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/infiniband/ulp/iser/iser_initiator.c
index bdc38f4,b31fa1d..000
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers/infiniband/ulp/iser/iser_initiator.c
@@@ -342,10 -249,15 +343,16 @@@ static int iser_post_rx_bufs(struct isc
WARN_ON(iser_conn-ib_conn-post_recv_buf_count != 1);
WARN_ON(atomic_read(iser_conn-ib_conn-post_send_buf_count) != 0);
- iser_dbg(Initially post: %d\n, iser_conn-ib_conn-min_posted_rx);
+ if (session-discovery_sess) {
+ iser_info(Discovery session, re-using login RX buffer\n);
+ return 0;
+ } else
+ iser_info(Normal session, posting batch of RX %d buffers\n,
-ISER_MIN_POSTED_RX);
++iser_conn-ib_conn-min_posted_rx);
+
/* Initial post receive buffers */
- if (iser_post_recvm(iser_conn-ib_conn, ISER_MIN_POSTED_RX))
+ if (iser_post_recvm(iser_conn-ib_conn,
+ iser_conn-ib_conn-min_posted_rx))
return -ENOMEM;
return 0;
pgpGesHGgQK84.pgp
Description: PGP signature
Re: [PATCH] IB/srp: add change_queue_depth and change_queue_type support
On 08/26/13 15:53, Jack Wang wrote:
From: Jack Wang jinpu.w...@profitbricks.com
Date: Mon, 26 Aug 2013 15:50:03 +0200
Subject: [PATCH] IB/srp: add change_queue_depth/change_queue_type support
Signed-off-by: Jack Wang jinpu.w...@profitbricks.com
Hello Jack,
When posting a Linux kernel patch it is not only expected that the
commit message explains what is changed but also why these changes have
been made. What made you look into adding dynamic queue depth support ?
Had you perhaps run into a performance issue, an issue that is solved by
this patch ? If so, did it occur with all storage types or only with
certain storage types (e.g. hard disks or hard disk arrays) ? How much
did this patch improve performance ?
@@ -1697,6 +1698,56 @@ static int srp_cm_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *event)
return 0;
}
+/**
+ * srp_change_queue_type - changing device queue tag type
Please leave a blank line between the end of one function and the header
of the next function.
+
+/**
+ * srp_change_queue_depth - setting device queue depth
+ * @sdev: scsi device struct
+ * @qdepth: requested queue depth
+ * @reason: SCSI_QDEPTH_DEFAULT/SCSI_QDEPTH_QFULL/SCSI_QDEPTH_RAMP_UP
+ * (see include/scsi/scsi_host.h for definition)
+ *
+ * Returns queue depth.
+ */
+static int
+srp_change_queue_depth(struct scsi_device *sdev, int qdepth, int reason)
+{
+ if (reason == SCSI_QDEPTH_DEFAULT || reason == SCSI_QDEPTH_RAMP_UP) {
+ struct Scsi_Host *shost = sdev-host;
+ int max_depth;
Nothing important, but I think in the Linux kernel there is a preference
to declare variables at the outermost scope.
+ if (!sdev-tagged_supported)
+ max_depth = 1;
This code seems incorrect to me for the SRP protocol. In the SRP
protocol, although there is no TCQ support, queue depths above one are
supported.
I also have a more general remark. There is no TCQ support in the SRP
protocol, which means that sdev-tagged_supported is always 0 (false).
So my recommendation is to leave out all code that depends on if
(sdev-tagged_supported) and to remove the if
(!sdev-tagged_supported) tests.
Bart.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/srp: add change_queue_depth and change_queue_type support
On 08/27/2013 10:31 AM, Bart Van Assche wrote:
On 08/26/13 15:53, Jack Wang wrote:
From: Jack Wang jinpu.w...@profitbricks.com
Date: Mon, 26 Aug 2013 15:50:03 +0200
Subject: [PATCH] IB/srp: add change_queue_depth/change_queue_type support
Signed-off-by: Jack Wang jinpu.w...@profitbricks.com
Hello Jack,
When posting a Linux kernel patch it is not only expected that the
commit message explains what is changed but also why these changes have
been made. What made you look into adding dynamic queue depth support ?
Had you perhaps run into a performance issue, an issue that is solved by
this patch ? If so, did it occur with all storage types or only with
certain storage types (e.g. hard disks or hard disk arrays) ? How much
did this patch improve performance ?
Hello Bart,
Thanks for informative comments.
The intention to add change_queue_type/change_queue_type support is we
saw some times srp run into scsi error handle when storage server(scst)
is busy, we want reduce the queue_depth at this point to avoid such
situation, as I understand about scsi core, it will try to auto change
queue depth according to scsi command results, when success ramp up
queue depth, and when storage return busy or queue full, it reduce the
queue depth.
The README of SCST suggests:
Unfortunately, currently SCST lacks dynamic I/O flow control, when the
queue depth on the target is dynamically decreased/increased based on
how slow/fast the backstorage speed comparing to the target link. So,
there are 6 possible actions, which you can do to workaround or fix this
issue in this case:
1. Ignore incoming task management (TM) commands. It's fine if there are
not too many of them, so average performance isn't hurt and the
corresponding device isn't getting put offline, i.e. if the backstorage
isn't too slow.
2. Decrease /sys/block/sdX/device/queue_depth on the initiator in case
if it's Linux (see below how) or/and SCST_MAX_TGT_DEV_COMMANDS constant
in scst_priv.h file until you stop seeing incoming TM commands.
ISCSI-SCST driver also has its own iSCSI specific parameter for that,
see its README file.
To decrease device queue depth on Linux initiators you can run command:
# echo Y /sys/block/sdX/device/queue_depth
where Y is the new number of simultaneously queued commands, X - your
imported device letter, like 'a' for sda device. There are no special
limitations for Y value, it can be any value from 1 to possible maximum
(usually, 32), so start from dividing the current value on 2, i.e. set
16, if /sys/block/sdX/device/queue_depth contains 32.
3. Increase the corresponding timeout on the initiator. For Linux it is
located in
/sys/devices/platform/host*/session*/target*:0:0/*:0:0:1/timeout. It can
be done automatically by an udev rule. For instance, the following
rule will increase it to 300 seconds:
SUBSYSTEM==scsi, KERNEL==[0-9]*:[0-9]*, ACTION==add,
ATTR{type}==0|7|14, ATTR{timeout}=300
By default, this timeout is 30 or 60 seconds, depending on your
distribution.
4. Try to avoid such seek intensive workloads.
5. Increase speed of the target's backstorage.
6. Implement in SCST dynamic I/O flow control. This will be an ultimate
solution. See Dynamic I/O flow control section on
http://scst.sourceforge.net/contributing.html page for possible
implementation idea.
I'm approaching the second one.
@@ -1697,6 +1698,56 @@ static int srp_cm_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *event)
return 0;
}
+/**
+ * srp_change_queue_type - changing device queue tag type
Please leave a blank line between the end of one function and the header
of the next function.
thanks, will do
+
+/**
+ * srp_change_queue_depth - setting device queue depth
+ * @sdev: scsi device struct
+ * @qdepth: requested queue depth
+ * @reason: SCSI_QDEPTH_DEFAULT/SCSI_QDEPTH_QFULL/SCSI_QDEPTH_RAMP_UP
+ * (see include/scsi/scsi_host.h for definition)
+ *
+ * Returns queue depth.
+ */
+static int
+srp_change_queue_depth(struct scsi_device *sdev, int qdepth, int reason)
+{
+if (reason == SCSI_QDEPTH_DEFAULT || reason ==
SCSI_QDEPTH_RAMP_UP) {
+struct Scsi_Host *shost = sdev-host;
+int max_depth;
Nothing important, but I think in the Linux kernel there is a preference
to declare variables at the outermost scope.
sure, will do.
+if (!sdev-tagged_supported)
+max_depth = 1;
This code seems incorrect to me for the SRP protocol. In the SRP
protocol, although there is no TCQ support, queue depths above one are
supported.
I also have a more general remark. There is no TCQ support in the SRP
protocol, which means that sdev-tagged_supported is always 0 (false).
So my recommendation is to leave out all code that depends on if
(sdev-tagged_supported) and to remove the if
(!sdev-tagged_supported) tests.
Good to know, thanks for share will fix this.
KR
Jack
Bart.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a
RE: [PATCH 0/2] fs: supply inode uid/gid setting interface
Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface On 2013/8/23 12:10, Greg KH wrote: On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote: This patchset implements an accessor functions to set uid/gid in inode struct. Just finish code clean up. Why? It can introduce a new function to reduce some codes. Just clean up. In what sense is it a 'cleanup' ? To my mind it just means that anyone reading the code has to go and look at another file in order to see what the function does (it might be expected to be more complex). It also adds run time cost, while probably not directly measurable I suspect it more than doubles the execution time of that code fragment - do that everywhere and the system will run like a sick pig. The only real use for accessor functions is when you don't want the structure offset to be public. In this case that is obviously not the case since all the drivers are directly accessing other members of the structure. David -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 for-next 3/4] IB/core: Export ib_create/destroy_flow through uverbs
On 26/8/2013 10:01 PM, Roland Dreier wrote:
On Wed, Aug 14, 2013 at 3:58 AM, Or Gerlitz ogerl...@mellanox.com wrote:
+ if (cmd.flow_attr.num_of_specs) {
+ kern_flow_attr = kmalloc(cmd.flow_attr.size, GFP_KERNEL);
+ if (!kern_flow_attr)
+ return -ENOMEM;
+
+ memcpy(kern_flow_attr, cmd.flow_attr, sizeof(*kern_flow_attr));
+ kern_attr_size = cmd.flow_attr.size - sizeof(cmd) -
sizeof(struct ib_uverbs_cmd_hdr_ex);
+ if (copy_from_user(kern_flow_attr + 1, buf + sizeof(cmd),
+ kern_attr_size)) {
+ err = -EFAULT;
+ goto err_free_attr;
+ }
+ } else {
This looks risky... it's basically taking size fields passed in from
userspace and trusting them enough to pass directly to kmalloc. In
fact kern_attr_size is a plain int and I don't see even enogh checking
to make sure it's positive (nothing I see enforces that
cmd.flow_attr.size sizeof(cmd) + sizeof(struct
ib_uverbs_cmd_hdr_ex)).
- R.
You are correct. We'll fix it in V6.
- Matan
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 opensm] Improve m_key lookup
From: Alex Netes ale...@mellanox.com
Lookup for M_Key only when you don't know the M_Key (till you get
GetResp(PortInfo) from the port). In other cases use the M_Key stored in
the PortInfo.
Signed-off-by: Alex Netes ale...@mellanox.com
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
include/iba/ib_types.h | 59
include/opensm/osm_sm.h| 29 -
opensm/osm_guid_mgr.c |2 +
opensm/osm_lid_mgr.c |1 +
opensm/osm_link_mgr.c | 14 +++---
opensm/osm_mcast_mgr.c | 13 ++---
opensm/osm_node_info_rcv.c | 18 +++--
opensm/osm_perfmgr.c |6 ++--
opensm/osm_pkey_mgr.c | 18 -
opensm/osm_port_info_rcv.c | 27 +++
opensm/osm_qos.c |9 ++
opensm/osm_req.c | 37 ++-
opensm/osm_sm_state_mgr.c |5 ++-
opensm/osm_state_mgr.c | 30 ++
opensm/osm_sw_info_rcv.c | 10 +++---
opensm/osm_trap_rcv.c | 11 +++-
opensm/osm_ucast_mgr.c |7 +++-
17 files changed, 234 insertions(+), 62 deletions(-)
diff --git a/include/iba/ib_types.h b/include/iba/ib_types.h
index 5c238ae..24bad76 100644
--- a/include/iba/ib_types.h
+++ b/include/iba/ib_types.h
@@ -6242,6 +6242,65 @@ ib_port_info_set_phy_and_overrun_err_thd(IN
ib_port_info_t * const p_pi,
* SEE ALSO
*/
+/f* IBA Base: Types/ib_port_info_get_m_key
+* NAME
+* ib_port_info_get_m_key
+*
+* DESCRIPTION
+* Gets the M_Key
+*
+* SYNOPSIS
+*/
+static inline ib_net64_t OSM_API
+ib_port_info_get_m_key(IN const ib_port_info_t * const p_pi)
+{
+ return p_pi-m_key;
+}
+
+/*
+* PARAMETERS
+* p_pi
+* [in] Pointer to a PortInfo attribute.
+*
+* RETURN VALUES
+* M_Key.
+*
+* NOTES
+*
+* SEE ALSO
+*/
+
+/f* IBA Base: Types/ib_port_info_set_m_key
+* NAME
+* ib_port_info_set_m_key
+*
+* DESCRIPTION
+* Sets the M_Key value
+*
+* SYNOPSIS
+*/
+static inline void OSM_API
+ib_port_info_set_m_key(IN ib_port_info_t * const p_pi, IN ib_net64_t m_key)
+{
+ p_pi-m_key = m_key;
+}
+
+/*
+* PARAMETERS
+* p_pi
+* [in] Pointer to a PortInfo attribute.
+* m_key
+* [in] M_Key value.
+*
+* RETURN VALUES
+* None.
+*
+* NOTES
+*
+* SEE ALSO
+*/
+
+
/s* IBA Base: Types/ib_mlnx_ext_port_info_t
* NAME
* ib_mlnx_ext_port_info_t
diff --git a/include/opensm/osm_sm.h b/include/opensm/osm_sm.h
index 710d206..e48c549 100644
--- a/include/opensm/osm_sm.h
+++ b/include/opensm/osm_sm.h
@@ -402,6 +402,7 @@ ib_api_status_t osm_sm_bind(IN osm_sm_t * p_sm, IN
ib_net64_t port_guid);
*/
ib_api_status_t osm_req_get(IN osm_sm_t * sm, IN const osm_dr_path_t * p_path,
IN ib_net16_t attr_id, IN ib_net32_t attr_mod,
+ IN boolean_t find_mkey, ib_net64_t m_key,
IN cl_disp_msgid_t err_msg,
IN const osm_madw_context_t * p_context);
/*
@@ -419,6 +420,13 @@ ib_api_status_t osm_req_get(IN osm_sm_t * sm, IN const
osm_dr_path_t * p_path,
* attr_mod
* [in] Attribute modifier for this request.
*
+* find_mkey
+* [in] Flag to indicate whether the M_Key should be looked up for
+* this MAD.
+* m_key
+* [in] M_Key value to be send with this MAD. Applied, only when
+* find_mkey is FALSE.
+*
* err_msg
* [in] Message id with which to post this MAD if an error occurs.
*
@@ -467,7 +475,8 @@ void osm_send_req_mad(IN osm_sm_t * sm, IN osm_madw_t
*p_madw);
osm_madw_t *osm_prepare_req_set(IN osm_sm_t * sm, IN const osm_dr_path_t *
p_path,
IN const uint8_t * p_payload,
IN size_t payload_size, IN ib_net16_t attr_id,
- IN ib_net32_t attr_mod, IN cl_disp_msgid_t
err_msg,
+ IN ib_net32_t attr_mod, IN boolean_t find_mkey,
+ IN ib_net64_t m_key, IN cl_disp_msgid_t err_msg,
IN const osm_madw_context_t * p_context);
/*
* PARAMETERS
@@ -489,6 +498,13 @@ osm_madw_t *osm_prepare_req_set(IN osm_sm_t * sm, IN const
osm_dr_path_t * p_pat
* attr_mod
* [in] Attribute modifier for this request.
*
+* find_mkey
+* [in] Flag to indicate whether the M_Key should be looked up for
+* this MAD.
+* m_key
+* [in] M_Key value to be send with this MAD. Applied, only when
+* find_mkey is FALSE.
+*
* err_msg
* [in] Message id with which to post this MAD if an error occurs.
*
@@ -513,7 +529,8 @@ osm_madw_t *osm_prepare_req_set(IN osm_sm_t * sm, IN const
osm_dr_path_t * p_pat
ib_api_status_t osm_req_set(IN osm_sm_t * sm, IN const osm_dr_path_t * p_path,
Re: [PATCH libibverbs V2] Add new verb: uv_query_port_max_datagram()
Bump. This is V2 of the patch, which removes the ABI issue: libibverbs
directly calls the command in the kernel (without going through the provider
plugin).
On Aug 21, 2013, at 5:22 PM, Jeff Squyres jsquy...@cisco.com wrote:
Per lengthy discussion on the linux-rdma list, add a new verb to get
max datagram size (in bytes) since the methods for retrieving MTU
values are limited to a finite enum set, and are difficult to change
for backwards compatibility reasons.
Also add corresponding command: uv_cmd_query_port_max_datagram().
Since this is a new verb, there was no need to add a _V2 enum for the
command macro, which required adding a UB_INIT_CMD_RESP() macro.
If the kernel does not support the new QUERY_PORT_MAX_DATAGRAM
command, fall back to returning the int-ized MTU enum from
ibv_cmd_query_port().
Note that the name for this verb was chosen with the following
rationale:
* After discussion with Roland, use the prefix uv instead of ibv,
since this verb is generic to both Ethernet, InfiniBand, and
whatever other transports are underneath.
* query was used (vs. get) because it invokes a command (vs. a
struct lookup)
If the community likes this approach, I'll send the corresponding
kernel patch.
Difference from V1
==
Do not add this verb to the devops struct (because that would break ABI).
Instead, just have uv_query_port_max_datagram() directly invoke
uv_cmd_query_port_max_datagram().
Signed-off-by: Jeff Squyres jsquy...@cisco.com
---
Makefile.am | 3 +-
examples/devinfo.c | 7 +
include/infiniband/driver.h | 4 +++
include/infiniband/kern-abi.h| 17 +++-
include/infiniband/verbs.h | 6
man/uv_query_port_max_datagram.3 | 59
src/cmd.c| 54
src/ibverbs.h| 8 ++
src/libibverbs.map | 2 ++
src/verbs.c | 13 +
10 files changed, 171 insertions(+), 2 deletions(-)
create mode 100644 man/uv_query_port_max_datagram.3
diff --git a/Makefile.am b/Makefile.am
index 40e83be..51fe5d5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -54,7 +54,8 @@ man_MANS = man/ibv_asyncwatch.1 man/ibv_devices.1
man/ibv_devinfo.1 \
man/ibv_post_srq_recv.3 man/ibv_query_device.3 man/ibv_query_gid.3
\
man/ibv_query_pkey.3 man/ibv_query_port.3 man/ibv_query_qp.3 \
man/ibv_query_srq.3 man/ibv_rate_to_mult.3 man/ibv_reg_mr.3
\
-man/ibv_req_notify_cq.3 man/ibv_resize_cq.3 man/ibv_rate_to_mbps.3
+man/ibv_req_notify_cq.3 man/ibv_resize_cq.3 man/ibv_rate_to_mbps.3
\
+man/uv_query_port_max_datagram.3
DEBIAN = debian/changelog debian/compat debian/control debian/copyright \
debian/ibverbs-utils.install debian/libibverbs1.install \
diff --git a/examples/devinfo.c b/examples/devinfo.c
index ff078e4..f51620b 100644
--- a/examples/devinfo.c
+++ b/examples/devinfo.c
@@ -209,6 +209,7 @@ static int print_hca_cap(struct ibv_device *ib_dev,
uint8_t ib_port)
struct ibv_port_attr port_attr;
int rc = 0;
uint8_t port;
+ uint32_t max_datagram;
char buf[256];
ctx = ibv_open_device(ib_dev);
@@ -298,6 +299,11 @@ static int print_hca_cap(struct ibv_device *ib_dev,
uint8_t ib_port)
fprintf(stderr, Failed to query port %u props\n,
port);
goto cleanup;
}
+ rc = uv_query_port_max_datagram(ctx, port, max_datagram);
+ if (rc) {
+ fprintf(stderr, Failed to query port %u max datagram
size\n, port);
+ goto cleanup;
+ }
printf(\t\tport:\t%d\n, port);
printf(\t\t\tstate:\t\t\t%s (%d)\n,
port_state_str(port_attr.state), port_attr.state);
@@ -305,6 +311,7 @@ static int print_hca_cap(struct ibv_device *ib_dev,
uint8_t ib_port)
mtu_str(port_attr.max_mtu), port_attr.max_mtu);
printf(\t\t\tactive_mtu:\t\t%s (%d)\n,
mtu_str(port_attr.active_mtu), port_attr.active_mtu);
+ printf(\t\t\tmax_datagram_size:\t%u\n, max_datagram);
printf(\t\t\tsm_lid:\t\t\t%d\n, port_attr.sm_lid);
printf(\t\t\tport_lid:\t\t%d\n, port_attr.lid);
printf(\t\t\tport_lmc:\t\t0x%02x\n, port_attr.lmc);
diff --git a/include/infiniband/driver.h b/include/infiniband/driver.h
index 9a81416..6e1236c 100644
--- a/include/infiniband/driver.h
+++ b/include/infiniband/driver.h
@@ -67,6 +67,10 @@ int ibv_cmd_query_device(struct ibv_context *context,
int ibv_cmd_query_port(struct ibv_context *context, uint8_t port_num,
struct ibv_port_attr *port_attr,
struct ibv_query_port *cmd, size_t cmd_size);
+int
Re: [PATCH] IB/srp: add change_queue_depth and change_queue_type support
snip This code seems incorrect to me for the SRP protocol. In the SRP protocol, although there is no TCQ support, queue depths above one are supported. I also have a more general remark. There is no TCQ support in the SRP protocol, which means that sdev-tagged_supported is always 0 (false). So my recommendation is to leave out all code that depends on if (sdev-tagged_supported) and to remove the if (!sdev-tagged_supported) tests. Bart. Hello Bart, I look into scsi core about above statement: In drivers/scsi/scsi_scan.c:865: if ((sdev-scsi_level = SCSI_2) (inq_result[7] 2) !(*bflags BLIST_NOTQ)) sdev-tagged_supported = 1; It check inquiry result byte 7 with cmdque bit. inquiry result of a disk export through srp/srpt sg_inq /dev/sdb standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x06 [SPC-4] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=1 (VS=0) [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=66 (0x42) Peripheral device type: disk Vendor identification: SCST_FIO Product identification: vol0 Product revision level: 300 Unit serial number: 609bbc13 So the sdev_tagged_supported will be set in this case In srpr16 p38 The TASK ATTRIBUTE field is defined in table 21, it includes support for: head of queue ordered simple Do I miss something? Regards, Jack -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/srp: add change_queue_depth and change_queue_type support
On 08/27/13 18:39, Jack Wang wrote: I look into scsi core about above statement: In drivers/scsi/scsi_scan.c:865: if ((sdev-scsi_level = SCSI_2) (inq_result[7] 2) !(*bflags BLIST_NOTQ)) sdev-tagged_supported = 1; It check inquiry result byte 7 with cmdque bit. Ah, thanks for looking that up. I had overlooked that statement. So it should be fine to keep all the code that depends on the value of sdev-tagged_supported. Regards, Bart. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 for-next 1/4] IB/core: Add receive Flow Steering support
On 26/8/2013 10:07 PM, Roland Dreier wrote:
On Wed, Aug 14, 2013 at 3:58 AM, Or Gerlitz ogerl...@mellanox.com wrote:
+struct _ib_flow_spec {
Just out of curiousity, why does this structure name start with _?
In fact why have the struct at all, since all it's doing is wrapping
an anonymous union? Does the following work:
+union ib_flow_spec {
+ struct {
+ enum ib_flow_spec_type type;
+ u16 size;
+ };
+ struct ib_flow_spec_eth eth;
+ struct ib_flow_spec_ipv4 ipv4;
+ struct ib_flow_spec_tcp_udp tcp_udp;
+ };
+};
If that works, then that seems a lot nicer to me...
- R.
There's no real good reason for that. The struct isn't needed and we'll
definitely change that for V6.
- Matan
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] RDMA/ocrdma: Add support for FRMR.
Hello Naresh, Good question. I'm not sure though what Roland prefers. Bart. On 08/27/13 16:33, B.A.L.N.Raju Gottumukkala wrote: Hi Bert, Sure I will change that. Some of the patches in this patch series will also get affected because of that. It will be easy for us to address that as a separate patch on top of this patch series. Does this sound Ok ? Thanks!! Naresh. -Original Message- From: Bart Van Assche [mailto:bvanass...@acm.org] Sent: Monday, August 26, 2013 3:39 PM To: bgottumu...@emulex.com Cc: linux-rdma@vger.kernel.org; rol...@kernel.org; B.A.L.N.Raju Gottumukkala Subject: Re: [PATCH 02/14] RDMA/ocrdma: Add support for FRMR. On 08/26/13 11:57, bgottumu...@emulex.com wrote: From: Naresh Gottumukkala bgottumukk...@emulex.com Also get the max_srq value from query_config mailbox response. Signed-off-by: Naresh Gottumukkala bgottumukk...@emulex.com There are already a few drivers upstream in which the fast register memory region work request is abbreviated as FRWR. Please consider renaming FRMR into FRWR in order to avoid confusion and in order to make it easier to find related code with grep in the kernel tree. Thanks, Bart. $ git grep -i '[^r]frwr' rdreier-infiniband/for-next | cat rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c:static __be64 frwr_mkey_mask(void) rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c:static void set_frwr_umr_segment(struct mlx5_wqe_umr_ctrl_seg *umr, rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c:umr-mkey_mask = frwr_mkey_mask(); rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c:static void set_frwr_pages(struct mlx5_wqe_data_seg *dseg, rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c:static int set_frwr_li_wr(void **seg, struct ib_send_wr *wr, int *size, rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c: set_frwr_umr_segment(*seg, wr, li); rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c: set_frwr_pages(*seg, wr, mdev, pd, writ); rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c: err = set_frwr_li_wr(seg, wr, size, mdev, to_mpd(ibqp-pd), qp); rdreier-infiniband/for-next:drivers/infiniband/hw/mlx5/qp.c: err = set_frwr_li_wr(seg, wr, size, mdev, to_mpd(ibqp-pd), qp); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h: /* For fast registration - FRWR */ rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h: } frwr; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h:int iser_reg_rdma_mem_frwr(struct iscsi_iser_task *task, rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h:void iser_unreg_mem_frwr(struct iscsi_iser_task *iser_task, rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h:int iser_create_frwr_pool(struct iser_conn *ib_conn, unsigned cmds_max); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iscsi_iser.h:void iser_free_frwr_pool(struct iser_conn *ib_conn); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_memory.c: * iser_reg_rdma_mem_frwr - Registers memory intended for RDMA, rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_memory.c:int iser_reg_rdma_mem_frwr(struct iscsi_iser_task *iser_task, rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_memory.c: desc = list_first_entry(ib_conn-fastreg.frwr.pool, rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_memory.c: list_add_tail(desc-list, ib_conn-fastreg.frwr.pool); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: iser_info(FRWR supported, using FRWR for registration\n); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: device-iser_alloc_rdma_reg_res = iser_create_frwr_pool; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: device-iser_free_rdma_reg_res = iser_free_frwr_pool; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: device-iser_reg_rdma_mem = iser_reg_rdma_mem_frwr; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: device-iser_unreg_rdma_mem = iser_unreg_mem_frwr; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: iser_err(IB device does not support FMRs nor FRWRs, can't register memory\n); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: * iser_create_frwr_pool - Creates pool of fast_reg descriptors rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c:int iser_create_frwr_pool(struct iser_conn *ib_conn, unsigned cmds_max) rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: INIT_LIST_HEAD(ib_conn-fastreg.frwr.pool); rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c: ib_conn-fastreg.frwr.pool_size = 0; rdreier-infiniband/for-next:drivers/infiniband/ulp/iser/iser_verbs.c:
RE: [PATCH librdmacm 0/3] no IBV_SEND_INLINE thus memory registration required on QLogic/Intel HCA
While doing some tests, I've found that rdma_client failed on my QLogic/Intel QLE7340 / QLE7342 HCA: # rdma_client rdma_client: start rdma_post_send 22 rdma_client: end -1 I had a deeper look on the examples and found that max_inline_data was returned as 0, The man page to ibv_create_qp() states: The function ibv_create_qp() will update the qp_init_attr-cap struct with the actual QP values of the QP that was created; the values will be greater than or equal to the values requested. From this, it sounds like there is a bug in the Intel provider. The ibv_create_qp call should have failed. - Sean -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH librdmacm] examples: adds cmtime to .gitignore
thanks - applied -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
