- 04 Jun, 2018 1 commit
-
-
Jason Gunthorpe authored
Merge tag 'verbs_flow_counters' of git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git into for-next Pull verbs counters series from Leon Romanovsky: ==================== Verbs flow counters support This series comes to allow user space applications to monitor real time traffic activity and events of the verbs objects it manages, e.g.: ibv_qp, ibv_wq, ibv_flow. The API enables generic counters creation and define mapping to association with a verbs object, the current mlx5 driver is using this API for flow counters. With this API, an application can monitor the entire life cycle of object activity, defined here as a static counters attachment. This API also allows dynamic counters monitoring of measurement points for a partial period in the verbs object life cycle. In addition it presents the implementation of the generic counters interface. This will be achieved by extending flow creation by adding a new flow count specification type which allows the user to associate a previously created flow counters using the generic verbs counters interface to the created flow, once associated the user could read statistics by using the read function of the generic counters interface. The API includes: 1. create and destroyed API of a new counters objects 2. read the counters values from HW Note: Attaching API to allow application to define the measurement points per objects is a user space only API and this data is passed to kernel when the counted object (e.g. flow) is created with the counters object. =================== * tag 'verbs_flow_counters': IB/mlx5: Add counters read support IB/mlx5: Add flow counters read support IB/mlx5: Add flow counters binding support IB/mlx5: Add counters create and destroy support IB/uverbs: Add support for flow counters IB/core: Add support for flow counters IB/core: Support passing uhw for create_flow IB/uverbs: Add read counters support IB/core: Introduce counters read verb IB/uverbs: Add create/destroy counters support IB/core: Introduce counters object and its create/destroy IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure net/mlx5: Export flow counter related API net/mlx5: Use flow counter pointer as input to the query function
-
- 02 Jun, 2018 14 commits
-
-
Raed Salem authored
This patch implements the uverbs counters read API, it will use the specific read counters function to the given type to accomplish its task. Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Raed Salem <raeds@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
Raed Salem authored
Implements the flow counters read wrapper. Reviewed-by:
-
Raed Salem authored
Associates a counters with a flow when IB_FLOW_SPEC_ACTION_COUNT is part of the flow specifications. The counters user space placements of location and description (index, description) pairs are passed as private data of the counters flow specification. Reviewed-by:
-
Raed Salem authored
This patch implements the device counters create and destroy APIs and introducing some internal management structures. Downstream patches in this series will add the functionality to support flow counters binding and reading. Reviewed-by:
-
Raed Salem authored
The struct ib_uverbs_flow_spec_action_count associates a counters object with the flow. Post this association the flow counters can be read via the counters object. Reviewed-by:
-
Raed Salem authored
A counters object could be attached to flow on creation by providing the counter specification action. General counters description which count packets and bytes are introduced, downstream patches from this series will use them as part of flow counters binding. In addition, increase number of flow specifications supported layers to 10 upon adding count specification and for the previously added drop specification. Reviewed-by:
-
Matan Barak authored
This is required when user-space drivers need to pass extra information regarding how to handle this flow steering specification. Reviewed-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Signed-off-by:
-
Raed Salem authored
This patch exposes the read counters verb to user space applications. By that verb the user can read the hardware counters which are associated with the counters object. The application needs to provide a sufficient memory to hold the statistics. Reviewed-by:
-
Raed Salem authored
The user supplies counters instance and a reference to an output array of uint64_t. The driver reads the hardware counters values and writes them to the output index location in the user supplied array. All counters values are represented as uint64_t types. To be able to successfully read the data the counters must be first bound to an IB object. Downstream patches will present binding method for flow counters. Reviewed-by:
-
Raed Salem authored
User space application which uses counters functionality, is expected to allocate/release the counters resources by calling create/destroy verbs and in turn get a unique handle that can be used to attach the counters to its counted type. Reviewed-by:
-
Raed Salem authored
A verbs application may need to get statistics and info on various aspects of a verb object (e.g. Flow, QP, ...), in general case the application will state which object's counters its interested in (we refer to this action as attach), bind this new counters object to the appropriate verb object and on later stage read their values using the counters object. This series introduces a general API for counters object that may accumulate any ib object counters type, bound and read on demand. Counters instance is allocated on an IB context and belongs to that context. Upon successful creation the counters can be bound to a verbs object so that hardware counter instances can be created and read. Downstream patches in this series will introduce the attach, bind and the read functionality. Counters instance can be de-allocated, upon successful destruction the related hardware resources are released. Prior to destroy call the user must first make sure that the counters is not being used by any IB object, e.g. not attached to any of its counted type otherwise an EBUSY error is invoked. Reviewed-by:
-
Matan Barak authored
Previously, the user had to dig inside the attribute to get the uobject. Add a helper function that correctly extract it (and do the required checks) for him/her. Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
-
Raed Salem authored
Exports counters API to be used in both IB and EN. Reviewed-by:
-
Or Gerlitz authored
This allows to un-expose the details of struct mlx5_fc and keep it internal to the core driver. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
- 01 Jun, 2018 11 commits
-
-
Leon Romanovsky authored
All callers of zap_vma_ptes() are not interested in the return value of that function, so let's simplify its interface and drop the return value. Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Doug Ledford authored
There is no need to check return value of zap_vma_ptes() because there is nothing to do with this knowledge. Signed-off-by: -
Leon Romanovsky authored
The failure reported by zap_vma_ptes() means that wrong VMA pages were supplied, however it is impossible for this type of address. Signed-off-by:
-
Leon Romanovsky authored
There is no need to check return value of zap_vma_ptes() because there is nothing to do with this knowledge. Signed-off-by:
-
Leon Romanovsky authored
Let's perform checks in-place instead of BUG_ONs. Signed-off-by:
-
Leon Romanovsky authored
There is no need to check existence of mad_queue, because we already did pointer dereference before call to dequeue_mad(). Signed-off-by:
-
Leon Romanovsky authored
There is no need to bring down the whole machine, just because unknown event was received. It is better to ignore it silently. Signed-off-by:
-
Leon Romanovsky authored
In case CM work list is empty, the work pointer will be NULL, so instead of kernel crash it is better to abort processing of works. Signed-off-by:
-
Leon Romanovsky authored
cxgb3 driver properly handles errors returned by IDR, so there is no need to have special case (kernel crash) just because IDR is full. Signed-off-by:
-
Leon Romanovsky authored
There is no need to crash the machine if unknown work request was received in SQP MAD. Cc: <stable@vger.kernel.org> # 3.6 Fixes: 37bfc7c1 ("IB/mlx4: SR-IOV multiplex and demultiplex MADs") Signed-off-by:
-
Leon Romanovsky authored
Any steering QP is supposed be above steering_qp_base, see function mlx4_ib_steer_qp_alloc() for it, however in case of misalignment between SW and FW, this qp_base can be wrong. Use WARN() to catch such situation without killing the machine. Signed-off-by:
-
- 31 May, 2018 7 commits
-
-
Colin Ian King authored
Trivial fix to spelling mistake in DP_ERR error message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Sergey Gorenko authored
The iSER driver reduces max_sectors. For example, if you load the ib_iser module with max_sectors=1024, you will see that /sys/class/block/<bdev>/queue/max_hw_sectors_kb is 508. It is an incorrect value. The expected value is (max_sectors * sector_size) / 1024 = 512. Reducing of max_sectors can cause performance degradation due to unnecessary splitting of IO requests. The number of pages per MR has been fixed here, so there is no longer any need to reduce max_sectors. Fixes: 9c674815 ("IB/iser: Fix max_sectors calculation") Signed-off-by:
Sergey Gorenko <sergeygo@mellanox.com> Reviewed-by:
Israel Rukshin <israelr@mellanox.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Acked-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Doug Ledford authored
Signed-off-by: -
Wei Hu(Xavier) authored
This patch implemented the IB core disassociate_ucontext API. Signed-off-by:
Wei Hu (Xavier) <xavier.huwei@huawei.com> Signed-off-by:
-
Wei Hu(Xavier) authored
This patch hoisted the common process of disassociate_ucontext callback function into ib core code, and these code are common to ervery ib_device driver. Signed-off-by:
-
Wei Hu(Xavier) authored
This patch fixed the potential illegal operation when using the extend sge buffer cross page in post send operation. The bug will cause the calltrace as below. [ 3302.922107] Unable to handle kernel paging request at virtual address ffff00003b3a0004 [ 3302.930009] Mem abort info: [ 3302.932790] Exception class = DABT (current EL), IL = 32 bits [ 3302.938695] SET = 0, FnV = 0 [ 3302.941735] EA = 0, S1PTW = 0 [ 3302.944863] Data abort info: [ 3302.947729] ISV = 0, ISS = 0x00000047 [ 3302.951551] CM = 0, WnR = 1 [ 3302.954506] swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff000009ea5000 [ 3302.961279] [ffff00003b3a0004] *pgd=00000023dfffe003, *pud=00000023dfffd003, *pmd=00000022dc84c003, *pte=0000000000000000 [ 3302.972224] Internal error: Oops: 96000047 [#1] SMP [ 3302.999509] CPU: 9 PID: 19628 Comm: roce_test_main Tainted: G OE 4.14.10 #1 [ 3303.007498] task: ffff80234df78000 task.stack: ffff00000f640000 [ 3303.013412] PC is at hns_roce_v2_post_send+0x690/0xe20 [hns_roce_pci] [ 3303.019843] LR is at hns_roce_v2_post_send+0x658/0xe20 [hns_roce_pci] [ 3303.026269] pc : [<ffff0000020694f8>] lr : [<ffff0000020694c0>] pstate: 804001c9 [ 3303.033649] sp : ffff00000f643870 [ 3303.036951] x29: ffff00000f643870 x28: ffff80232bfa9c00 [ 3303.042250] x27: ffff80234d909380 x26: ffff00003b37f0c0 [ 3303.047549] x25: 0000000000000000 x24: 0000000000000003 [ 3303.052848] x23: 0000000000000000 x22: 0000000000000000 [ 3303.058148] x21: 0000000000000101 x20: 0000000000000001 [ 3303.063447] x19: ffff80236163f800 x18: 0000000000000000 [ 3303.068746] x17: 0000ffff86b76fc8 x16: ffff000008301600 [ 3303.074045] x15: 000020a51c000000 x14: 3128726464615f65 [ 3303.079344] x13: 746f6d6572202c29 x12: 303035312879656b [ 3303.084643] x11: 723a6f666e692072 x10: 573a6f666e693a5d [ 3303.089943] x9 : 0000000000000004 x8 : ffff8023ce38b000 [ 3303.095242] x7 : ffff8023ce38b320 x6 : 0000000000000418 [ 3303.100541] x5 : ffff80232bfa9cc8 x4 : 0000000000000030 [ 3303.105839] x3 : 0000000000000100 x2 : 0000000000000200 [ 3303.111138] x1 : 0000000000000320 x0 : ffff00003b3a0000 [ 3303.116438] Process roce_test_main (pid: 19628, stack limit = 0xffff00000f640000) [ 3303.123906] Call trace: [ 3303.126339] Exception stack(0xffff00000f643730 to 0xffff00000f643870) [ 3303.215790] [<ffff0000020694f8>] hns_roce_v2_post_send+0x690/0xe20 [hns_roce_pci] [ 3303.223293] [<ffff0000021c3750>] rt_ktest_post_send+0x5d0/0x8b8 [rdma_test] [ 3303.230261] [<ffff0000021b3234>] exec_send_cmd+0x664/0x1350 [rdma_test] [ 3303.236881] [<ffff0000021b8b30>] rt_ktest_dispatch_cmd_3+0x1510/0x3790 [rdma_test] [ 3303.244455] [<ffff0000021bae54>] rt_ktest_dispatch_cmd_2+0xa4/0x118 [rdma_test] [ 3303.251770] [<ffff0000021bafec>] rt_ktest_dispatch_cmd+0x124/0xaa8 [rdma_test] [ 3303.258997] [<ffff0000021bbc3c>] rt_ktest_dev_write+0x2cc/0x568 [rdma_test] [ 3303.265947] [<ffff0000082ad688>] __vfs_write+0x60/0x18c [ 3303.271158] [<ffff0000082ad998>] vfs_write+0xa8/0x198 [ 3303.276196] [<ffff0000082adc7c>] SyS_write+0x6c/0xd4 [ 3303.281147] Exception stack(0xffff00000f643ec0 to 0xffff00000f644000) [ 3303.287573] 3ec0: 0000000000000003 0000fffffc85faa8 0000000000004e60 0000000000000000 [ 3303.295388] 3ee0: 0000000021fb2000 000000000000ffff eff0e3efe4e58080 0000fffffcc724fe [ 3303.303204] 3f00: 0000000000000040 1999999999999999 0101010101010101 0000000000000038 [ 3303.311019] 3f20: 0000000000000005 ffffffffffffffff 0d73757461747320 ffffffffffffffff [ 3303.318835] 3f40: 0000000000000000 0000000000459b00 0000fffffc85e360 000000000043d788 [ 3303.326650] 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.334465] 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.342281] 3fa0: 0000000000000000 0000fffffc85e570 0000000000438804 0000fffffc85e570 [ 3303.350096] 3fc0: 0000ffff8553f618 0000000080000000 0000000000000003 0000000000000040 [ 3303.357911] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 3303.365729] [<ffff000008083808>] __sys_trace_return+0x0/0x4 [ 3303.371288] Code: b94008e9 34000129 b9400ce2 110006b5 (b9000402) [ 3303.377377] ---[ end trace fd5ab98b3325cf9a ]--- Reported-by:
Jie Chen <chenjie103@huawei.com> Reported-by:
Xiping Zhang (Francis) <zhangxiping3@huawei.com> Fixes: b1c15835("RDMA/hns: Get rid of virt_to_page and vmap calls after dma_alloc_coherent") Signed-off-by:
-
Wei Hu(Xavier) authored
This patch added reset process for RoCE in hip08. Signed-off-by:
-
- 29 May, 2018 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaJason Gunthorpe authored
Leon Romanovsky says: ==================== Introduce new internal to mlx5 CQE format - mini-CQE. It is a CQE in compressed form that holds data needed to extra a single full CQE. It is a stride index, byte count and packet checksum. ==================== * mini_cqe: IB/mlx5: Introduce a new mini-CQE format IB/mlx5: Refactor CQE compression response net/mlx5: Exposing a new mini-CQE format Signed-off-by: -
Jason Gunthorpe authored
This once might have made sense when cache.c was in a different module from device.c, but today it just obfuscation. Get rid of the wrappers and call roge_gid_mgmt_init()/cleanup() directly. Signed-off-by:
-
Yonatan Cohen authored
The new mini-CQE format includes the stride index, byte count and packet checksum. Stride index is needed for striding WQ feature. This patch exposes this capability and enables its setting via mlx5 UHW data as part of query device and cq creation. Reviewed-by:
Guy Levi <guyle@mellanox.com> Signed-off-by:
Yonatan Cohen <yonatanc@mellanox.com> Signed-off-by:
-
Yonatan Cohen authored
Refactor CQE compression response to be fully set only when it`s really supported. There is no change from user perspective because anyway resp.cqe_comp_caps.max_num was set to zero. Reviewed-by:
-
Yonatan Cohen authored
The new mini-CQE format includes byte-count, checksum and stride index. Reviewed-by:
Saeed Mahameed <saeedm@mellanox.com>
-
- 28 May, 2018 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaJason Gunthorpe authored
Update mlx4 to support user MR creation against read-only memory, previously it required the memory to be writable. Based on rdma for-rc due to dependencies. * mr_fix: (2 commits) IB/mlx4: Mark user MR as writable if actual virtual memory is writable IB/core: Make testing MR flags for writability a static inline function
-
Jack Morgenstein authored
To allow rereg_user_mr to modify the MR from read-only to writable without using get_user_pages again, we needed to define the initial MR as writable. However, this was originally done unconditionally, without taking into account the writability of the underlying virtual memory. As a result, any attempt to register a read-only MR over read-only virtual memory failed. To fix this, do not add the writable flag bit when the user virtual memory is not writable (e.g. const memory). However, when the underlying memory is NOT writable (and we therefore do not define the initial MR as writable), the IB core adds a "force writable" flag to its user-pages request. If this succeeds, the reg_user_mr caller gets a writable copy of the original pages. If the user-space caller then does a rereg_user_mr operation to enable writability, this will succeed. This should not be allowed, since the original virtual memory was not writable. Cc: <stable@vger.kernel.org> Fixes: 9376932d ("IB/mlx4_ib: Add support for user MR re-registration") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
