- 20 Apr, 2017 25 commits
-
-
Erez Shitrit authored
IPoIB driver now uses the new set of callback functions. If the hardware provider supports the new ipoib_options implementation, the driver uses the callbacks in its data path flows, otherwise it uses the driver default implementation for all data flows in its code. The default implementation wasn't change and it is exactly as it was before introduction of acceleration support. Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Erez Shitrit authored
Make ipoib_priv point to netdev_priv where the code calls netdev_priv. Signed-off-by:
-
Erez Shitrit authored
Change of function parameter name from qpn to be dqpn. Signed-off-by:
-
Erez Shitrit authored
This patch is preparing the netdev part at the IPoIB driver to be able to use the ipoib_options. It deals with the two flows from the .ndo: ipoib_open and ipoib_stop. The code is rearranged as follows: * All operations which deal with the hardware resources, (for example change QP state, post-receive etc.) are performed in one place. * All operations that are control oriented (like restart multicast task, start the reap_ah etc.) are performed in separate place. The functions that deal with the hardware resources now located at __ipoib_ib_dev_open for the ipoib_open flow and __ipoib_ib_dev_stop for ipoib_stop. Signed-off-by:
-
Erez Shitrit authored
This patch prepares init and teardown flows so we can call them through ipoib_options function pointers. It arranges that area of code as the following: * All operations which deal with the resource allocation/deletion are performed in one place. * All operations that are control oriented, meaning that they are not connected to a specific hardware, are performed in a separate place. The operations for allocation of hardware resources are now in the function ipoib_dev_init_default, and the deletion of all the resources are in ipoib_dev_uninit_default The only exception is the creation of the PD object, which is used both for resource allocation (create QP etc.) and for control flows like creating AH. It also does: * Move creation of rx_ring and tx_ring to be in the resources allocation area. * Move the function ipoib_ib_dev_open that does the open device to the control area instead of the dev_init which creates resources. Signed-off-by:
-
Niranjana Vishwanathapura authored
Add RDMA netdev interface to ib device structure allowing RDMA netdev devices to be allocated by ib clients. The idea is to allow to providers to optimize IPoIB data path. New struct that includes functions and data member is exposed. It exposes set of callback functions for handling data path flows in IPoIB driver. Each provider can support these set of functions in order to optimize its specific data path, and let IPoIB to leverage its data path. There is an assumption, that providers should give the full set of functions and not only part of them, in order to work properly. Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Vishwanathapura, Niranjana authored
HFI1 VNIC SDMA support enables transmission of VNIC packets over SDMA. Map VNIC queues to SDMA engines and support halting and wakeup of the VNIC queues. Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Signed-off-by:
-
Vishwanathapura, Niranjana authored
HFI1 HW specific support for VNIC functionality. Dynamically allocate a set of contexts for VNIC when the first vnic port is instantiated. Allocate VNIC contexts from user contexts pool and return them back to the same pool while freeing up. Set aside enough MSI-X interrupts for VNIC contexts and assign them when the contexts are allocated. On the receive side, use an RSM rule to spread TCP/UDP streams among VNIC contexts. Reviewed-by:
Andrzej Kacprowski <andrzej.kacprowski@intel.com> Signed-off-by:
-
Vishwanathapura, Niranjana authored
Add support to create and free OPA_VNIC rdma netdev devices. Implement netstack interface functionality including xmit_skb, receive side NAPI etc. Also implement rdma netdev control functions. Reviewed-by:
-
Vishwanathapura, Niranjana authored
OPA VEMA function interfaces with the Infiniband MAD stack to exchange the management information packets with the Ethernet Manager (EM). It interfaces with the OPA VNIC netdev function to SET/GET the management information. The information exchanged with the EM includes class port details, encapsulation configuration, various counters, unicast and multicast MAC list and the MAC table. It also supports sending traps to the EM. Reviewed-by:
Sadanand Warrier <sadanand.warrier@intel.com> Signed-off-by:
Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by:
-
Vishwanathapura, Niranjana authored
OPA VNIC EMA interface functions are the management interfaces to the OPA VNIC netdev. Add support to add and remove VNIC ports. Implement the required GET/SET management interface functions and processing of new management information. Add support to send trap notifications upon various events like interface status change, unicast/multicast mac list update and mac address change. Reviewed-by:
-
Vishwanathapura, Niranjana authored
OPA VNIC MAC table contains the MAC address to DLID mappings provided by the Ethernet manager. During transmission, the MAC table provides the MAC address to DLID translation. Implement MAC table using simple hash list. Also provide support to update/query the MAC table by Ethernet manager. Reviewed-by:
-
Vishwanathapura, Niranjana authored
OPA VNIC driver statistics support maintains various counters including standard netdev counters and the Ethernet manager defined counters. Add the Ethtool hook to read the counters. Reviewed-by:
-
Vishwanathapura, Niranjana authored
Define VNIC EM MAD structures and the associated macros. These structures are used for information exchange between VNIC EM agent (EMA) on the host and the Ethernet manager. These include the virtual ethernet switch (vesw) port information, vesw port mac table, summay and error counters, vesw port interface mac lists and the EMA trap. Reviewed-by:
-
Vishwanathapura, Niranjana authored
OPA VNIC netdev function supports Ethernet functionality over Omni-Path fabric by encapsulating Ethernet packets inside Omni-Path packet header. It allocates a rdma netdev device and interfaces with the network stack to provide standard Ethernet network interfaces. It overrides HFI1 device's netdev operations where it is required. Reviewed-by:
-
Vishwanathapura, Niranjana authored
Define OPA VNIC interface between hardware independent VNIC functionality and the hardware dependent VNIC functionality. Reviewed-by:
-
Vishwanathapura, Niranjana authored
Add rdma netdev interface to ib device structure allowing rdma netdev devices to be allocated by ib clients. Reviewed-by:
-
Vishwanathapura, Niranjana authored
Add OPA VNIC design document explaining the VNIC architecture and the driver design. Reviewed-by:
-
Doug Ledford authored
-
Matan Barak authored
Previously, ib_uverbs_event_file was suffixed by _file as it contained the actual file information. Since it's now only used as base struct for ib_uverbs_async_event_file and ib_uverbs_completion_event_file, we change its name to ib_uverbs_event_queue. This represents its logical role better. Fixes: 1e7710f3 ('IB/core: Change completion channel to use the reworked objects schema') Signed-off-by:
Matan Barak <matanb@mellanox.com> Reviewed-by:
Sean Hefty <sean.hefty@intel.com> Signed-off-by:
-
Matan Barak authored
Previously, we inferred the events size in ib_uverbs_event_read by using the is_async flag. Instead of that, we pass the event size directly. Fixes: 1e7710f3 ('IB/core: Change completion channel to use the reworked objects schema') Signed-off-by:
-
Matan Barak authored
Instead of having uverbs_uobject_put both in the error flow and the good flow, we unite them. Fixes: fd3c7904 ('IB/core: Change idr objects to use the new schema') Signed-off-by:
-
Matan Barak authored
Currently, we initialize all fields of ib_uobject straight after allocation. Therefore, a kmalloc was sufficient. Since ib_uobject could be embedded in a type specific structure, we nullify it to spare programmer errors. Fixes: 38321256 ('IB/core: Add support for idr types') Signed-off-by:
-
Matan Barak authored
The only scenario where this function was called while the lock is already taken is in the context cleanup scenario. Thus, in order not to pass the lock state to this function, we just call the remove logic straight from the cleanup context function. Fixes: 38321256 ('IB/core: Add support for idr types') Signed-off-by:
-
Matan Barak authored
We rename the "write" flags to "exclusive", as it's used for both WRITE and DESTROY actions. Fixes: 38321256 ('IB/core: Add support for idr types') Signed-off-by:
-
- 17 Apr, 2017 15 commits
-
-
David S. Miller authored
Saeed Mahameed says: ==================== Mellanox, mlx5 RDMA net device support This series provides the lower level mlx5 support of RDMA netdevice creation API [1] suggested and introduced by Intel's HFI OPA VNIC netdevice driver [2], to enable IPoIB mlx5 RDMA netdevice creation. mlx5 IPoIB RDMA netdev will serve as an acceleration netdevice for the current IPoIB ULP generic netdevice, providing: - mlx5 RSS support. - mlx5 HW RX,TX offloads (checksum, TSO, LRO, etc ..). - Full mlx5 HW features transparent to the ULP itself. The idea here is to reuse and benefit from the already implemented mlx5e netdevice management and channels API for both etherent and RDMA netdevices, since both IPoIB and Ethernet netdevices share same common mlx5 HW resources (with some small exceptions) and share most of the control/data path logic, it is more natural to have them share the same code. The differences between IPoIB and Ethernet netdevices can be summarized to: Steering: In mlx5, IPoIB traffic is sent and received from an underlay special QP, and in Ethernet the traffic is handled by vports and vport steering is managed by e-switch or FW. For IPoIB traffic to get steered correctly the only thing we need to do is to create RSS HW contexts for RX and TX HW contexts for TX (similar to mlx5e) with the underlay QP attached to them (underlay QP will be 0 in case of Ethernet). RX,TX: Since IPoIB traffic is different, slightly modified RX and TX handlers are required, still we do some code reuse in data path via common helper functions. All of the other generic netdevice and mlx5 aspects will be shared between mlx5 Ethernet and IPoIB netdevices, e.g. - Channels creation and handling (RQs,SQs,CQs, NAPI, interrupt moderation, etc..) - Offloads, checksum, GRO, LRO, TSO, and more. - netdevice logic and non Ethernet specific ndos (open/close, etc..) In order to achieve what we want: In patchet 1 to 3, Erez added the supported for underlay QP in mlx5_ifc and refactored the mlx5 steering code to accept the underlay QP as a parameter for creating steering objects and enabled flow steering for IB link. Then we are going to use the mlx5e netdevice profile, which is already used to separate between NIC and VF representors netdevices, to create new type of IPoIB netdevice profile. For that, one small refactoring is required to make mlx5e netdevice profile management more genetic and agnostic to link type which is done in patch #4. In patch #5, we introduce ipoib.c to host all of mlx5 IPoIB (mlx5i) specific logic and a skeleton for the IPoIB mlx5 netdevice profile, and we will start filling it in next patches, using mlx5e already existing APIs. Patch #6 and #7, Implement init/cleanup RX mlx5i netdev profile handlers to create mlx5 RSS resources, same as mlx5e but without vlan and L2 steering tables. Patch #8, Implement init/cleanup TX mlx5i netdev profile handlers, to create TX resources same as mlx5e but with one TC (tc = 0) support. Patch #9, Implement mlx5i open/close ndos, where we reuese the mlx5e channels API, to start/stop TX/RX channels. Patch #10, Create the underlay QP and attach it to mlx5i RSS and TX HW contexts. Patch #11 and #12, Break down the mlx5e xmit flow into smaller helper function and implement the mlx5i IPoIB xmit routine. Patch #13 and #14, Have an RX handler per netdevice profile. We already do this before this series in a non clean way to separate between NIC netdev and VF representor RX handlers, in patch 13 we make the RX handler generic and bound to a profile and in patch 14 we implement the IPoIB RX handlers. Patch #15, Small cleanup to avoid e-switch with IPoIB netdev. In order to enable mlx5 IPoIB, a merge between the IPoIB RDMA netdev offolad support [3] - which was alread submitted to the rdma mailing list - and this series is required plus an extra small patch [4] which will connect between both sides and actually enables the offload. Once both patch-sets are merged into linux we will have to submit the extra small patch [4], to enable the feature. Thanks, Saeed. [1] https://patchwork.kernel.org/patch/9676637/ [2] https://lwn.net/Articles/715453/ https://patchwork.kernel.org/patch/9587815/ [3] https://patchwork.kernel.org/patch/9672069/ [4] https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/commit/?id=0141db6a686e32294dee015b7d07706162ba48d8 ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Erez Shitrit authored
Add check for bit IB_QP_CREATE_NETIF_QP while creating QP. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
Currently the driver support only ethernet eswitch, and we want to protect downstream IPoIB netdev from trying to access it in IB link. Signed-off-by:
-
Saeed Mahameed authored
Implement IPoIB RX SKB handler. Signed-off-by:
-
Saeed Mahameed authored
In order to have different RX handler per profile, fix and refactor the current code to take the rx handler directly from the netdevice profile rather than computing it on runtime as it was done with the switchdev mode representor rx handler. This will also remove the current wrong assumption in mlx5e_alloc_rq code that mlx5e_priv->ppriv is of the type vport_rep. Signed-off-by:
-
Saeed Mahameed authored
Implement mlx5e's IPoIB SKB transmit using the helper functions provided by mlx5e ethernet tx flow, the only difference in the code between mlx5e_xmit and mlx5i_xmit is that IPoIB has some extra fields to fill (UD datagram segment) in the TX descriptor (WQE) and it doesn't need to have any vlan handling. Signed-off-by:
-
Saeed Mahameed authored
Break current mlx5e xmit flow into smaller blocks (helper functions) in order to reuse them for IPoIB SKB transmission. Signed-off-by:
-
Saeed Mahameed authored
Create IPoIB underlay QP needed by the IPoIB netdevice profile for RSS and TX HW context to perform on IPoIB traffic. Reset the underlay QP on dev_uninit ndo to stop IPoIB traffic going through this QP when the ULP IPoIB decides to cleanup. Implement attach/detach mcast RDMA netdev callbacks for later RDMA netdev use. Signed-off-by:
-
Saeed Mahameed authored
Implement open/close of IPoIB netdevice ndos using mlx5e's channels API to manage data path resources (RQs/SQs/CQs). Set IPoIB netdev address on dev_init ndo. Signed-off-by:
-
Saeed Mahameed authored
Modify mlx5e tis creation function to accept underlay qp number, which will be needed by IPoIB. Implement mlx5i (IPoIB) tx init/cleanup netdevice profile flows to create one TIS with the IPoIB underlay qp, for IPoIB TX SQs. Signed-off-by:
-
Saeed Mahameed authored
Like the mlx5e ethernet mode, on IPoIB mode we need to create RX steering tables, but IPoIB do not require MAC and VLAN steering tables so the only tables we create in here are: 1. TTC Table (Traffic Type Classifier table for RSS steering) 2. ARFS Table (for accelerated RFS support) Creation of those tables is identical to mlx5e ethernet mode, hence the use of mlx5e_create_ttc_table and mlx5e_arfs_create_tables. Signed-off-by:
-
Saeed Mahameed authored
Implement IPoIB RX RSS (RQTs and TIRs) HW objects creation, All we do here is simply reuse the mlx5e implementation to create direct and indirect (RSS) steering HW objects. For that we just expose mlx5e_{create,destroy}_{direct,indirect}_{rqt,tir} functions into en.h and call them from ipoib.c in init/cleanup_rx IPoIB netdevice profile callbacks. Signed-off-by: -
Saeed Mahameed authored
Create mlx5e IPoIB netdevice profile skeleton in the new ipoib.c file with empty implementation. Downstream patches will provide the full mlx5 rdma netdevice acceleration support for IPoIB into this new file, by using the mlx5e netdevice profile and new mlx5_channels APIs and infrastructures. Same as already done in mlx5e NIC netdevice and switchdev mode VF representors. Signed-off-by:
-
Saeed Mahameed authored
In preparation for mlx5e RDMA net_device support, here we generalize mlx5e_attach/detach in a way that those functions will be agnostic to link type. For that we move ethernet specific NIC net device logic out of those functions into {nic,rep}_{enable/disable} mlx5e NIC and representor profiles callbacks. Also some of the logic was moved only to NIC profile since it is not right to have this logic for representor net device (e.g. set port MTU). Signed-off-by: -
Erez Shitrit authored
Get the relevant capabilities if supports ipoib_enhanced_offloads and init the flow steering table accordingly. Signed-off-by:
-
