> >> >> 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).
> >> >> 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.
> > 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
> 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
> uses more resources and one that uses less).
Sounds like the user should chose 1 combined in 1 rx in this scenario.