- 13 Dec, 2016 10 commits
-
-
Moses Reuben authored
Add ib_uverbs_flow_spec_tunnel to define the rule to match Vxlan, the type, size, reserved fields are identical to rest of the protocols, and are used to identify the spec. The tunnel id is the vni value of the Vxlan protocol, and it is used as part of the steering rule, it is limited by the mask. The steering rule configured on the hardware does a match according to vni and other protocols. In the same way as rest of the protocols that we match, the uniq field's of each protocol are represented on the val and the mask. Signed-off-by:
Moses Reuben <mosesr@mellanox.com> Reviewed-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com>
-
Moses Reuben authored
Aligned the structure ib_flow_spec_type indentation, after adding a new definition. Signed-off-by:
-
Moses Reuben authored
In order to support tunneling, that can be used by the QP, both struct ib_flow_spec_tunnel and struct ib_flow_tunnel_filter can be used to more IP or UDP based tunneling protocols (e.g NVGRE, GRE, etc). IB_FLOW_SPEC_VXLAN_TUNNEL type flow specification is added to use this functionality and match specific Vxlan packets. In similar to IPv6, we check overflow of the vni value by comparing with the maximum size. Signed-off-by:
-
Bodong Wang authored
CQE compressing reduces PCI overhead by coalescing and compressing multiple CQEs into a single merged CQE. Successful compressing improves message rate especially for small packet traffic. CQE compressing is supported for all 64B CQE formats (with certain limitations) generated by RQ/Responder or by SQ/Requestor. Signed-off-by:
Bodong Wang <bodong@mellanox.com> Reviewed-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Bodong Wang authored
The capabilities include: - Max number of compressed and aggregated CQEs in a single session, while zero means unsupported. - For Responder, there are two formats of mini CQE: mini CQE with Rx hash and mini CQE with checksum. They're mutual exclusive. Signed-off-by:
-
Bodong Wang authored
The capabilities whether hardware support multi packet WQE or not is exposed to user space through query_device by uhw. Signed-off-by:
-
Leon Romanovsky authored
Multi packet WQE enables sending multiple fix sized packets using a single WQE. The exposed field reports such HW support. Signed-off-by:
-
Yonatan Cohen authored
Increase limit of max CQE from 8K to 32K to allow demanding applications to work over SoftRoCE with same configuration as most RoCEv2 HW vendors have. Fixes: 8700e3e7 ("Soft RoCE driver") Signed-off-by:
Yonatan Cohen <yonatanc@mellanox.com> Reviewed-by:
Moni Shoua <monis@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
Before reading GRH attributes, need to make sure AH contains GRH, and in addition, initialize GID type. Fixes: dbf727de ('IB/core: Use GID table in AH creation and dmac resolution') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
-
Eran Ben Elisha authored
According to the firmware spec, FLOW_STEERING_IB_UC_QP_RANGE command is supported only if dmfs_ipoib bit is set. If it isn't set we want to ensure allocating NET_IF QPs fail. We do so by filling out the allocation bitmap. By thus, the NET_IF QPs allocating function won't find any free QP and will fail. Fixes: c1c98501 ('IB/mlx4: Add support for steerable IB UD QPs') Signed-off-by:
-
- 17 Nov, 2016 13 commits
-
-
Saeed Mahameed authored
Report the correct speed in the port attributes when using a 56Gbps ethernet link. Without this change the field is incorrectly set to 10. Fixes: a9c766bb ('IB/mlx4: Fix info returned when querying IBoE ports') Fixes: 2e96691c ('IB: Use central enum for speed instead of hard-coded values') Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
-
Maor Gottlieb authored
Use INT_MAX since this is the max value the attribute can hold, though hardware capability is unlimited. Fixes: 225c7b1f ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Jack Morgenstein authored
If OpenSM runs over a ConnectX-3, and there are ConnectX-4 or Connect-IB VFs active on the network, the OpenSM will receive QP1 packets containing a GRH where the destination GID is the "Well-Known GID" -- which is not a GID in the HCA Port's GID Table. This GID must be tested-for separately -- and packets which contain this destination GID should be routed to slave 0 (the PF). Fixes: 37bfc7c1 ('IB/mlx4: SR-IOV multiplex and demultiplex MADs') Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Moni Shoua authored
When MAD arrives to the hypervisor, we need to identify which slave it should be sent by destination GID. When L3 protocol is IPv4 the GRH is replaced by an IPv4 header. This patch detects when IPv4 header needs to be parsed instead of GRH. Fixes: b6ffaeff ('mlx4: In RoCE allow guests to have multiple GIDS') Signed-off-by:
-
Maor Gottlieb authored
Set traffic class within sl_tclass_flowlabel when create iboe AH. Without this the TOS value will be empty when running VLAN tagged traffic, because the TOS value is taken from the traffic class in the address handle attributes. Fixes: 9106c410 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE') Signed-off-by:
-
Kamal Heib authored
Remove the warning print of "can't use of GFP_NOIO" to avoid prints in each QP creation when devices aren't supporting IB_QP_CREATE_USE_GFP_NOIO. This print become more annoying when the IPoIB interface is configured to work in connected mode. Fixes: 09b93088 ('IB: Add a QP creation flag to use GFP_NOIO allocations') Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Majd Dibbiny authored
The maximum page size in the mkey context is 2GB. Until today, we didn't enforce this requirement in the code, and therefore, if we got a page size larger than 2GB, we have passed zeros in the log_page_shift instead of the actual value and the registration failed. This patch limits the driver to use compound pages of 2GB for mkeys. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Majd Dibbiny <majd@mellanox.com> Signed-off-by:
-
Eli Cohen authored
Add the 512 bytes limit of RDMA READ and the size of remote address to the max SGE calculation. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Eli Cohen authored
Wait before continuing unload till all pending mkey async creation requests are done. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Maor Gottlieb authored
We put INT_MAX since this is the max value that can be held. Though there is no hardware limitation, this is practically a large enough number so we can use it. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Maor Gottlieb authored
Remove from the driver the limitation imposed by firmware check to not allow change of atomic permissions for indirect UMRs. In order to avoid failures on old firmware, we only ask for change of atomic permissions if atomic operations are supported. Fixes: 968e78dd ('IB/mlx5: Enhance UMR support to allow partial page table update') Signed-off-by:
-
Max Gurtovoy authored
Replace the pre-defined macro signifying inline umr instead of the numerical constant. Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
-
Mark Bloch authored
When we create flow steering rule, we need to save the related QP in the ib_flow struct. this QP is used in destroy flow. Move the QP assignment from ib_uverbs_ex_create_flow into ib_create_flow, this would allow both kernel and userspace consumers to use it. This bug wasn't seen in the wild because there are no kernel consumers currently in the kernel. Fixes: 319a441d ("IB/core: Add receive flow steering support") Signed-off-by:
-
- 30 Oct, 2016 15 commits
-
-
Mark Bloch authored
When creating a FWD rule using tc create also a HW counter for this rule. Signed-off-by:
-
Mark Bloch authored
Currently the code supports only drop rules to possess counters, add that ability also for fwd rules. Signed-off-by:
-
Mark Bloch authored
Currently when calling mlx5_add_flow_rule we accept only one flow destination, this commit allows to pass multiple destinations. This change forces us to change the return structure to a more flexible one. We introduce a flow handle (struct mlx5_flow_handle), it holds internally the number for rules created and holds an array where each cell points the to a flow rule. From the consumers (of mlx5_add_flow_rule) point of view this change is only cosmetic and requires only to change the type of the returned value they store. From the core point of view, we now need to use a loop when allocating and deleting rules (e.g given to us a flow handler). Signed-off-by:
-
Mark Bloch authored
When adding a new rule, if we can match it with compare_match_value and flow tag we might be able to insert the rule to the same fte. In order to do that, there must be an overlap between the actions of the fte and the new rule. When updating the action of an existing fte, we must tell the firmware we are doing so. Signed-off-by:
-
Mark Bloch authored
The way we compare between two dests will need to be used in other places in the future, so we factor out the comparison logic between two dests into a separate function. Signed-off-by:
-
Mark Bloch authored
An fte status becomes FS_FTE_STATUS_EXISTING only after it was created in HW. We can use this in order to simplify the logic on what firmware command to use. If the status isn't FS_FTE_STATUS_EXISTING we need to create the fte, otherwise we need only to update it. Signed-off-by:
-
Mark Bloch authored
When adding a new rule to an fte, we need to hold the fte lock until we add that rule to the fte and increase the fte ref count. Fixes: 0c56b975 ("net/mlx5_core: Introduce flow steering API") Signed-off-by:
-
Mohamad Haj Yahia authored
Implement the vf set rate ndo by modifying the TSAR vport rate limit. Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
-
Mohamad Haj Yahia authored
Add TSAR to the eswitch which will act as the vports rate limiter. Create/Destroy TSAR on Enable/Dsiable SRIOV. Attach/Detach vport to eswitch TSAR on Enable/Disable vport. Signed-off-by:
-
Mohamad Haj Yahia authored
TSAR (stands for Transmit Scheduling ARbiter) is a hardware component that is responsible for selecting the next entity to serve on the transmit path. The arbitration defines the QoS policy between the agents connected to the TSAR. The TSAR is a consist two main features: 1) BW Allocation between agents: The TSAR implements a defecit weighted round robin between the agents. Each agent attached to the TSAR is assigned with a weight and it is awarded transmission tokens according to this weight. 2) Rate limer per agent: Each agent attached to the TSAR is (optionally) assigned with a rate limit. TSAR will not allow scheduling for an agent exceeding its defined rate limit. In this patch we implement the API of manipulating the TSAR. Signed-off-by:
-
Saeed Mahameed authored
For the mlx5 driver to support ConnectX-5 PCIe 4.0 VFs, we add the device ID "0x101a" to mlx5_core_pci_table. Signed-off-by:
-
Eugenia Emantayev authored
According to PRM async_event_mask have to be 64 bits long. Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Artemy Kovalyov authored
SRQ physical address structure field should be in big-endian format. Signed-off-by:
Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Artemy Kovalyov authored
Update struct mlx5_ifc_xrqc_bits according to last specification Signed-off-by:
-
Saeed Mahameed authored
Do not dispatch unknown mlx5 core events on mlx5_ib_event. Signed-off-by:
-
- 29 Oct, 2016 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 bugfix from Thomas Gleixner: "A single bugfix for the recent changes related to registering the boot cpu when this has not happened before prefill_possible_map(). The main problem with this change got fixed already, but we missed the case where the local APIC is not yet mapped, when prefill_possible_map() is invoked, so the registration of the boot cpu which has the APIC bit set in CPUID will explode. I should have seen that issue earlier, but all I can do now is feeling embarassed" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/smpboot: Init apic mapping before usage
-
