- 04 Apr, 2018 14 commits
-
-
Matan Barak authored
Binding a flow_action to flow steering rule requires using a new specification. Therefore, adding such an IB_FLOW_SPEC_ACTION_HANDLE flow specification. Flow steering rules could use flow_action(s) and as of that we need to avoid deleting flow_action(s) as long as they're being used. Moreover, when the attached rules are deleted, action_handle reference count should be decremented. Introducing a new mechanism of flow resources to keep track on the attached action_handle(s). Later on, this mechanism should be extended to other attached flow steering resources like flow counters. Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com>
-
Matan Barak authored
A verbs application may receive and transmits packets using a data path pipeline. Sometimes, the first stage in the receive pipeline or the last stage in the transmit pipeline involves transforming a packet, either in order to make it easier for later stages to process it or to prepare it for transmission over the wire. Such transformation could be stripping/encapsulating the packet (i.e. vxlan), decrypting/encrypting it (i.e. ipsec), altering headers, doing some complex FPGA changes, etc. Some hardware could do such transformations without software data path intervention at all. The flow steering API supports steering a packet (either to a QP or dropping it) and some simple packet immutable actions (i.e. tagging a packet). Complex actions, that may change the packet, could bloat the flow steering API extensively. Sometimes the same action should be applied to several flows. In this case, it's easier to bind several flows to the same action and modify it than change all matching flows. Introducing a new flow_action object that abstracts any packet transformation (out of a standard and well defined set of actions). This flow_action object could be tied to a flow steering rule via a new specification. Currently, we support esp flow_action, which encrypts or decrypts a packet according to the given parameters. However, we present a flexible schema that could be used to other transformation actions tied to flow rules. Reviewed-by:
-
Matan Barak authored
The current implementation of kern_spec_to_ib_spec_filter, which takes a uAPI based flow steering specification and creates the respective kernel API flow steering structure, gets a ib_uverbs_flow_spec structure. The new flow_action uAPI gets a match mask and filter from user-space which aren't encoded in the flow steering's ib_uverbs_flow_spec structure. Exporting the logic out of kern_spec_to_ib_spec_filter to get user-space blobs rather than ib_uverbs_flow_spec structure. Reviewed-by:
-
Boris Pismenny authored
ConnectX3 doesn't support egress flow steering. Return an EOPNOTSUPP error when such a flow is being created. Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Reviewed-by:
Aviad Yehezkel <aviadye@mellanox.com> Reviewed-by:
-
Matan Barak authored
Methods sometimes need to get one attribute out of a group of pre-defined attributes. This is an enum-like behavior. Since this is a common requirement, we add a new ENUM attribute to the generic uverbs ioctl() layer. This attribute is embedded in methods, like any other attributes we currently have. ENUM attributes point to an array of standard UVERBS_ATTR_PTR_IN. The user-space encodes the enum's attribute id in the id field and the internal PTR_IN attr id in the enum_data.elem_id field. This ENUM attribute could be shared by several attributes and it can get UVERBS_ATTR_SPEC_F_MANDATORY flag, stating this attribute must be supported by the kernel, like any other attribute. Reviewed-by:
-
Matan Barak authored
In order to have a custom parsing tree, a provider driver needs to assign its parsing tree to ib_device specs_tree field. Otherwise, the uverbs client assigns a common default parsing tree for it. In downstream patches, the mlx5_ib driver gains a custom parsing tree, which contains both the common objects and a new flags field for the UVERBS_FLOW_ACTION_ESP_CREATE command. This patch makes mlx5_ib assign its own tree to specs_root, which later on will be extended. Reviewed-by:
-
Parav Pandit authored
Now that ib_gid_attr contains device, port and index, simplify the provider APIs add_gid() and del_gid() to use device, port and index fields from the ib_gid_attr attributes structure. Signed-off-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Now that IB core GID cache ensures that all RoCE entries have an associated netdev remove null checks from the provider drivers for clarity. Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Now that the IB core GID cache ensures that a zero GID doesn't exist in the GID table remove zero GID checks from the provider drivers for clarity. Reviewed-by:
-
Parav Pandit authored
Code is refactored to prepare separate functions for RoCE which can do more complex operations related to reference counting, while still maintainining code readability. This includes (a) Simplification to not perform netdevice checks and modifications for IB link layer. (b) Do not add RoCE GID entry which has NULL netdevice; instead return an error. (c) If GID addition fails at provider level add_gid(), do not add the entry in the cache and keep the entry marked as INVALID. (d) Simplify and reuse the ib_cache_gid_add()/del() routines so that they can be used even for modifying default GIDs. This avoid some code duplication in modifying default GIDs. (e) find_gid() routine refers to the data entry flags to qualify a GID as valid or invalid GID rather than depending on attributes and zeroness of the GID content. (f) gid_table_reserve_default() sets the GID default attribute at beginning while setting up the GID table. There is no need to use default_gid flag in low level functions such as write_gid(), add_gid(), del_gid(), as they never need to update the DEFAULT property of the GID entry while during GID table update. As as result of this refactor, reserved GID 0:0:0:0:0:0:0:0 is no longer searchable as described below. A unicast GID entry of 0:0:0:0:0:0:0:0 is Reserved GID as per the IB spec version 1.3 section 4.1.1, point (6) whose snippet is below. "The unicast GID address 0:0:0:0:0:0:0:0 is reserved - referred to as the Reserved GID. It shall never be assigned to any endport. It shall not be used as a destination address or in a global routing header (GRH)." GID table cache now only stores valid GID entries. Before this patch, Reserved GID 0:0:0:0:0:0:0:0 was searchable in the GID table using ib_find_cached_gid_by_port() and other similar find routines. Zero GID is no longer searchable as it shall not to be present in GRH or path recored entry as described in IB spec version 1.3 section 4.1.1, point (6), section 12.7.10 and section 12.7.20. ib_cache_update() is simplified to check link layer once, use unified locking scheme for all link layers, removed temporary gid table allocation/free logic. Additionally, (a) Expand ib_gid_attr to store port and index so that GID query routines can get port and index information from the attribute structure. (b) Expand ib_gid_attr to store device as well so that in future code when GID reference counting is done, device is used to reach back to the GID table entry. Signed-off-by:
-
Parav Pandit authored
Currently following inconsistencies exist. 1. ib_query_gid() returns GID from the software cache for a RoCE port and returns GID from the HCA for an IB port. This is incorrect because software GID cache is maintained regardless of HCA port type. 2. GID is queries from the HCA via ib_query_gid and updated in the software cache for IB link layer. Both of them might not be in sync. ULPs such as SRP initiator, SRP target, IPoIB driver have historically used ib_query_gid() API to query the GID. However CM used cached version during CM processing, When software cache was introduced, this inconsitency remained. In order to simplify, improve readability and avoid link layer specific above inconsistencies, this patch brings following changes. 1. ib_query_gid() always refers to the cache layer regardless of link layer. 2. cache module who reads the GID entry from HCA and builds the cache, directly invokes the HCA provider verb's query_gid() callback function. 3. ib_query_port() is being called in early stage where GID cache is not yet build while reading port immutable property. Therefore it needs to read the default GID from the HCA for IB link layer to publish the subnet prefix. Signed-off-by:
-
Parav Pandit authored
ib_query_gid() fetches the GID from the software cache maintained in ib_core for RoCE ports. Therefore, simplify the provider drivers for RoCE to treat query_gid() callback as never called for RoCE, and only require non-RoCE devices to implement it. Signed-off-by:
-
Parav Pandit authored
query_gid() should return right GID value for iWarp and IB link layers. It is a no-op for RoCE link layer. Update the documentation to reflect this. Signed-off-by:
-
Roland Dreier authored
Check to make sure that ctx->cm_id->device is set before we use it. Otherwise userspace can trigger a NULL dereference by doing RDMA_USER_CM_CMD_SET_OPTION on an ID that is not bound to a device. Cc: <stable@vger.kernel.org> Reported-by: <syzbot+a67bc93e14682d92fc2f@syzkaller.appspotmail.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
- 03 Apr, 2018 5 commits
-
-
Parav Pandit authored
qedr driver's add_gid() and del_gid() callbacks are doing simple checks which are already done by the ib core before invoking these callback routines. Therefore, code is simplified to skip implementing add_gid() and del_gid() callback functions. Signed-off-by:
-
Shiraz Saleem authored
Support for resource profile 1 is currenlty deprecated due to a pre-production errata. Remove this workaround as its no longer needed. Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
-
Jason Gunthorpe authored
This structure is pushed down the ex and the non-ex path, so it needs to be aligned to 8 bytes to go through ex without implicit padding. Old user space will provide 4 bytes of resp on !ex and 8 bytes on ex, so take the approach of just copying the minimum length. New user space will consistently provide 8 bytes in both cases. Signed-off-by:
-
Gustavo A. R. Silva authored
Check on return values and goto label mbx_err are unnecessary. Addresses-Coverity-ID: 1271151 ("Identical code for different branches") Addresses-Coverity-ID: 1268788 ("Identical code for different branches") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Yuval Shaia authored
This structure is not needed since the introduction of commit 'c4268778 ("IB/ipoib: Scatter-Gather support in connected mode")' Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Reviewed-by:
Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by:
-
- 29 Mar, 2018 8 commits
-
-
Bharat Potnuri authored
c4iw_ep_common structure holds the mapped addresses, so while printing them, use appropriate pointers. Fixes: bab572f1 ("iw_cxgb4: Guard against null cm_id in dump_ep/qp") Signed-off-by:
Potnuri Bharat Teja <bharat@chelsio.com> Signed-off-by:
-
Parav Pandit authored
rdma_cm_state enum is internal to rdma_cm kernel module. It is not required to expose state enums to ULP modules. So lets keep its scope limited to rdma_cm module in cma_priv.h file. Signed-off-by:
-
Parav Pandit authored
Make dst_entry pointer as const struct dst_entry* to improve code readablity to make sure that dst structure fields are not modified by various functions which are using it. Signed-off-by:
-
Jason Gunthorpe authored
This is already used in many places, get the rest of them too, only to make the code a bit clearer & simpler. Signed-off-by: -
Leon Romanovsky authored
Export the net device name and index to easily find connection between IB devices and relevant net devices. We also updated the comment regarding the devices without FW. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
-
Zhu Yanjun authored
In mcast recv process, the function skb_clone is used. In fact, the refcount can be increased to replace cloning a new skb since the original skb will not be modified before it is freed. This can make the performance better and save the memory. CC: Srinivas Eeda <srinivas.eeda@oracle.com> CC: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in DP_ERR message text Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Signed-off-by:
-
Steve Wise authored
Since the rdma_port_space enum is being passed between user and kernel for user cm_id setup, we need it in a UAPI header. So add it to rdma_user_cm.h. This also fixes the cm_id restrack changes which pass up the port space value via the RDMA_NLDEV_ATTR_RES_PS attribute. Fixes: 00313983 ("RDMA/nldev: provide detailed CM_ID information") Signed-off-by:
-
- 28 Mar, 2018 1 commit
-
-
Steve Wise authored
This is no longer supported, so remove it. Signed-off-by:
-
- 27 Mar, 2018 12 commits
-
-
Parav Pandit authored
IB core maintains the GID cache entries for the GID table. This cache table has to be maintained regardless of HCA's support of GID table. For IB and iWarp ports, cache is created by querying the HCA. For RoCE cache is created based on netdev events. Therefore just refer to the RoCE port property of the {device, port} to decide whether to build cache by querying HCA or from netdev events. There is no need to check if HCA support GID table or not. ib_cache_update() referred to RoCE attribute before validating port. Though in all current callers port is valid, it is incorrect to query RoCE port property before validating the port. Therefore, rdma_protocol_roce() check is done after rdma_is_port_valid() verifies that port is valid. Fixes: 115b68aa ("IB/ocrdma: Removed GID add/del null routines") Reviewed-by:Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Even though API is only used by IPoIB driver, its incorrect to refer RoCE GID table property to search for GID. Look for only IB link layer to search for the GID. Fixes: dbb12562 ("IB/{core, ipoib}: Simplify ib_find_gid to search only for IB link layer") Signed-off-by:
-
Parav Pandit authored
ib_find_gid_by_filter() searches GID with filter only for RoCE link layer regardless of HCA's support for GID table. Therefore, right way to lookup is compare RoCE port property and not the GID table property. Fixes: 99b27e3b ("IB/cache: Add ib_find_gid_by_filter cache API") Signed-off-by:
-
Parav Pandit authored
Due to following reasons, GID table event is generated regardless of GID table property. 1. GID table cache is maintained at ib core layer regardless of link layer. 2. GID change event has no relation with IB link layer. 3. GID change event also doesn't depend on whether HCA supports GID table or not. Fixes: f3906bd3 ("IB/core: Refactor GID cache's ib_dispatch_event") Signed-off-by:
-
Parav Pandit authored
Due to below reasons, it is better to not support alternate path receive messages for RoCE in near term. 1. Alternate path for RoCE is not supported at rdmacm layer. 2. It is not supported in uverbs/core layer for RoCE. 3. Alternate path for IPv6 for link local address cannot resolve route determinstically without a valid incoming interface id whose usecase make sense only with dual port mode. 4. init_av_from_path while processing LAP messages for IB and RoCE can lead to adding duplicate entry of AV into the port list, leads to list corruption. 5. rdma-core userspace a well known userspace implementation has removed support of libucm which use ucm.ko module, which is the only module that can trigger alternate path related messages. 6. ucm kernel module is requested to be removed from the IB core in patch [1]. [1] https://patchwork.kernel.org/patch/10268503/Signed-off-by:
-
Mark Bloch authored
Currently access to hardware stats buffer isn't protected, this can result in multiple writes and reads at the same time to the same memory location. This can lead to providing an incorrect value to the user. Add a mutex to protect against it. Fixes: b40f4757 ("IB/core: Make device counter infrastructure dynamic") Signed-off-by:
-
Majd Dibbiny authored
In some firmware configuration, UMR usage from Virtual Functions is restricted. This information is published to the driver using new capability bits. Avoid using UMRs in these cases and use the Firmware slow-path flow to create mkeys and populate them with Virtual to Physical address translation. Older drivers that do not have this patch, will end up using memory keys that aren't populated with Virtual to Physical address translation that is done part of the UMR work. Reviewed-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
Majd Dibbiny authored
When working with RC QPs, the FW sets the ECN capable bits for all the RoCE v2 packets. On the other hand, for UD QPs, the driver needs to set the the ECN capable bits in the Address Handler since the HW generates each packet according to the Address Handler and not the QP context. If ECN is not enabled in NIC or switch, these bits are ignored. Fixes: 2811ba51 ("IB/mlx5: Add RoCE fields to Address Vector") Reviewed-by:
-
Matan Barak authored
The ioctl() UAPIs are meant to be used by both user-space and kernel ioctl() handlers. Mostly, these UAPI structs tend to consist of simple types, but sometimes user-space pointers may be passed between user-space and kernel. We would like to avoid dereferencing a user-space pointer in the kernel, thus - we always define RDMA_UAPI_PTR as a __aligned_u64 type. Fixes: 1f7ff9d5 ('IB/uverbs: Move to new headers and make naming consistent') Signed-off-by:
-
Jason Gunthorpe authored
The design of the uAPI had intended all structs to share the same layout on 32 and 64 bit compiles. Unfortunately over the years some errors have crept in. This series fixes all the incompatabilities. It goes along with a userspace rdma-core series that causes the providers to use these structs directly and then does various self-checks on the command formation. Those checks were combined with output from pahole on 32 and 64 bit compiles to confirm that the structure layouts are the same. This series does not make implicit padding explicit, as long as the implicit padding is the same on 32 and 64 bit compiles. Finally, the issue is put to rest by using __aligned_u64 in the uapi headers, if new code copies that type, and is checked in userspace, it is unlikely we will see problems in future. There are two patches that break the ABI for a 32 bit kernel, one for rxe and one for mlx4. Both patches have notes, but the overall feeling from Doug and I is that providing compat is just too difficult and not necessary since there is no real user of a 32 bit userspace and 32 bit kernel for various good reasons. The 32 bit userspace / 64 bit kernel case however does seem to have some real users and does need to work as designed. * 32compat: RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 RDMA/rxe: Fix uABI structure layouts for 32/64 compat RDMA/mlx4: Fix uABI structure layouts for 32/64 compat RDMA/qedr: Fix uABI structure layouts for 32/64 compat RDMA/ucma: Fix uABI structure layouts for 32/64 compat RDMA: Remove minor pahole differences between 32/64
-
Jason Gunthorpe authored
The new auditing standard for the subsystem will be to only use __aligned_64 in uapi headers to try and prevent 32/64 compat bugs from existing in the future. Changing all existing usage will help ensure new developers copy the right idea. The before/after of this patch was tested using pahole on 32 and 64 bit compiles to confirm it has no change in the structure layout, so this patch is a NOP. Signed-off-by: -
Jason Gunthorpe authored
With 32 bit compilation several of the fields become misaligned here. Fixing this is an ABI break for 32 bit rxe and it is in well used portions of the rxe ABI. To handle this we bump the ABI version, as expected. However the user space driver doesn't handle it properly today, so all existing user space continues to work. Updated userspace will start to require the necessary kernel version. We don't expect there to be any 32 bit users of rxe. Most likely cases, such as ARM 32 already generally don't work because rxe does not handle the CPU cache properly on its shared with userspace pages. Signed-off-by:
-
