On Mon, Sep 19, 2016 at 2:21 AM, Mintz, Yuval <yuval.mi...@cavium.com> wrote: >> >> 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 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).
