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