RE: [PATCH net-next 05/10] bnxt_en: Fix ethtool -l|-L inconsistent channel counts.

quoted

quoted

quoted

quoted

The existing code is inconsistent in reporting and accepting the
combined channel count.  bnxt_get_channels() reports maximum
combined as the maximum rx count.  bnxt_set_channels() accepts
combined count that cannot be bigger than max rx or max tx.

For example, if max rx = 2 and max tx = 1, we report max supported
combined to be 2.  But if the user tries to set combined to 2, it
will fail because 2 is bigger than max tx which is 1.

Fix the code to be consistent.  Max allowed combined = max(max_rx,

max_tx).

quoted

quoted

We will accept a combined channel count <= max(max_rx, max_tx).

Don't you mean the 'max allowed combined = min(max_rx, max_tx)'.
How does using 'max' change the faulty scenario you've described?

I'm fixing the inconsistency described in the first 2 paragraphs.
The driver logic allows a combined ring to be rx or tx only.  In the
above example, we allow combined to be set to 2.  The 2nd combined ring

supports rx only.

quoted

Then what makes it a combined channel?
Sounds to me like in the above scenario you should have claimed support for:
  - max rx == 2
  - max tx == 1
  - max combined == 1

Our implementation will report:

max rx 2
max tx 1
max combined 2

If the user chooses 2 rx and 1 tx, he will use 3 msix vectors (3 completion rings,
etc).  If the user chooses 2 combined (1 with rx/tx,
1 with rx only), he will use 2 msix vectors (2 completion rings, etc).
With a large number of NPAR functions and SRIOV functions, the number of
rings available per function may not be symmetrical.  We just want maximum
flexibility to make use of all available resources in 2 different modes (one that
uses more resources and one that uses less).

Sounds like the user should chose 1 combined in 1 rx in this scenario.