talos-op-linux/include/linux/mlx5/driver.h, branch v4.12

net/mlx5: Avoid using pending command interface slots

2017-05-23T13:23:31+00:00

Currently when firmware command gets stuck or it takes long time to complete, the driver command will get timeout and the command slot is freed and can be used for new commands, and if the firmware receive new command on the old busy slot its behavior is unexpected and this could be harmful. To fix this when the driver command gets timeout we return failure, but we don't free the command slot and we wait for the firmware to explicitly respond to that command. Once all the entries are busy we will stop processing new firmware commands. Fixes: 9cba4ebcf374 ('net/mlx5: Fix potential deadlock in command mode change') Signed-off-by: Mohamad Haj Yahia Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed

Merge tags 'for-linus' and 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

2017-05-09T03:07:29+00:00

Pull more rdma updates from Doug Ledford: "As mentioned in my first pull request, this is the subsequent pull requests I had. This is all I have, and in fact this cleans out the RDMA subsystem's entire patchworks queue of kernel changes that are ready to go (well, it did for the weekend anyway, a few new patches are in, but they'll be coming during the -rc cycle). The first tag contains a single patch that would have conflicted if taken from my tree or DaveM's tree as it needed our trees merged to come cleanly. The second tag contains the patch series from Intel plus three other stragllers that came in late last week. I took them because it allowed me to legitimately claim that the RDMA patchworks queue was, for a short time, 100% cleared of all waiting kernel patches, woohoo! :-). I have it under my for-next tag, so it did get 0day and linux- next over the end of last week, and linux-next did show one minor conflict. Summary: 'for-linus' tag: - mlx5/IPoIB fixup patch 'for-next' tag: - the hfi1 15 patch set that landed late - IPoIB get_link_ksettings which landed late because I asked for a respin - one late rxe change - one -rc worthy fix that's in early" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/mlx5: Enable IPoIB acceleration * tag 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: rxe: expose num_possible_cpus() cnum_comp_vectors IB/rxe: Update caller's CRC for RXE_MEM_TYPE_DMA memory type IB/hfi1: Clean up on context initialization failure IB/hfi1: Fix an assign/ordering issue with shared context IDs IB/hfi1: Clean up context initialization IB/hfi1: Correctly clear the pkey IB/hfi1: Search shared contexts on the opened device, not all devices IB/hfi1: Remove atomic operations for SDMA_REQ_HAVE_AHG bit IB/hfi1: Use filedata rather than filepointer IB/hfi1: Name function prototype parameters IB/hfi1: Fix a subcontext memory leak IB/hfi1: Return an error on memory allocation failure IB/hfi1: Adjust default eager_buffer_size to 8MB IB/hfi1: Get rid of divide when setting the tx request header IB/hfi1: Fix yield logic in send engine IB/hfi1, IB/rdmavt: Move r_adefered to r_lock cache line IB/hfi1: Fix checks for Offline transient state IB/ipoib: add get_link_ksettings in ethtool

treewide: use kv[mz]alloc* rather than opencoded variants

2017-05-09T00:15:13+00:00

There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation requests <= 32kB (with 4kB pages) are basically never failing and invoke OOM killer to satisfy the allocation. This sounds too disruptive for something that has a reasonable fallback - the vmalloc. On the other hand those requests might fallback to vmalloc even when the memory allocator would succeed after several more reclaim/compaction attempts previously. There is no guarantee something like that happens though. This patch converts many of those places to kv[mz]alloc* helpers because they are more conservative. Link: http://lkml.kernel.org/r/20170306103327.2766-2-mhocko@kernel.org Signed-off-by: Michal Hocko Reviewed-by: Boris Ostrovsky # Xen bits Acked-by: Kees Cook Acked-by: Vlastimil Babka Acked-by: Andreas Dilger # Lustre Acked-by: Christian Borntraeger # KVM/s390 Acked-by: Dan Williams # nvdim Acked-by: David Sterba # btrfs Acked-by: Ilya Dryomov # Ceph Acked-by: Tariq Toukan # mlx4 Acked-by: Leon Romanovsky # mlx5 Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Herbert Xu Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: "Rafael J. Wysocki" Cc: Ben Skeggs Cc: Kent Overstreet Cc: Santosh Raspatur Cc: Hariprasad S Cc: Yishai Hadas Cc: Oleg Drokin Cc: "Yan, Zheng" Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Eric Dumazet Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

IB/mlx5: Enable IPoIB acceleration

