2016-01-22 21:00:15 +00:00
|
|
|
#ifndef DEF_RDMAVT_INCCQ_H
|
|
|
|
#define DEF_RDMAVT_INCCQ_H
|
|
|
|
|
|
|
|
/*
|
|
|
|
*
|
|
|
|
* This file is provided under a dual BSD/GPLv2 license. When using or
|
|
|
|
* redistributing this file, you may do so under either license.
|
|
|
|
*
|
|
|
|
* GPL LICENSE SUMMARY
|
|
|
|
*
|
IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support
Currently the driver doesn't support completion vectors. These
are used to indicate which sets of CQs should be grouped together
into the same vector. A vector is a CQ processing thread that
runs on a specific CPU.
If an application has several CQs bound to different completion
vectors, and each completion vector runs on different CPUs, then
the completion queue workload is balanced. This helps scale as more
nodes are used.
Implement CQ completion vector support using a global workqueue
where a CQ entry is queued to the CPU corresponding to the CQ's
completion vector. Since the workqueue is global, it's guaranteed
to always be there when queueing CQ entries; Therefore, the RCU
locking for cq->rdi->worker in the hot path is superfluous.
Each completion vector is assigned to a different CPU. The number of
completion vectors available is computed by taking the number of
online, physical CPUs from the local NUMA node and subtracting the
CPUs used for kernel receive queues and the general interrupt.
Special use cases:
* If there are no CPUs left for completion vectors, the same CPU
for the general interrupt is used; Therefore, there would only
be one completion vector available.
* For multi-HFI systems, the number of completion vectors available
for each device is the total number of completion vectors in
the local NUMA node divided by the number of devices in the same
NUMA node. If there's a division remainder, the first device to
get initialized gets an extra completion vector.
Upon a CQ creation, an invalid completion vector could be specified.
Handle it as follows:
* If the completion vector is less than 0, set it to 0.
* Set the completion vector to the result of the passed completion
vector moded with the number of device completion vectors
available.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Sebastian Sanchez <sebastian.sanchez@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-05-02 13:43:55 +00:00
|
|
|
* Copyright(c) 2016 - 2018 Intel Corporation.
|
2016-01-22 21:00:15 +00:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of version 2 of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* BSD LICENSE
|
|
|
|
*
|
|
|
|
* Copyright(c) 2015 Intel Corporation.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* - Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* - Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
* - Neither the name of Intel Corporation nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
* from this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kthread.h>
|
|
|
|
#include <rdma/ib_user_verbs.h>
|
2019-07-22 17:01:30 +00:00
|
|
|
#include <rdma/ib_verbs.h>
|
2016-01-22 21:00:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Define an ib_cq_notify value that is not valid so we know when CQ
|
|
|
|
* notifications are armed.
|
|
|
|
*/
|
|
|
|
#define RVT_CQ_NONE (IB_CQ_NEXT_COMP + 1)
|
|
|
|
|
2019-06-28 18:04:17 +00:00
|
|
|
/*
|
|
|
|
* Define read macro that apply smp_load_acquire memory barrier
|
|
|
|
* when reading indice of circular buffer that mmaped to user space.
|
|
|
|
*/
|
|
|
|
#define RDMA_READ_UAPI_ATOMIC(member) smp_load_acquire(&(member).val)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Define write macro that uses smp_store_release memory barrier
|
|
|
|
* when writing indice of circular buffer that mmaped to user space.
|
|
|
|
*/
|
|
|
|
#define RDMA_WRITE_UAPI_ATOMIC(member, x) smp_store_release(&(member).val, x)
|
|
|
|
#include <rdma/rvt-abi.h>
|
|
|
|
|
2016-01-22 21:00:15 +00:00
|
|
|
/*
|
|
|
|
* This structure is used to contain the head pointer, tail pointer,
|
|
|
|
* and completion queue entries as a single memory allocation so
|
|
|
|
* it can be mmap'ed into user space.
|
|
|
|
*/
|
2019-06-28 18:04:17 +00:00
|
|
|
struct rvt_k_cq_wc {
|
2016-01-22 21:00:15 +00:00
|
|
|
u32 head; /* index of next entry to fill */
|
|
|
|
u32 tail; /* index of next ib_poll_cq() entry */
|
2019-06-28 18:04:17 +00:00
|
|
|
struct ib_wc kqueue[];
|
2016-01-22 21:00:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The completion queue structure.
|
|
|
|
*/
|
|
|
|
struct rvt_cq {
|
|
|
|
struct ib_cq ibcq;
|
IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support
Currently the driver doesn't support completion vectors. These
are used to indicate which sets of CQs should be grouped together
into the same vector. A vector is a CQ processing thread that
runs on a specific CPU.
If an application has several CQs bound to different completion
vectors, and each completion vector runs on different CPUs, then
the completion queue workload is balanced. This helps scale as more
nodes are used.
Implement CQ completion vector support using a global workqueue
where a CQ entry is queued to the CPU corresponding to the CQ's
completion vector. Since the workqueue is global, it's guaranteed
to always be there when queueing CQ entries; Therefore, the RCU
locking for cq->rdi->worker in the hot path is superfluous.
Each completion vector is assigned to a different CPU. The number of
completion vectors available is computed by taking the number of
online, physical CPUs from the local NUMA node and subtracting the
CPUs used for kernel receive queues and the general interrupt.
Special use cases:
* If there are no CPUs left for completion vectors, the same CPU
for the general interrupt is used; Therefore, there would only
be one completion vector available.
* For multi-HFI systems, the number of completion vectors available
for each device is the total number of completion vectors in
the local NUMA node divided by the number of devices in the same
NUMA node. If there's a division remainder, the first device to
get initialized gets an extra completion vector.
Upon a CQ creation, an invalid completion vector could be specified.
Handle it as follows:
* If the completion vector is less than 0, set it to 0.
* Set the completion vector to the result of the passed completion
vector moded with the number of device completion vectors
available.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Sebastian Sanchez <sebastian.sanchez@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-05-02 13:43:55 +00:00
|
|
|
struct work_struct comptask;
|
2016-01-22 21:00:15 +00:00
|
|
|
spinlock_t lock; /* protect changes in this struct */
|
|
|
|
u8 notify;
|
|
|
|
u8 triggered;
|
2019-06-28 18:21:52 +00:00
|
|
|
u8 cq_full;
|
IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support
Currently the driver doesn't support completion vectors. These
are used to indicate which sets of CQs should be grouped together
into the same vector. A vector is a CQ processing thread that
runs on a specific CPU.
If an application has several CQs bound to different completion
vectors, and each completion vector runs on different CPUs, then
the completion queue workload is balanced. This helps scale as more
nodes are used.
Implement CQ completion vector support using a global workqueue
where a CQ entry is queued to the CPU corresponding to the CQ's
completion vector. Since the workqueue is global, it's guaranteed
to always be there when queueing CQ entries; Therefore, the RCU
locking for cq->rdi->worker in the hot path is superfluous.
Each completion vector is assigned to a different CPU. The number of
completion vectors available is computed by taking the number of
online, physical CPUs from the local NUMA node and subtracting the
CPUs used for kernel receive queues and the general interrupt.
Special use cases:
* If there are no CPUs left for completion vectors, the same CPU
for the general interrupt is used; Therefore, there would only
be one completion vector available.
* For multi-HFI systems, the number of completion vectors available
for each device is the total number of completion vectors in
the local NUMA node divided by the number of devices in the same
NUMA node. If there's a division remainder, the first device to
get initialized gets an extra completion vector.
Upon a CQ creation, an invalid completion vector could be specified.
Handle it as follows:
* If the completion vector is less than 0, set it to 0.
* Set the completion vector to the result of the passed completion
vector moded with the number of device completion vectors
available.
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Sebastian Sanchez <sebastian.sanchez@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2018-05-02 13:43:55 +00:00
|
|
|
int comp_vector_cpu;
|
2016-01-22 21:00:15 +00:00
|
|
|
struct rvt_dev_info *rdi;
|
|
|
|
struct rvt_cq_wc *queue;
|
|
|
|
struct rvt_mmap_info *ip;
|
2019-06-28 18:04:17 +00:00
|
|
|
struct rvt_k_cq_wc *kqueue;
|
2016-01-22 21:00:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct rvt_cq *ibcq_to_rvtcq(struct ib_cq *ibcq)
|
|
|
|
{
|
|
|
|
return container_of(ibcq, struct rvt_cq, ibcq);
|
|
|
|
}
|
|
|
|
|
2019-06-28 18:21:52 +00:00
|
|
|
bool rvt_cq_enter(struct rvt_cq *cq, struct ib_wc *entry, bool solicited);
|
2016-01-22 21:00:15 +00:00
|
|
|
|
|
|
|
#endif /* DEF_RDMAVT_INCCQH */
|