- 04 Dec, 2018 13 commits
-
-
Doug Ledford authored
The enhanced devx support series needs commit: 9d43faac ("net/mlx5: Update mlx5_ifc with DEVX UCTX capabilities bits") Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Yishai Hadas authored
Expose device capabilities for DEVX user context, it includes which caps the device is supported and a matching bit to set as part of user context creation. Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Reviewed-by:
Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com>
-
Leon Romanovsky authored
There is no need to perform modify_rmp in two separate function, while one of them uses stack as a placeholder for data while other allocates it dynamically. Combine those two functions to one call instead of two. Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
-
Leon Romanovsky authored
There is no need to perform create_rmp in two separate function, while one of them uses stack as a placeholder for data while other allocates it dynamically. Combine those two functions to one instead of two. Reviewed-by:
-
Leon Romanovsky authored
Transfer initialization and cleanup from mlx5_priv struct of mlx5_core_dev to be part of mlx5_ib_dev. This completes removal of SRQ from mlx5_core. Reviewed-by:
-
Leon Romanovsky authored
Reflect the change of moving SRQ code from mlx5_core to mlx5_ib by updating function signatures do not require mlx5_core_dev as an input, because all operations in mlx5_ib are supposed to use mlx5_ib_dev. Reviewed-by:
-
Leon Romanovsky authored
Reuse existing infrastructure to initialize and release DEVX uid. The DevX interface is intended for user space access, so it is supposed to be initialized before ib_register_device(). Also it isn't supported in switchdev mode and don't need to initialize it in that mode. Fixes: 76dc5a84 ("IB/mlx5: Manage device uid for DEVX white list commands") Reviewed-by:
-
Leon Romanovsky authored
SRQ signature is not supported, hence no need for special static global variable to announce it. Reviewed-by:
-
Leon Romanovsky authored
There is no need to keep SRQ which is RDMA object in mlx5_core. In this patch, we partially move the execution code, while next patches will move table initialization/release logic too. Reviewed-by:
-
Leon Romanovsky authored
As a preparation to move SRQ functionality to RDMA, drop all references to mlx5_core logic and make SRQ be dependent on shared code only. Most of the time, we are interested to know if events are working/not working and it is possible with previous commit ("net/mlx5: Debug print for forwarded async events"). Reviewed-by: -
Leon Romanovsky authored
lib/eq.h is needed for EQ manipulation which are not performed in SRQ. Reviewed-by:
-
Leon Romanovsky authored
Delete functions which are not called and not needed. Reviewed-by:
-
Leon Romanovsky authored
Ensure that both RDMA and netdev parts of SRQ implementation has same copyright and license information annotated by SPDX tags. Reviewed-by:
-
- 03 Dec, 2018 16 commits
-
-
Leon Romanovsky authored
[leonro@server ~]$ rdma res show 1: mlx5_0: pd 3 cq 5 qp 4 cm_id 0 mr 0 ctx 0 Signed-off-by:
-
Leon Romanovsky authored
Add restrack annotations to track allocations of ucontexts. Signed-off-by:
-
Leon Romanovsky authored
Add ability to track allocated ib_ucontext, which are limited resource and worth to be visible by users. Signed-off-by:
-
Doug Ledford authored
Make all of the write() handlers use a consistent flow From Jason, This series unifies all the write handlers to use a flow that is very similar to the ioctl handler flow, including having the same basic assumptions about extensible buffer handling and the same handler function call signature. Along the way this consolidates all the copy_to/from_user into a small set of safe buffer accessor functions tailored to the usage here. These accessors use the new dispatcher-controlled calling convention for ucore data, and support a placement of the response that does not rely on the cmd.response value. Overall this brings in in strong bounds checking to all the write() handlers and consistent enforcement of the zero-fill/zero-check methodology for buffer extension. The end result is a significant complexity reduction for all of the handlers and creates a high degree of uniformity between the write, write_ex, and ioctl handlers and dispatch flow. Thanks Jason Gunthorpe (12): RDMA/uverbs: Remove out_len checks that are now done by the core RDMA/uverbs: Use uverbs_attr_bundle to pass ucore for write/write_ex RDMA/uverbs: Get rid of the 'callback' scheme in the compat path RDMA/uverbs: Use uverbs_response() for remaining response copying RDMA/uverbs: Use uverbs_request() for request copying RDMA/uverbs: Use uverbs_request() and core for write_ex handlers RDMA/uverbs: Fill in the response for IB_USER_VERBS_EX_CMD_MODIFY_QP RDMA/uverbs: Simplify ib_uverbs_ex_query_device RDMA/uverbs: Add a simple iterator interface for reading the command RDMA/uverbs: Use the iterator for ib_uverbs_unmarshall_recv() RDMA/uverbs: Do not check the input length on create_cq/qp paths RDMA/uverbs: Use only attrs for the write() handler signature drivers/infiniband/core/rdma_core.h | 5 +- drivers/infiniband/core/uverbs_cmd.c | 1165 ++++++++++--------------- drivers/infiniband/core/uverbs_main.c | 23 +- drivers/infiniband/core/uverbs_uapi.c | 23 +- include/rdma/uverbs_ioctl.h | 9 +- 5 files changed, 479 insertions(+), 746 deletions(-) Signed-off-by: -
Jason Gunthorpe authored
All of the old arguments can be derived from the uverbs_attr_bundle structure, so get rid of the redundant arguments. Most of the prior work has been removing users of the arguments to allow this to be a simple patch. Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Jason Gunthorpe authored
If the user did not provide a long enough command buffer then the missing bytes are forced to zero. There is no reason to check the length if a zero value is OK. Signed-off-by:
-
Jason Gunthorpe authored
This has a very complicated memory layout, with two flex arrays. Use the iterator API to make reading it clearer. Signed-off-by:
-
Jason Gunthorpe authored
Several methods have a command with a trailing flex array, and they all open code some extraction scheme. Centralize this into a simple iterator API. Signed-off-by:
-
Jason Gunthorpe authored
We truncate the response structure if there is not enough room in the user buffer so there is no reason to have all the mess with finely managing response_length. Just fully fill the attrs and truncate on copy. Signed-off-by:
-
Jason Gunthorpe authored
A response struct was defined, and userspace is providing it (but not checking it). Fill it in and write it out. Signed-off-by:
-
Jason Gunthorpe authored
The write_ex handlers have this horrible boilerplate in every function to do the zero extend/zero check and min size checks. This is now handled in the core code via the meta-data, and the zero checks are handled by uverbs_request(). Replace all the occurrences. Signed-off-by:
-
Jason Gunthorpe authored
This function properly zero-extends, and zero-checks if the user buffer is not the same size as the kernel command struct. Signed-off-by:
-
Jason Gunthorpe authored
This function properly truncates and zero-fills the response which is the standard used by the ioctl uAPI when working with user data. Signed-off-by:
-
Jason Gunthorpe authored
There is no reason for this. For response processing we simply need to copy, truncate, and zero fill the response into whatever output buffer was provided. Add a function uverbs_response() that does this consistently. Signed-off-by:
-
Jason Gunthorpe authored
This creates a consistent way to access the two core buffers across write and write_ex handlers. Remove the open coded ucore conversion in the write/ex compatibility handlers. Signed-off-by:
-
Jason Gunthorpe authored
write() methods must work with fixed sized structures as that is the only way to know where the udata segment starts. The common udata code now rejects any write() that has a response buffer shorter than the core's response. Thus all the checks of out_len for write methods are redundant and can be removed. Signed-off-by:
-
- 30 Nov, 2018 11 commits
-
-
Saeed Mahameed authored
Print a debug message for every async FW event forwarded to mlx5 interfaces (mlx5e netdev and mlx5_ib rdma module). Signed-off-by:Saeed Mahameed <saeedm@mellanox.com>
-
Saeed Mahameed authored
Allow forwarding of SRQ events to mlx5_core interfaces, e.g. mlx5_ib. Use mlx5_notifier_register/unregister in srq.c in order to allow seamless transition of srq.c to infiniband subsystem. Signed-off-by: -
Saeed Mahameed authored
Allow forwarding QP and WQ events to mlx5_core interfaces, e.g. mlx5_ib Use mlx5_notifier_register/unregister in qp.c in order to allow seamless transition of qp.c to infiniband subsystem. Signed-off-by: -
Saeed Mahameed authored
Before the new mlx5 event notification infrastructure and API, mlx5_core used to process all events before forwarding them to mlx5 interfaces (mlx5e/mlx5_ib) and used to translate the event type enum to a software defined enum, this is not needed anymore since it is ok for mlx5e and mlx5_ib to receive FW events as is, at least the few ones mlx5 core allows. mlx5e and mlx5_ib already moved to use the new API and they only handle FW events types, it is now safe to remove all equivalent software defined events and the logic around them. Signed-off-by: -
Saeed Mahameed authored
Handle FW general event rq delay drop as it was received from FW via mlx5 notifiers API, instead of handling the processed software version of that event. After this patch we can safely remove all software processed FW events types and definitions. Signed-off-by: -
Saeed Mahameed authored
FW general event is used by mlx5_ib for RQ delay drop timeout event handling, in this patch we allow to forward FW general event type to mlx5 notifiers chain so mlx5_ib can handle it and to deprecate the software version of it. Signed-off-by: -
Saeed Mahameed authored
Use the FW version of the port change event as forwarded via new mlx5 notifiers API. After this patch, processed software version of the port change event will become deprecated and will be totally removed in downstream patches. Signed-off-by: -
Saeed Mahameed authored
The mlx5_interface->event callback is not used by mlx5e/mlx5_ib anymore. We totally remove the delayed events logic work around, since with the dynamic notifier registration API it is not needed anymore, mlx5_ib can register its notifier and start receiving events exactly at the moment it is ready to handle them. Signed-off-by: -
Saeed Mahameed authored
Remove the deprecated mlx5_interface->event mlx5_ib callback and use new mlx5 notifier API to subscribe for mlx5 events. For native mlx5_ib devices profiles pf_profile/nic_rep_profile register the notifier callback mlx5_ib_handle_event which treats the notifier context as mlx5_ib_dev. For vport repesentors, don't register any notifier, same as before, they didn't receive any mlx5 events. For slave port (mlx5_ib_multiport_info) register a different notifier callback mlx5_ib_event_slave_port, which knows that the event is coming for mlx5_ib_multiport_info and prepares the event job accordingly. Before this on the event handler work we had to ask mlx5_core if this is a slave port mlx5_core_is_mp_slave(work->dev), now it is not needed anymore. mlx5_ib_multiport_info notifier registration is done on mlx5_ib_bind_slave_port and de-registration is done on mlx5_ib_unbind_slave_port. Signed-off-by: -
Saeed Mahameed authored
This to allow seamless migration to the new notifier chain API, and to eventually deprecate interfaces dev->event callback. Signed-off-by: -
Saeed Mahameed authored
Remove the deprecated mlx5_interface->event mlx5e callback and use new mlx5 notifier API to subscribe for mlx5 events, handle port change event as received from FW rather than handling the mlx5 core processed port change software version event. Signed-off-by:
-
