SVNews r318534

NOTE: This service is experimental and subject to change! Use at your own risk!

2017-05-19 12:42:33 - r318534 by hselasky (Hans Petter Selasky)

Complete list of files affected by revision r318534:

(Note: At the moment, these links point to ViewVC on They are probably slow. Do not overuse.)

   Contents     MODIFY   /stable/9/sys  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/drivers/net/mlx4/fw.c  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/drivers/net/mlx4/fw.h  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/drivers/net/mlx4/main.c  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/drivers/net/mlx4/qp.c  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/drivers/net/mlx4/resource_tracker.c  
  History   Contents   Diff   MODIFY   /stable/9/sys/ofed/include/linux/mlx4/device.h  

Commit message:

MFC r313556:
Change mlx4 QP allocation scheme.

When using Blue-Flame, BF, the QPN overrides the VLAN, CV, and SV
fields in the WQE. Thus, BF may only be used for QPNs with bits 6,7

The current ethernet driver code reserves a TX QP range with 256b

This is wrong because if there are more than 64 TX QPs in use, QPNs >=
base + 65 will have bits 6/7 set.

This problem is not specific for the Ethernet driver, any entity that
tries to reserve more than 64 BF-enabled QPs should fail. Also, using
ranges is not necessary here and is wasteful.

The new mechanism introduced here will support reservation for "Eth
QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
(when hypervisors support WC in VMs). The flow we use is:

1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
  and request "BF enabled QPs" if BF is supported for the function

2. In the ALLOC_RES FW command, change param1 to:
a. param1[23:0] - number of QPs
b. param1[31-24] - flags controlling QPs reservation

Bit 31 refers to Eth blueflame supported QPs. Those QPs must have bits
6 and 7 unset in order to be used in Ethernet.

Bits 24-30 of the flags are currently reserved.

When a function tries to allocate a QP, it states the required
attributes for this QP. Those attributes are considered "best-effort".
If an attribute, such as Ethernet BF enabled QP, is a must-have
attribute, the function has to check that attribute is supported
before trying to do the allocation.

In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
which are unsupported. If SRIOV is used, the PF validates those
attributes and masks out unsupported attributes as well. In order to
notify VFs which attributes are supported, the VF uses QUERY_FUNC_CAP
command. This command's mailbox is filled by the PF, which notifies
which QP allocation attributes it supports.

Obtained from: Linux (dual BSD/GPLv2 licensed)
Submitted by: Dexuan Cui @ microsoft . com
Differential Revision:
Sponsored by: Mellanox Technologies


Powered by Python FreeBSD support by secnetix GmbH & Co. KG

Page generated in 19 ms, 7 files printed. Current time is 2017-05-28 04:52:28. All times are in UTC/GMT.