On Thu, 13 Jun 2019 14:41:30 +0200, Björn Töpel wrote: > On Wed, 12 Jun 2019 at 22:24, Jakub Kicinski > <jakub.kicinski@xxxxxxxxxxxxx> 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 <maximmi@xxxxxxxxxxxx> > > > Reviewed-by: Tariq Toukan <tariqt@xxxxxxxxxxxx> > > > Acked-by: Saeed Mahameed <saeedm@xxxxxxxxxxxx> > > > > 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. That was my knee jerk reaction too, but I think this is only use to size the array (I could be wrong). In which case we need an index for unidirectional socks, too. Perhaps the helper could be named better if my understanding is correct :(