2017-05-04T20:22:08+00:00

Enable mlx5 IPoIB acceleration by declaring mlx5_ib_{alloc,free}_rdma_netdev and assigning the mlx5 IPoIB rdma_netdev callbacks. In addition, this patch brings in sync mlx5's IPoIB parts for net and IB trees. As a precaution, we disabled IPoIB acceleration by default (in the mlx5_core Kconfig file). Signed-off-by: Saeed Mahameed Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford

net/mlx5e: Update neighbour 'used' state using HW flow rules counters

2017-04-30T13:03:14+00:00

When IP tunnel encapsulation rules are offloaded, the kernel can't see the traffic of the offloaded flow. The neighbour for the IP tunnel destination of the offloaded flow can mistakenly become STALE and deleted by the kernel since its 'used' value wasn't changed. To make sure that a neighbour which is used by the HW won't become STALE, we proactively update the neighbour 'used' value every DELAY_PROBE_TIME period, when packets were matched and counted by the HW for one of the tunnel encap flows related to this neighbour. The periodic task that updates the used neighbours is scheduled when a tunnel encap rule is successfully offloaded into HW and keeps re-scheduling itself as long as the representor's neighbours list isn't empty. Add, remove, lookup and status change operations done over the representor's neighbours list or the neighbour hash entry encaps list are all serialized by RTNL lock. Signed-off-by: Hadar Hen Zion Reviewed-by: Or Gerlitz Signed-off-by: Saeed Mahameed

net/mlx5e: Single bfreg (UAR) for all mlx5e SQs and netdevs

2017-03-25T02:11:45+00:00

One is sufficient since Blue Flame is not supported anymore. This will also come in handy for switchdev mode to save resources, since VF representors will use same single UAR as well for their own SQs. Signed-off-by: Saeed Mahameed Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

2017-02-23T19:27:49+00:00

Pull Mellanox rdma updates from Doug Ledford: "Mellanox specific updates for 4.11 merge window Because the Mellanox code required being based on a net-next tree, I keept it separate from the remainder of the RDMA stack submission that is based on 4.10-rc3. This branch contains: - Various mlx4 and mlx5 fixes and minor changes - Support for adding a tag match rule to flow specs - Support for cvlan offload operation for raw ethernet QPs - A change to the core IB code to recognize raw eth capabilities and enumerate them (touches non-Mellanox code) - Implicit On-Demand Paging memory registration support" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (40 commits) IB/mlx5: Fix configuration of port capabilities IB/mlx4: Take source GID by index from HW GID table IB/mlx5: Fix blue flame buffer size calculation IB/mlx4: Remove unused variable from function declaration IB: Query ports via the core instead of direct into the driver IB: Add protocol for USNIC IB/mlx4: Support raw packet protocol IB/mlx5: Support raw packet protocol IB/core: Add raw packet protocol IB/mlx5: Add implicit MR support IB/mlx5: Expose MR cache for mlx5_ib IB/mlx5: Add null_mkey access IB/umem: Indicate that process is being terminated IB/umem: Update on demand page (ODP) support IB/core: Add implicit MR flag IB/mlx5: Support creation of a WQ with scatter FCS offload IB/mlx5: Enable QP creation with cvlan offload IB/mlx5: Enable WQ creation and modification with cvlan offload IB/mlx5: Expose vlan offloads capabilities IB/uverbs: Enable QP creation with cvlan offload ...

IB/mlx5: Add implicit MR support

2017-02-14T16:41:19+00:00

Add implicit MR, covering entire user address space. The MR is implemented as an indirect KSM MR consisting of 1GB direct MRs. Pages and direct MRs are added/removed to MR by ODP. Signed-off-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford

IB/mlx5: Expose MR cache for mlx5_ib

2017-02-14T16:41:18+00:00

Allow other parts of mlx5_ib to use MR cache mechanism. * Add new functions mlx5_mr_cache_alloc and mlx5_mr_cache_free * Traditional MTT MKey buckets are limited by MAX_UMR_CACHE_ENTRY Additinal buckets may be added above. Signed-off-by: Artemy Kovalyov Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford

IB/mlx5: Add additional checks before processing MADs

2017-02-14T15:14:25+00:00

Check the has_smi bit in vport context and class version of MADs before allowing MADs processing to take place. MAD_IFC SMI commands can be executed only if smi bit is set. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Maor Gottlieb Signed-off-by: Parvi Kaustubhi Reviewed-by: Eli Cohen Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford