Re: [PATCH net-next v10 4/4] net: mana: add dynamic HWC queue depth with reinit path

[Wei Hu]

Thanks for the review.

> Which direction does the PF mean by HWC_INIT_DATA_MAX_REQUEST?

The driver uses MAX_REQUEST for the RQ and MAX_RESPONSE for the SQ, and
the host-to-PF request budget follows the SQ. That allocation convention
already exists in mana_hwc_init_queues(). The new mapping is also stated
explicitly in mana_hwc_finish_channel() and the request-budget helper.

I agree that the names alone are not sufficient protocol documentation.
However, the suggested opposite interpretation is not established by the
review either. A protocol reference defining the PF's directional meaning
would be needed before concluding that these limits are reversed.

I plan to preserve the mapping, not swap the fields or impose the minimum
of both directions on that assumption. The latter could reject valid
asymmetric traffic. I will clarify the existing RQ/SQ convention in the
description without claiming a new firmware guarantee.

> How does the PF learn the ring sizes of the rebuilt channel?

The PF specifies the HWC queue depth and corresponding ring sizes. It
reports the required depth via HWC_INIT_DATA_QUEUE_DEPTH, and the VF
rebuilds the rings to implement that PF requirement.

The PF therefore already knows the required geometry; the absence of size
fields in ESTABLISH_HWC does not mean that it must keep assuming bootstrap
sizes. I plan to keep the sizing protocol unchanged and make this PF-driven
contract explicit in the description.

> Can a PF that leaves out any of these HWC_INIT_DATA types, or reports 0,
> still bring up the HWC? It looks like HWC creation now fails with -EPROTO
> even in the depth-1 setup that used to work, with no fallback.

The new nonzero-report validation does apply before the decision to keep
the bootstrap queues, and to the restored bootstrap report. I will
document that behavior and its -EPROTO result explicitly in the message.

That documentation omission is a small follow-up. It does not establish
that absent or zero maxima are valid PF reports. I will not add a fallback
to guessed limits without that contract.

> This isn't a bug in the new code, but this check fixes an existing
> out-of-bounds MMIO write, together with the INVALID_DOORBELL early return
> added to mana_gd_ring_doorbell().

Agreed that this also hardens a baseline path. I checked the original
driver's unchecked doorbell assignment and MMIO address calculation. I
will make the existing bug and applicable Fixes lineage explicit for
dependency-aware backports. This is a metadata clarification, not another
MMIO behavior change or a wholesale split of the feature series.

Regards,
Wei