On Wed, 12 Jun 2019 at 22:24, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > > On Wed, 12 Jun 2019 15:56:48 +0000, Maxim Mikityanskiy wrote: > > Currently, libbpf uses the number of combined channels as the maximum > > queue number. However, the kernel has a different limitation: > > > > - xdp_reg_umem_at_qid() allows up to max(RX queues, TX queues). > > > > - ethtool_set_channels() checks for UMEMs in queues up to > > combined_count + max(rx_count, tx_count). > > > > libbpf shouldn't limit applications to a lower max queue number. Account > > for non-combined RX and TX channels when calculating the max queue > > number. Use the same formula that is used in ethtool. > > > > Signed-off-by: Maxim Mikityanskiy <maxi...@mellanox.com> > > Reviewed-by: Tariq Toukan <tar...@mellanox.com> > > Acked-by: Saeed Mahameed <sae...@mellanox.com> > > I don't think this is correct. max_tx tells you how many TX channels > there can be, you can't add that to combined. Correct calculations is: > > max_num_chans = max(max_combined, max(max_rx, max_tx)) >
...but the inner max should be min, right? Assuming we'd like to receive and send.
