Re: [PATCH v1 00/24] New fast registration API
Hi Bart, How has the converted SRP initiator driver been tested ? With the kernel tree that is available on branch reg_api.4 That's odd. Although I haven't formally submitted reg_api.4 yet, I did test ib_srp initiator against upstream srpt over CX3 (mlx4) and CX4 (mlx5). I ran connect, disconnect, stress IO of all block sizes and some unaligned block-IO and SG_IO test utilities. It all seems to pass for me. Just this morning (my morning) I tested the v2 set on iser, srp, nfs. I placed that in branch reg_api.5. Would you mind running reg_api.5 and see if this issue persist (I would be surprised because I haven't seen any sign of it)? I'm waiting for your input before submitting v2 of this series. Thanks, Sagi. -- 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 RFC] IB/mad: remove obsolete snoop interface
From: Ira Weiny
This interface has no current users and is obsolete.
Signed-off-by: Ira Weiny
---
This has undergone a medium level of testing. I have run it against
mlx4, qib, and OPA hardware and it does not seem to cause any regressions.
drivers/infiniband/core/mad.c | 226 +
drivers/infiniband/core/mad_priv.h | 13 ---
2 files changed, 5 insertions(+), 234 deletions(-)
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 4b5c72311deb..08ab92604e88 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -428,132 +428,12 @@ error1:
}
EXPORT_SYMBOL(ib_register_mad_agent);
-static inline int is_snooping_sends(int mad_snoop_flags)
-{
- return (mad_snoop_flags &
- (/*IB_MAD_SNOOP_POSTED_SENDS |
-IB_MAD_SNOOP_RMPP_SENDS |*/
-IB_MAD_SNOOP_SEND_COMPLETIONS /*|
-IB_MAD_SNOOP_RMPP_SEND_COMPLETIONS*/));
-}
-
-static inline int is_snooping_recvs(int mad_snoop_flags)
-{
- return (mad_snoop_flags &
- (IB_MAD_SNOOP_RECVS /*|
-IB_MAD_SNOOP_RMPP_RECVS*/));
-}
-
-static int register_snoop_agent(struct ib_mad_qp_info *qp_info,
- struct ib_mad_snoop_private *mad_snoop_priv)
-{
- struct ib_mad_snoop_private **new_snoop_table;
- unsigned long flags;
- int i;
-
- spin_lock_irqsave(&qp_info->snoop_lock, flags);
- /* Check for empty slot in array. */
- for (i = 0; i < qp_info->snoop_table_size; i++)
- if (!qp_info->snoop_table[i])
- break;
-
- if (i == qp_info->snoop_table_size) {
- /* Grow table. */
- new_snoop_table = krealloc(qp_info->snoop_table,
- sizeof mad_snoop_priv *
- (qp_info->snoop_table_size + 1),
- GFP_ATOMIC);
- if (!new_snoop_table) {
- i = -ENOMEM;
- goto out;
- }
-
- qp_info->snoop_table = new_snoop_table;
- qp_info->snoop_table_size++;
- }
- qp_info->snoop_table[i] = mad_snoop_priv;
- atomic_inc(&qp_info->snoop_count);
-out:
- spin_unlock_irqrestore(&qp_info->snoop_lock, flags);
- return i;
-}
-
-struct ib_mad_agent *ib_register_mad_snoop(struct ib_device *device,
- u8 port_num,
- enum ib_qp_type qp_type,
- int mad_snoop_flags,
- ib_mad_snoop_handler snoop_handler,
- ib_mad_recv_handler recv_handler,
- void *context)
-{
- struct ib_mad_port_private *port_priv;
- struct ib_mad_agent *ret;
- struct ib_mad_snoop_private *mad_snoop_priv;
- int qpn;
-
- /* Validate parameters */
- if ((is_snooping_sends(mad_snoop_flags) && !snoop_handler) ||
- (is_snooping_recvs(mad_snoop_flags) && !recv_handler)) {
- ret = ERR_PTR(-EINVAL);
- goto error1;
- }
- qpn = get_spl_qp_index(qp_type);
- if (qpn == -1) {
- ret = ERR_PTR(-EINVAL);
- goto error1;
- }
- port_priv = ib_get_mad_port(device, port_num);
- if (!port_priv) {
- ret = ERR_PTR(-ENODEV);
- goto error1;
- }
- /* Allocate structures */
- mad_snoop_priv = kzalloc(sizeof *mad_snoop_priv, GFP_KERNEL);
- if (!mad_snoop_priv) {
- ret = ERR_PTR(-ENOMEM);
- goto error1;
- }
-
- /* Now, fill in the various structures */
- mad_snoop_priv->qp_info = &port_priv->qp_info[qpn];
- mad_snoop_priv->agent.device = device;
- mad_snoop_priv->agent.recv_handler = recv_handler;
- mad_snoop_priv->agent.snoop_handler = snoop_handler;
- mad_snoop_priv->agent.context = context;
- mad_snoop_priv->agent.qp = port_priv->qp_info[qpn].qp;
- mad_snoop_priv->agent.port_num = port_num;
- mad_snoop_priv->mad_snoop_flags = mad_snoop_flags;
- init_completion(&mad_snoop_priv->comp);
- mad_snoop_priv->snoop_index = register_snoop_agent(
- &port_priv->qp_info[qpn],
- mad_snoop_priv);
- if (mad_snoop_priv->snoop_index < 0) {
- ret = ERR_PTR(mad_snoop_priv->snoop_index);
- goto error2;
- }
-
- atomic_set(&mad_snoop_priv->refcount, 1);
- return &mad_snoop_priv->agent;
-
-error2:
- kfree(mad_snoop_priv);
-error1:
- return ret;
-}
-EXPORT_SYMBOL(ib_register_mad_snoop);
-
static inline void deref_mad_agent(struct ib_mad_agent_private *mad_agent
RE: [PATCH] infiniband:Remove unneeded function definitions and declarations in the file, mad.c
>
> This removes the definitions and declarations of the functions
> ib_register_mad_snoop and register_snoop_agent in the file mad.c due to have
> no more callers and thus can be removed to reduce code size of this particular
> file.
I don't disagree with removing the snoop code, however, I don't believe this
goes far enough. I have a similar patch which removes the snoop interface
completely. It has a medium level of testing.
I'll send it to the list for review. If you concur with the larger removal,
I'd be happy to add your signed-off by line.
Thanks,
Ira
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/infiniband/core/mad.c | 98
> ---
> 1 file changed, 98 deletions(-)
>
> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> index 4b5c723..e5978e1 100644
> --- a/drivers/infiniband/core/mad.c
> +++ b/drivers/infiniband/core/mad.c
> @@ -444,104 +444,6 @@ static inline int is_snooping_recvs(int
> mad_snoop_flags)
>IB_MAD_SNOOP_RMPP_RECVS*/));
> }
>
> -static int register_snoop_agent(struct ib_mad_qp_info *qp_info,
> - struct ib_mad_snoop_private
> *mad_snoop_priv)
> -{
> - struct ib_mad_snoop_private **new_snoop_table;
> - unsigned long flags;
> - int i;
> -
> - spin_lock_irqsave(&qp_info->snoop_lock, flags);
> - /* Check for empty slot in array. */
> - for (i = 0; i < qp_info->snoop_table_size; i++)
> - if (!qp_info->snoop_table[i])
> - break;
> -
> - if (i == qp_info->snoop_table_size) {
> - /* Grow table. */
> - new_snoop_table = krealloc(qp_info->snoop_table,
> -sizeof mad_snoop_priv *
> -(qp_info->snoop_table_size + 1),
> -GFP_ATOMIC);
> - if (!new_snoop_table) {
> - i = -ENOMEM;
> - goto out;
> - }
> -
> - qp_info->snoop_table = new_snoop_table;
> - qp_info->snoop_table_size++;
> - }
> - qp_info->snoop_table[i] = mad_snoop_priv;
> - atomic_inc(&qp_info->snoop_count);
> -out:
> - spin_unlock_irqrestore(&qp_info->snoop_lock, flags);
> - return i;
> -}
> -
> -struct ib_mad_agent *ib_register_mad_snoop(struct ib_device *device,
> -u8 port_num,
> -enum ib_qp_type qp_type,
> -int mad_snoop_flags,
> -ib_mad_snoop_handler
> snoop_handler,
> -ib_mad_recv_handler recv_handler,
> -void *context)
> -{
> - struct ib_mad_port_private *port_priv;
> - struct ib_mad_agent *ret;
> - struct ib_mad_snoop_private *mad_snoop_priv;
> - int qpn;
> -
> - /* Validate parameters */
> - if ((is_snooping_sends(mad_snoop_flags) && !snoop_handler) ||
> - (is_snooping_recvs(mad_snoop_flags) && !recv_handler)) {
> - ret = ERR_PTR(-EINVAL);
> - goto error1;
> - }
> - qpn = get_spl_qp_index(qp_type);
> - if (qpn == -1) {
> - ret = ERR_PTR(-EINVAL);
> - goto error1;
> - }
> - port_priv = ib_get_mad_port(device, port_num);
> - if (!port_priv) {
> - ret = ERR_PTR(-ENODEV);
> - goto error1;
> - }
> - /* Allocate structures */
> - mad_snoop_priv = kzalloc(sizeof *mad_snoop_priv, GFP_KERNEL);
> - if (!mad_snoop_priv) {
> - ret = ERR_PTR(-ENOMEM);
> - goto error1;
> - }
> -
> - /* Now, fill in the various structures */
> - mad_snoop_priv->qp_info = &port_priv->qp_info[qpn];
> - mad_snoop_priv->agent.device = device;
> - mad_snoop_priv->agent.recv_handler = recv_handler;
> - mad_snoop_priv->agent.snoop_handler = snoop_handler;
> - mad_snoop_priv->agent.context = context;
> - mad_snoop_priv->agent.qp = port_priv->qp_info[qpn].qp;
> - mad_snoop_priv->agent.port_num = port_num;
> - mad_snoop_priv->mad_snoop_flags = mad_snoop_flags;
> - init_completion(&mad_snoop_priv->comp);
> - mad_snoop_priv->snoop_index = register_snoop_agent(
> - &port_priv->qp_info[qpn],
> - mad_snoop_priv);
> - if (mad_snoop_priv->snoop_index < 0) {
> - ret = ERR_PTR(mad_snoop_priv->snoop_index);
> - goto error2;
> - }
> -
> - atomic_set(&mad_snoop_priv->refcount, 1);
> - return &mad_snoop_priv->agent;
> -
> -error2:
> - kfree(mad_snoop_priv);
> -error1:
> - return ret;
> -}
> -EXPORT_SYMBOL(ib_register_mad_snoop);
> -
> static inline void deref_mad_agent(struct ib_mad_agent_private
> *mad_agent_priv) {
> if (atomic_dec_and_test(&mad_agent_priv->refcou
[ANNOUNCE] dapl-2.1.7-1 release
New release for uDAPL (2.1.7) is available at http://downloads.openfabrics.org/dapl/ Vlad, please pull into OFED 3.18-1 RC2 md5sum: c25f1c3f99fd7cf9de7c69f664cda492 dapl-2.1.7.tar.gz For v2.1 package install RPM packages as follow: dapl-2.1.7-1 dapl-utils-2.1.7-1 dapl-devel-2.1.7-1 dapl-debuginfo-2.1.7-1 Release notes: http://downloads.openfabrics.org/dapl/documentation/uDAPL_release_notes.txt Summary of changes: Release 2.1.7 dtest: add -a -i options, all data sizes, incremental size dapl: Fix segfault while freeing qp mpxyd: add P2P inline support for data size <= 96 bytes dtest: change rdma_write_ping_pong so client is always last receiver ucm: add DAPL_NETWORK_PROCESS_NUM option for total ranks ucm: fca create group incorrectly using IB addr instead of socket address. ucm: fca_comm_destroy called with NULL dtest: add -W option for rdma write pingpong, similar to ib_write_lat docs: update release notes for collective build mpxyd: reduce log level for rcv message flush dapltest: dapltest with no argument not working in ppc64 arch Release commit: http://git.openfabrics.org/?p=~ardavis/dapl.git;a=commit;h=0494ec10176e07804c26b28484535252e47c3f99 Regards, Arlin -- 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 v1 00/24] New fast registration API
On 9/29/2015 10:03 PM, Bart Van Assche wrote: On 09/17/2015 02:42 AM, Sagi Grimberg wrote: - Converted SRP initiator and RDS iwarp ULPs to the new API Hello Sagi, Hi Bart, How has the converted SRP initiator driver been tested ? With the kernel tree that is available on branch reg_api.4 That's odd. Although I haven't formally submitted reg_api.4 yet, I did test ib_srp initiator against upstream srpt over CX3 (mlx4) and CX4 (mlx5). I ran connect, disconnect, stress IO of all block sizes and some unaligned block-IO and SG_IO test utilities. It all seems to pass for me. Just this morning (my morning) I tested the v2 set on iser, srp, nfs. I placed that in branch reg_api.5. Would you mind running reg_api.5 and see if this issue persist (I would be surprised because I haven't seen any sign of it)? Thanks, Sagi. -- 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 v1 00/24] New fast registration API
On 09/17/2015 02:42 AM, Sagi Grimberg wrote: - Converted SRP initiator and RDS iwarp ULPs to the new API Hello Sagi, How has the converted SRP initiator driver been tested ? With the kernel tree that is available on branch reg_api.4 (427def03e9fa9801efbb27f6c3c6bf7fc0d012e1) I see on the initiator system that login fails and that the following message is logged: Sep 29 12:01:05 ion-dev-ib-ini kernel: scsi host72: ib_srp: failed receive status WR flushed (5) for iu 88045bb80930 Thanks, 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 v1 for-next 0/7] Add support for multicast loopback prevention to mlx4
On 09/21/2015 10:24 AM, eran ben elisha wrote: > On Thu, Aug 20, 2015 at 5:34 PM, Eran Ben Elisha wrote: >> Hi Doug, >> >> This patch-set adds a new implementation for multicast loopback prevention >> for >> mlx4 driver. The current implementation is very limited, especially if link >> layer is Ethernet. The new implementation is based on HW feature of dropping >> incoming multicast packets if the sender QP counter index is equal to the >> receiver counter index. >> >> Patch 0001 extends ib_uverbs_create_qp in order to allow receiving the >> multicast loopback flag at create flags. >> Patch 0002 adds an infrastructure for the counters' loopback prevention in >> the >> mlx4_core. >> Patch 0003 modifies mlx4_en QPs to use the new loopback prevention mode. >> Patches 0004-0006 implements this feature for mlx4_ib driver. >> Patch 0007 allows setting IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK in >> create_flag >> field both from uverbs and ib_create_qp. >> >> Changes from v0: >> Move loopback assignment outside the for loop according to Yuval's comment >> rebase over to-be-rebased/for-4.3 >> >> >> Thanks, >> Eran. >> >> Eran Ben Elisha (5): >> IB/core: Extend ib_uverbs_create_qp >> IB/core: Allow setting create flags in QP init attribute >> IB/mlx4: Add IB counters table >> IB/mlx4: Add counter based implementation for QP multicast loopback >> block >> IB/mlx4: Add support for blocking multicast loopback QP creation user >> flag >> >> Maor Gottlieb (2): >> net/mlx4_core: Add support for filtering multicast loopback >> net/mlx4_en: Implement mcast loopback prevention for ETH qps > > Hi Doug, > This version sits in the mailing list for a month with no comment. > It has been tested by Christoph Lameter. > When do you plan to take it into your tree? I'm getting ready to tackle the for-next backlog. > Eran. > >> >> drivers/infiniband/core/uverbs.h | 1 + >> drivers/infiniband/core/uverbs_cmd.c | 259 >> +++-- >> drivers/infiniband/core/uverbs_main.c | 1 + >> drivers/infiniband/hw/mlx4/mad.c | 25 +- >> drivers/infiniband/hw/mlx4/main.c | 66 -- >> drivers/infiniband/hw/mlx4/mlx4_ib.h | 10 +- >> drivers/infiniband/hw/mlx4/qp.c| 88 ++- >> drivers/net/ethernet/mellanox/mlx4/en_main.c | 22 ++ >> drivers/net/ethernet/mellanox/mlx4/en_resources.c | 25 ++ >> drivers/net/ethernet/mellanox/mlx4/fw.c| 6 + >> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +- >> drivers/net/ethernet/mellanox/mlx4/qp.c| 19 +- >> .../net/ethernet/mellanox/mlx4/resource_tracker.c | 30 ++- >> include/linux/mlx4/device.h| 2 + >> include/linux/mlx4/qp.h| 24 +- >> include/uapi/rdma/ib_user_verbs.h | 26 +++ >> 16 files changed, 498 insertions(+), 109 deletions(-) >> >> -- >> 1.8.3.1 >> >> -- >> 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 > -- > 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 > -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH 04/38] IB/ehca: fix handling idr_alloc result
On 09/21/2015 09:33 AM, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>
> Signed-off-by: Andrzej Hajda
Patch looks fine to me.
Acked-by: Doug Ledford
> ---
> drivers/staging/rdma/ehca/ehca_cq.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rdma/ehca/ehca_cq.c
> b/drivers/staging/rdma/ehca/ehca_cq.c
> index 9b68b17..ea1b5c1 100644
> --- a/drivers/staging/rdma/ehca/ehca_cq.c
> +++ b/drivers/staging/rdma/ehca/ehca_cq.c
> @@ -130,7 +130,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device,
> void *vpage;
> u32 counter;
> u64 rpage, cqx_fec, h_ret;
> - int ipz_rc, i;
> + int rc, i;
> unsigned long flags;
>
> if (attr->flags)
> @@ -170,16 +170,17 @@ struct ib_cq *ehca_create_cq(struct ib_device *device,
>
> idr_preload(GFP_KERNEL);
> write_lock_irqsave(&ehca_cq_idr_lock, flags);
> - my_cq->token = idr_alloc(&ehca_cq_idr, my_cq, 0, 0x200, GFP_NOWAIT);
> + rc = idr_alloc(&ehca_cq_idr, my_cq, 0, 0x200, GFP_NOWAIT);
> write_unlock_irqrestore(&ehca_cq_idr_lock, flags);
> idr_preload_end();
>
> - if (my_cq->token < 0) {
> + if (rc < 0) {
> cq = ERR_PTR(-ENOMEM);
> ehca_err(device, "Can't allocate new idr entry. device=%p",
>device);
> goto create_cq_exit1;
> }
> + my_cq->token = rc;
>
> /*
>* CQs maximum depth is 4GB-64, but we need additional 20 as buffer
> @@ -195,11 +196,11 @@ struct ib_cq *ehca_create_cq(struct ib_device *device,
> goto create_cq_exit2;
> }
>
> - ipz_rc = ipz_queue_ctor(NULL, &my_cq->ipz_queue, param.act_pages,
> + rc = ipz_queue_ctor(NULL, &my_cq->ipz_queue, param.act_pages,
> EHCA_PAGESIZE, sizeof(struct ehca_cqe), 0, 0);
> - if (!ipz_rc) {
> + if (!rc) {
> ehca_err(device, "ipz_queue_ctor() failed ipz_rc=%i device=%p",
> - ipz_rc, device);
> + rc, device);
> cq = ERR_PTR(-EINVAL);
> goto create_cq_exit3;
> }
>
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
[PULL REQUEST] Please pull rdma.git
Hi Linus, I have a few -rc fixes for you. One fix in particular, for the NFSoRDMA code, relied upon changes that went in during the 4.3 merge window to apply cleanly, but also relied on a group of related commits in this set, making it need to come through my tree. So I merged up to 4.3-rc2, and this is what's in my tree beyond that: The following changes since commit 310b7cec8ea32dcd4e9978423717ce78dd89d45d: Merge tag 'v4.3-rc2' into k.o/for-4.3-v1 (2015-09-25 10:46:07 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git tags/for-linus for you to fetch changes up to 2866196f294954ce9fa226825c8c1eaa64c7da8a: IB/ipoib: increase the max mcast backlog queue (2015-09-25 22:30:24 -0400) Changes for 4.3-rc4 - Fixes for mlx5 related issues - Fixes for ipoib multicast handling Christoph Lameter (1): IB/ipoib: Expire sendonly multicast joins Chuck Lever (1): xprtrdma: Replace global lkey with lkey local to PD Doug Ledford (2): IB/ipoib: Make sendonly multicast joins create the mcast group IB/ipoib: increase the max mcast backlog queue Sagi Grimberg (3): IB/iser: Add module parameter for always register memory IB/mlx5: Remove support for IB_DEVICE_LOCAL_DMA_LKEY IB/mlx5: Remove pa_lkey usages drivers/infiniband/hw/mlx5/main.c | 67 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 - drivers/infiniband/hw/mlx5/qp.c| 4 +- drivers/infiniband/ulp/ipoib/ipoib.h | 4 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 18 +++ drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 26 +- drivers/infiniband/ulp/iser/iscsi_iser.c | 5 ++ drivers/infiniband/ulp/iser/iscsi_iser.h | 1 + drivers/infiniband/ulp/iser/iser_memory.c | 18 --- drivers/infiniband/ulp/iser/iser_verbs.c | 21 +--- drivers/net/ethernet/mellanox/mlx5/core/fw.c | 22 - include/linux/mlx5/device.h| 11 - include/linux/mlx5/driver.h| 1 - net/sunrpc/xprtrdma/fmr_ops.c | 19 net/sunrpc/xprtrdma/frwr_ops.c | 5 -- net/sunrpc/xprtrdma/physical_ops.c | 10 +--- net/sunrpc/xprtrdma/verbs.c| 2 +- net/sunrpc/xprtrdma/xprt_rdma.h| 1 - 18 files changed, 70 insertions(+), 167 deletions(-) -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
Re: [PATCH] Expire sendonly joins (was Re: [PATCH rdma-rc 0/2] Add mechanism for ipoib neigh state change notifications)
On 09/28/2015 01:10 PM, Jason Gunthorpe wrote: > On Mon, Sep 28, 2015 at 11:36:11AM -0400, Doug Ledford wrote: > >>> Also broadcast could cause a unecessary reception event on the NICs of >>> machines that have no interest in this traffic. >> >> This is true. However, I'm trying to balance between several competing >> issues. You also stated the revamped multicast code was adding latency >> and dropped packets into the problem space. Sending over the broadcast >> would help with latency. However, I have an alternative idea for that... > > I think your original idea of broadcast immediately and deferred > optimal mlid lookup is the best *functionally* for every case - only > when you enter the very edge world of caring about timing does it make > any difference. > > Christoph's needs would probably be better served by giving some API > to control the mlid cache (ie the neightbour table is already 99% of > the way there). This would let some userspace component pre-load and > fix all relevant data and undesired cache activity simply can't add > jitter. So, I've taken Christoph's patch, added two of my own (just changed the comment and the #if statement so that we create groups on send-only joins, and upped the max send-only backlog queue). We'll leave it at that for 4.3 and try to address it more fully in 4.4. -- Doug Ledford GPG KeyID: 0E572FDD signature.asc Description: OpenPGP digital signature
RE: [PATCH] dapl: Fix segfault while freeing qp
Thanks, applied.
> -Original Message-
> From: Bharat Potnuri [mailto:bha...@chelsio.com]
> Sent: Tuesday, September 29, 2015 5:30 AM
> To: Davis, Arlin R
> Cc: linux-rdma@vger.kernel.org; sw...@opengridcomputing.com;
> nirran...@chelsio.com; Bharat Potnuri
> Subject: [PATCH] dapl: Fix segfault while freeing qp
>
> In function dapls_ib_qp_free(), pointers qp and cm_ptr->cm_id->qp are
> pointing to the same qp structure, initialized in function
> dapls_ib_qp_alloc().
> The memory pointed by these pointers are freed twice in function
> dapls_ib_qp_free(), using rdma_destroy_qp() for the case _OPENIB_CMA
> defined and then further using ibv_destroy_qp(), causing a segmentation fault
> while freeing the qp. Therefore assigned NULL value to qp to avoid freeing
> illegal memory.
>
> Fixes: 7ff4f840bf11 ("common: add CM-EP linking to support mutiple CM's and
> proper protection during destruction")
>
> Signed-off-by: Bharat Potnuri
> ---
> dapl/openib_common/qp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/dapl/openib_common/qp.c b/dapl/openib_common/qp.c index
> 527fc1d4c46b..01f91ca2bd83 100644
> --- a/dapl/openib_common/qp.c
> +++ b/dapl/openib_common/qp.c
> @@ -397,6 +397,7 @@ DAT_RETURN dapls_ib_qp_free(IN DAPL_IA * ia_ptr,
> IN DAPL_EP * ep_ptr) #ifdef _OPENIB_CMA_
> rdma_destroy_qp(cm_ptr->cm_id);
> cm_ptr->cm_id->qp = NULL;
> + qp = NULL;
> #endif
>
> #ifdef _OPENIB_MCM_
> --
> 2.5.3
--
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 2/3] svcrdma: handle rdma read with a non-zero initial page offset
On Mon, Sep 28, 2015 at 04:49:21PM -0500, Steve Wise wrote:
>
>
> > -Original Message-
> > From: J. Bruce Fields [mailto:bfie...@fieldses.org]
> > Sent: Monday, September 28, 2015 4:05 PM
> > To: Steve Wise
> > Cc: trond.mykleb...@primarydata.com; linux-...@vger.kernel.org;
> > linux-rdma@vger.kernel.org
> > Subject: Re: [PATCH 2/3] svcrdma: handle rdma read with a non-zero initial
> > page offset
> >
> > On Mon, Sep 28, 2015 at 09:31:25AM -0500, Steve Wise wrote:
> > > On 9/21/2015 12:24 PM, Steve Wise wrote:
> > > >The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions
> > > >were not taking into account the initial page_offset when determining
> > > >the rdma read length. This resulted in a read who's starting address
> > > >and length exceeded the base/bounds of the frmr.
> > > >
> > > >Most work loads don't tickle this bug apparently, but one test hit it
> > > >every time: building the linux kernel on a 16 core node with 'make -j
> > > >16 O=/mnt/0' where /mnt/0 is a ramdisk mounted via NFSRDMA.
> > > >
> > > >This bug seems to only be tripped with devices having small fastreg page
> > > >list depths. I didn't see it with mlx4, for instance.
> > > >
> > > >Fixes: 0bf4828983df ('svcrdma: refactor marshalling logic')
> > > >Signed-off-by: Steve Wise
> > > >Tested-by: Chuck Lever
> > > >---
> > > >
> > > >
> > >
> > > Hey Bruce, can this make 4.3-rc? Also, what do you think about
> > > pushing it to stable?
> >
> > It looks like a reasonable candidate for stable. Apologies, somehow I
> > missed it when you posted it--would you mind resending?
> >
> > --b.
>
> resent this one patch.
>
> What is your process for pushing to stable?
Currently my standard regression tests don't seem to be passing on
recent 4.3; once I figure that out, I'll push out a branch with your
patch (and any others required) to
git://linux-nfs.org/~bfields for-4.3
and then send a pull request to Linus. Should be by the end of the
week.
--b.
--
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 3.2] IB/qib: Change lkey table allocation to support more MRs
The lkey table is allocated with with a get_user_pages() with an
order based on a number of index bits from a module parameter.
The underlying kernel code cannot allocate that many contiguous pages.
There is no reason the underlying memory needs to be physically
contiguous.
This patch:
- switches the allocation/deallocation to vmalloc/vfree
- caps the number of bits to 23 to insure at least 1 generation bit
o this matches the module parameter description
Cc: sta...@vger.kernel.org # 3.2
Reviewed-by: Vinit Agnihotri
Signed-off-by: Mike Marciniszyn
Signed-off-by: Doug Ledford
---
drivers/infiniband/hw/qib/qib_keys.c |4
drivers/infiniband/hw/qib/qib_verbs.c | 16 +++-
drivers/infiniband/hw/qib/qib_verbs.h |2 ++
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_keys.c
b/drivers/infiniband/hw/qib/qib_keys.c
index 8fd19a4..ca6e6cf 100644
--- a/drivers/infiniband/hw/qib/qib_keys.c
+++ b/drivers/infiniband/hw/qib/qib_keys.c
@@ -69,6 +69,10 @@ int qib_alloc_lkey(struct qib_lkey_table *rkt, struct
qib_mregion *mr)
* unrestricted LKEY.
*/
rkt->gen++;
+ /*
+* bits are capped in qib_verbs.c to insure enough bits
+* for generation number
+*/
mr->lkey = (r << (32 - ib_qib_lkey_table_size)) |
1 << (24 - ib_qib_lkey_table_size)) - 1) & rkt->gen)
<< 8);
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c
b/drivers/infiniband/hw/qib/qib_verbs.c
index a894762..95df4cd 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "qib.h"
#include "qib_common.h"
@@ -2035,10 +2036,16 @@ int qib_register_ib_device(struct qib_devdata *dd)
* the LKEY). The remaining bits act as a generation number or tag.
*/
spin_lock_init(&dev->lk_table.lock);
+ /* insure generation is at least 4 bits see keys.c */
+ if (ib_qib_lkey_table_size > MAX_LKEY_TABLE_BITS) {
+ qib_dev_warn(dd, "lkey bits %u too large, reduced to %u\n",
+ ib_qib_lkey_table_size, MAX_LKEY_TABLE_BITS);
+ ib_qib_lkey_table_size = MAX_LKEY_TABLE_BITS;
+ }
dev->lk_table.max = 1 << ib_qib_lkey_table_size;
lk_tab_size = dev->lk_table.max * sizeof(*dev->lk_table.table);
- dev->lk_table.table = (struct qib_mregion **)
- __get_free_pages(GFP_KERNEL, get_order(lk_tab_size));
+ dev->lk_table.table = (struct qib_mregion __rcu **)
+ vmalloc(lk_tab_size);
if (dev->lk_table.table == NULL) {
ret = -ENOMEM;
goto err_lk;
@@ -2208,7 +2215,7 @@ err_tx:
sizeof(struct qib_pio_header),
dev->pio_hdrs, dev->pio_hdrs_phys);
err_hdrs:
- free_pages((unsigned long) dev->lk_table.table, get_order(lk_tab_size));
+ vfree(dev->lk_table.table);
err_lk:
kfree(dev->qp_table);
err_qpt:
@@ -2262,7 +2269,6 @@ void qib_unregister_ib_device(struct qib_devdata *dd)
sizeof(struct qib_pio_header),
dev->pio_hdrs, dev->pio_hdrs_phys);
lk_tab_size = dev->lk_table.max * sizeof(*dev->lk_table.table);
- free_pages((unsigned long) dev->lk_table.table,
- get_order(lk_tab_size));
+ vfree(dev->lk_table.table);
kfree(dev->qp_table);
}
diff --git a/drivers/infiniband/hw/qib/qib_verbs.h
b/drivers/infiniband/hw/qib/qib_verbs.h
index 0c19ef0..66f7f62 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.h
+++ b/drivers/infiniband/hw/qib/qib_verbs.h
@@ -622,6 +622,8 @@ struct qib_qpn_table {
struct qpn_map map[QPNMAP_ENTRIES];
};
+#define MAX_LKEY_TABLE_BITS 23
+
struct qib_lkey_table {
spinlock_t lock; /* protect changes in this struct */
u32 next; /* next unused index (speeds search) */
--
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 3.4] IB/qib: Change lkey table allocation to support more MRs
The lkey table is allocated with with a get_user_pages() with an
order based on a number of index bits from a module parameter.
The underlying kernel code cannot allocate that many contiguous pages.
There is no reason the underlying memory needs to be physically
contiguous.
This patch:
- switches the allocation/deallocation to vmalloc/vfree
- caps the number of bits to 23 to insure at least 1 generation bit
o this matches the module parameter description
Cc: sta...@vger.kernel.org # 3.4
Reviewed-by: Vinit Agnihotri
Signed-off-by: Mike Marciniszyn
Signed-off-by: Doug Ledford
---
drivers/infiniband/hw/qib/qib_keys.c |4
drivers/infiniband/hw/qib/qib_verbs.c | 16 +++-
drivers/infiniband/hw/qib/qib_verbs.h |2 ++
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_keys.c
b/drivers/infiniband/hw/qib/qib_keys.c
index 8fd19a4..ca6e6cf 100644
--- a/drivers/infiniband/hw/qib/qib_keys.c
+++ b/drivers/infiniband/hw/qib/qib_keys.c
@@ -69,6 +69,10 @@ int qib_alloc_lkey(struct qib_lkey_table *rkt, struct
qib_mregion *mr)
* unrestricted LKEY.
*/
rkt->gen++;
+ /*
+* bits are capped in qib_verbs.c to insure enough bits
+* for generation number
+*/
mr->lkey = (r << (32 - ib_qib_lkey_table_size)) |
1 << (24 - ib_qib_lkey_table_size)) - 1) & rkt->gen)
<< 8);
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c
b/drivers/infiniband/hw/qib/qib_verbs.c
index 7b6c3bf..3840137 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "qib.h"
#include "qib_common.h"
@@ -2058,10 +2059,16 @@ int qib_register_ib_device(struct qib_devdata *dd)
* the LKEY). The remaining bits act as a generation number or tag.
*/
spin_lock_init(&dev->lk_table.lock);
+ /* insure generation is at least 4 bits see keys.c */
+ if (ib_qib_lkey_table_size > MAX_LKEY_TABLE_BITS) {
+ qib_dev_warn(dd, "lkey bits %u too large, reduced to %u\n",
+ ib_qib_lkey_table_size, MAX_LKEY_TABLE_BITS);
+ ib_qib_lkey_table_size = MAX_LKEY_TABLE_BITS;
+ }
dev->lk_table.max = 1 << ib_qib_lkey_table_size;
lk_tab_size = dev->lk_table.max * sizeof(*dev->lk_table.table);
- dev->lk_table.table = (struct qib_mregion **)
- __get_free_pages(GFP_KERNEL, get_order(lk_tab_size));
+ dev->lk_table.table = (struct qib_mregion __rcu **)
+ vmalloc(lk_tab_size);
if (dev->lk_table.table == NULL) {
ret = -ENOMEM;
goto err_lk;
@@ -2231,7 +2238,7 @@ err_tx:
sizeof(struct qib_pio_header),
dev->pio_hdrs, dev->pio_hdrs_phys);
err_hdrs:
- free_pages((unsigned long) dev->lk_table.table, get_order(lk_tab_size));
+ vfree(dev->lk_table.table);
err_lk:
kfree(dev->qp_table);
err_qpt:
@@ -2285,7 +2292,6 @@ void qib_unregister_ib_device(struct qib_devdata *dd)
sizeof(struct qib_pio_header),
dev->pio_hdrs, dev->pio_hdrs_phys);
lk_tab_size = dev->lk_table.max * sizeof(*dev->lk_table.table);
- free_pages((unsigned long) dev->lk_table.table,
- get_order(lk_tab_size));
+ vfree(dev->lk_table.table);
kfree(dev->qp_table);
}
diff --git a/drivers/infiniband/hw/qib/qib_verbs.h
b/drivers/infiniband/hw/qib/qib_verbs.h
index 0c19ef0..66f7f62 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.h
+++ b/drivers/infiniband/hw/qib/qib_verbs.h
@@ -622,6 +622,8 @@ struct qib_qpn_table {
struct qpn_map map[QPNMAP_ENTRIES];
};
+#define MAX_LKEY_TABLE_BITS 23
+
struct qib_lkey_table {
spinlock_t lock; /* protect changes in this struct */
u32 next; /* next unused index (speeds search) */
--
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 3.10] IB/qib: Change lkey table allocation to support more MRs
Ported from commit d6f1c17e162b2a11e708f28fa93f2f79c164b442 upstream.
The lkey table is allocated with with a get_user_pages() with an
order based on a number of index bits from a module parameter.
The underlying kernel code cannot allocate that many contiguous pages.
There is no reason the underlying memory needs to be physically
contiguous.
This patch:
- switches the allocation/deallocation to vmalloc/vfree
- caps the number of bits to 23 to insure at least 1 generation bit
o this matches the module parameter description
Cc: sta...@vger.kernel.org # 3.10
Reviewed-by: Vinit Agnihotri
Signed-off-by: Mike Marciniszyn
Signed-off-by: Doug Ledford
---
drivers/infiniband/hw/qib/qib.h | 27 +++
drivers/infiniband/hw/qib/qib_keys.c |4
drivers/infiniband/hw/qib/qib_verbs.c | 14 ++
drivers/infiniband/hw/qib/qib_verbs.h |2 ++
4 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib.h b/drivers/infiniband/hw/qib/qib.h
index d1b30c6..86c686a 100644
--- a/drivers/infiniband/hw/qib/qib.h
+++ b/drivers/infiniband/hw/qib/qib.h
@@ -1467,27 +1467,22 @@ extern struct mutex qib_mutex;
* first to avoid possible serial port delays from printk.
*/
#define qib_early_err(dev, fmt, ...) \
- do { \
- dev_err(dev, fmt, ##__VA_ARGS__); \
- } while (0)
+ dev_err(dev, fmt, ##__VA_ARGS__)
#define qib_dev_err(dd, fmt, ...) \
- do { \
- dev_err(&(dd)->pcidev->dev, "%s: " fmt, \
- qib_get_unit_name((dd)->unit), ##__VA_ARGS__); \
- } while (0)
+ dev_err(&(dd)->pcidev->dev, "%s: " fmt, \
+ qib_get_unit_name((dd)->unit), ##__VA_ARGS__)
-#define qib_dev_porterr(dd, port, fmt, ...) \
- do { \
- dev_err(&(dd)->pcidev->dev, "%s: IB%u:%u " fmt, \
- qib_get_unit_name((dd)->unit), (dd)->unit, (port), \
- ##__VA_ARGS__); \
- } while (0)
+#define qib_dev_warn(dd, fmt, ...) \
+ dev_warn(&(dd)->pcidev->dev, "%s: " fmt, \
+ qib_get_unit_name((dd)->unit), ##__VA_ARGS__)
+#define qib_dev_porterr(dd, port, fmt, ...) \
+ dev_err(&(dd)->pcidev->dev, "%s: IB%u:%u " fmt, \
+ qib_get_unit_name((dd)->unit), (dd)->unit, (port), \
+ ##__VA_ARGS__)
#define qib_devinfo(pcidev, fmt, ...) \
- do { \
- dev_info(&(pcidev)->dev, fmt, ##__VA_ARGS__); \
- } while (0)
+ dev_info(&(pcidev)->dev, fmt, ##__VA_ARGS__)
/*
* this is used for formatting hw error messages...
diff --git a/drivers/infiniband/hw/qib/qib_keys.c
b/drivers/infiniband/hw/qib/qib_keys.c
index 3b9afcc..eabe547 100644
--- a/drivers/infiniband/hw/qib/qib_keys.c
+++ b/drivers/infiniband/hw/qib/qib_keys.c
@@ -86,6 +86,10 @@ int qib_alloc_lkey(struct qib_mregion *mr, int dma_region)
* unrestricted LKEY.
*/
rkt->gen++;
+ /*
+* bits are capped in qib_verbs.c to insure enough bits
+* for generation number
+*/
mr->lkey = (r << (32 - ib_qib_lkey_table_size)) |
1 << (24 - ib_qib_lkey_table_size)) - 1) & rkt->gen)
<< 8);
diff --git a/drivers/infiniband/hw/qib/qib_verbs.c
b/drivers/infiniband/hw/qib/qib_verbs.c
index 904c384..6c809bf 100644
--- a/drivers/infiniband/hw/qib/qib_verbs.c
+++ b/drivers/infiniband/hw/qib/qib_verbs.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "qib.h"
#include "qib_common.h"
@@ -2084,10 +2085,16 @@ int qib_register_ib_device(struct qib_devdata *dd)
* the LKEY). The remaining bits act as a generation number or tag.
*/
spin_lock_init(&dev->lk_table.lock);
+ /* insure generation is at least 4 bits see keys.c */
+ if (ib_qib_lkey_table_size > MAX_LKEY_TABLE_BITS) {
+ qib_dev_warn(dd, "lkey bits %u too large, reduced to %u\n",
+ ib_qib_lkey_table_size, MAX_LKEY_TABLE_BITS);
+ ib_qib_lkey_table_size = MAX_LKEY_TABLE_BITS;
+ }
dev->lk_table.max = 1 << ib_qib_lkey_table_size;
lk_tab_size = dev->lk_table.max * sizeof(*dev->lk_table.table);
dev->lk_table.table = (struct qib_mregion __rcu **)
- __get_free_pages(GFP_KERNEL, get_order(lk_tab_size));
+ vmalloc(lk_tab_size);
if (dev->lk_table.table == NULL) {
ret = -ENOMEM;
goto err_lk;
@@ -2260,7 +2267,7 @@ err_tx:
sizeof(struct qib_pio_header),
dev->pio_hdrs, dev->pio_hdrs_phys);
err_hdrs:
- free_pages((unsigned long) dev->lk_table.table, get_order(lk_tab_size));
+ vfree(dev->lk_table.table);
err_lk:
kfree(dev->qp_table);
err_qpt:
@@ -2314,8 +2321,7 @@ void qib_unregister_ib_device(struct qib_devdata *dd)
sizeof(struct qib_pio_he
Create a common verbs transport library
Hi All, One of the conditions to move the hfi1 driver from staging into the normal drivers/infiniband/hw directory is to handle the code duplication in our verbs layer. This is going to be done by creating a new kmod which we will call rdmavt, for RDMA verbs transport. This will eventually live in the existing drivers/infiniband tree in a new sw directory: drivers/infiniband/sw/vt. This new directory can serve as a home for soft roce when its ready as well. The verbs library will start out life in drivers/staging/rdma/vt alongside hfi1. We (Intel) will push incremental patches to keep the community apprised of the development and allow for early and more continuous feedback. Once complete the plan would be to move out of staging along with hfi1. The current verbs support in the IB core should not need to be modified, rdmavt is just another verbs provider. Drivers will not use rdmavt directly. Rather, rdmavt will use the drivers to abstract away the hardware differences. Here is a diagram of what this will look like. +---+ |Ib Core| +---+ + | +--v+ |Verbs Transport| +-+--+--+ | | | | +-v--+ +-v--+ |qib | |hfi1| ++ ++ -Denny -- 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] dapl: Fix segfault while freeing qp
In function dapls_ib_qp_free(), pointers qp and cm_ptr->cm_id->qp are
pointing to the same qp structure, initialized in function
dapls_ib_qp_alloc(). The memory pointed by these pointers are freed
twice in function dapls_ib_qp_free(), using rdma_destroy_qp() for the
case _OPENIB_CMA defined and then further using ibv_destroy_qp(),
causing a segmentation fault while freeing the qp. Therefore assigned
NULL value to qp to avoid freeing illegal memory.
Fixes: 7ff4f840bf11 ("common: add CM-EP linking to support mutiple CM's
and proper protection during destruction")
Signed-off-by: Bharat Potnuri
---
dapl/openib_common/qp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dapl/openib_common/qp.c b/dapl/openib_common/qp.c
index 527fc1d4c46b..01f91ca2bd83 100644
--- a/dapl/openib_common/qp.c
+++ b/dapl/openib_common/qp.c
@@ -397,6 +397,7 @@ DAT_RETURN dapls_ib_qp_free(IN DAPL_IA * ia_ptr, IN DAPL_EP
* ep_ptr)
#ifdef _OPENIB_CMA_
rdma_destroy_qp(cm_ptr->cm_id);
cm_ptr->cm_id->qp = NULL;
+ qp = NULL;
#endif
#ifdef _OPENIB_MCM_
--
2.5.3
--
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: shrink struct ib_send_wr V4
On 13/09/2015 18:13, Christoph Hellwig wrote: > This series shrinks the WR size by splitting out the different WR > types. > > Patch number one is too large for the mailinglist, so if you didn't > get it grab it here: > > > http://git.infradead.org/users/hch/rdma.git/commitdiff_plain/c752d80937ff2d71f25ae7fcdd1a151054fb2ceb > > or the full git tree at: > > git://git.infradead.org/users/hch/rdma.git wr-cleanup > Hi, I've tested the current wr-cleanup branch with a Connect-IB device to make sure the changes to the mlx5-internal UMR work requests are fine (at least when invoked from user space). To test I also had to add Sagi's patches to remove the reserved lkey, but with those patches it works. Regards, Haggai -- 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 v1 01/24] IB/core: Introduce new fast registration API
Shouldn't higher layers take care of this? Trying to implement the same coalescing algorithm at various layers isn't very optimal, although we need to decide and document which one is responsible. The block layer can take care of it, but I'm not sure about NFS/RDS at the moment (IIRC Steve specifically asked if this API would take care of chunking contig sg elements) so I'd rather keep it in until we are absolutely sure we don't need it. I can add a documentation statement for it. -- 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
