The MANA Hardware Channel (HWC) is the control path the driver uses to
talk to the device.  It is created at a fixed depth of one outstanding
request, so every management command serialises behind the previous one.
This series lets several commands be in flight and raises the queue depth
to what the device reports.

Patches 1-2 are preparation and change no behaviour on their own.  Patch 1
records whether mana_smc_setup_hwc() got as far as handing the queue
addresses to the PF, which the reinit path in patch 4 needs in order to
know whether the device may still be using the queues.  Patch 2 gives each
message slot its own lock, refcount and completion state, which is what
makes more than one slot usable at a time.

Patch 3 makes the channel actually concurrent: a per-queue lock around
mana_gd_post_and_ring(), a bounded wait for a free slot, and a teardown
that drains in-flight senders before freeing the HWC.

Patch 4 bootstraps the HWC at depth 1, queries the device maximum and, if
it is larger, tears the queues down and rebuilds them at that depth.  The
device-reported dimensions are validated before they size DMA allocations,
and the dynamic-depth capability is advertised so firmware enables it only
for drivers that support it.

None of the four carries a Fixes: tag; the bug fixes that used to be part
of this series are being handled separately (see below).

Changes since v2:

 - Split the series.  v2 mixed five Fixes:-tagged bug fixes with the two
   feature patches and targeted net-next.  Per review feedback [1] the
   fixes now go via the net tree on their own, and this series carries
   only the feature work.  It no longer depends on that series: it
   applies to net-next as it stands today.

 - Because the fixes are no longer in front of them, the two feature
   patches were reworked rather than rebased.  The groundwork they used
   to inherit is now provided by the two preparation patches 1-2, which
   are deliberately not fixes and carry no Fixes: tag.

 - patch 3: the slot admission was reworked.  Acquisition uses
   down_timeout() so a caller expires rather than blocking on a slot
   that a timed-out request is still holding, and channel_up is
   re-checked under the bitmap lock once a permit is held so teardown
   cannot be missed.

 - patch 3: a slot whose request timed out is no longer released back to
   the pool -- only the matching response, or teardown, reclaims it.
   Releasing it early let a late response land on whichever command had
   since reused the slot.  mlx5 gates its command slots the same way
   ("only real completion can free the cmd slot", drivers/net/ethernet/
   mellanox/mlx5/core/cmd.c).

 - patch 4: validate the device-reported dimensions before they size DMA
   allocations -- require the negotiated message sizes to match the
   bootstrap ones, bound the depth by HW_CHANNEL_MAX_QUEUE_DEPTH, check
   that q_depth * max_msg_size plus alignment fits in u32, and carry the
   depth as u32 since the device field is 24-bit and truncating to u16
   could wrap a large value to a small depth.

 - patch 4: refuse the channel if the initialisation handshake did not
   supply a doorbell, rather than letting INVALID_DOORBELL reach
   mana_gd_ring_doorbell().

 - patch 4: a device that refuses the larger-depth establish now falls
   back to a working bootstrap channel instead of failing probe, but
   only once a retried DESTROY_HWC has confirmed the queue mappings are
   gone.

Testing on Azure hardware, with the series applied on net-next:

 - 17518 HWC commands, all completing successfully, with up to 2 in
   flight at once (the bootstrap channel can only ever have 1).
 - PCI remove/rescan x3: the reinit path runs every time, and the
   channel comes back at the larger depth.
 - iperf3 -P16: 1.24 TBytes at 182 Gbit/s, no taint and no splats.
 - Fault injection: with every HWC response dropped so that all slots
   end up held by timed-out requests, callers return -ETIMEDOUT in
   sub-millisecond time instead of blocking, no hung tasks, and the
   driver recovers once responses resume.

[1] https://lore.kernel.org/all/[email protected]/

 - v2: 
https://lore.kernel.org/all/[email protected]/
 - v1: 
https://lore.kernel.org/netdev/[email protected]/

Long Li (4):
  net: mana: track when the HWC has been handed to the PF
  net: mana: give each HWC message slot its own completion state
  net: mana: support concurrent HWC requests
  net: mana: add dynamic HWC queue depth with reinit path

 .../net/ethernet/microsoft/mana/gdma_main.c   |  63 +-
 .../net/ethernet/microsoft/mana/hw_channel.c  | 763 ++++++++++++++++--
 .../net/ethernet/microsoft/mana/shm_channel.c |  11 +-
 include/net/mana/gdma.h                       |  19 +
 include/net/mana/hw_channel.h                 |  64 +-
 include/net/mana/shm_channel.h                |   2 +-
 6 files changed, 862 insertions(+), 60 deletions(-)


base-commit: 1bb784eb6e38fd73143f021608e4ef3095d0c0d7
-- 
2.43.0


Reply via email to