On Thu, 11 Dec 2025 01:39:25 +0000 Pavel Begunkov wrote:
> On 12/2/25 18:58, Jakub Kicinski wrote:
> > On Sun, 30 Nov 2025 23:35:22 +0000 Pavel Begunkov wrote:
> >> +static ssize_t bnxt_get_rx_buf_size(struct bnxt *bp, int rxq_idx)
> >> +{
> >> + struct netdev_rx_queue *rxq = __netif_get_rx_queue(bp->dev, rxq_idx);
> >> + size_t rx_buf_size;
> >> +
> >> + rx_buf_size = rxq->mp_params.rx_buf_len;
> >> + if (!rx_buf_size)
> >> + return BNXT_RX_PAGE_SIZE;
> >
> > I'd like to retain my cfg objects in the queue API, if you don't mind.
> > I guess we just need the way for drivers to fill in the defaults and
> > then plumb them into the ops.
>
> It was problematic, I wanted to split it into more digestible chunks.
> My main problem is that it was not really optional and could break
> drivers that don't even care about this qcfg len option but allow
> setting it device-wise via ethtool, and I won't even have a way to
> test them.
>
> Maybe there is a way to strip down qcfg and only apply it to marked
> queue api enabled drivers for now, and then extend the idea it in
> the future. E.g.
Yes, I mean a stripped down version, since we're not shadowing the
ethtool knob any more the full set of changes I had will be too much.
Off the top of my head I think we'd need to retain:
- the qcfg struct passed as an argument to the queue callbacks
(drivers other than bnxt won't use it which is okay since they don't
set .supported_params)
- the ability to conjure the qcfg struct for any given queue by the
driver at any time (netdev_queue_config())
- probably the callback to fill in the defaults so that the driver
doesn't have to check "is the value set by the user" explicitly
