On Wed, Oct 07, 2026 at 08:23:50AM +0200, Paul de Weerd wrote:
>
> I understand your point, but seems to me that there should be a limit
> to the number of packets to queue. At this point in time I see:
>
> 08:14:49 aq0:0:txq:0 packets: 69748 packets
> 08:14:49 aq0:0:txq:1 packets: 3363 packets
> 08:14:49 aq0:0:txq:2 packets: 35566 packets
> 08:14:49 aq0:0:txq:3 packets: 2335 packets
> 08:14:49 aq0:0:txq:4 packets: 1754 packets
> 08:14:49 aq0:0:txq:5 packets: 4051 packets
> 08:14:49 aq0:0:txq:6 packets: 7631 packets
> 08:14:49 aq0:0:txq:7 packets: 1558 packets
>
> total packets: 126006. That's more than 8x 2048.
>
> free = tx->tx_cons + AQ_TXD_NUM - tx->tx_prod
>
> Both tx_cons and tx_prod are in [0..2047], so if tx_prod has wrapped
> but tx_cons hasn't yet (likely in the case where you're producing
> packets but never consuming them because the link is down) suddenly
> theres 2048 extra slots?
>
> Then this happens later on:
>
> if (used + AQ_TX_MAX_SEGMENTS + 1 >= free) {
> ifq_set_oactive(ifq);
> break;
> }
>
> But that condition isn't going to be true if free is more than 2048
> because of the previous bit, right?
>
> (caveat - i don't really know what i'm doing here, just trying to
> follow the code but i'm not really good at this stuff)
ah. "packets" in the txq kstats is a counter. it's the number of packets
that went through that transmit queue.
the current number of packets being held by the txq is the "qlen" gauge.
the maximum number of packets a txq will hold onto is shown by the
"maxqlen" gauge. for everyone elses benefit, this is what the whole set
of kvs in the txq kstat looks like:
aq0:0:txq:0
packets: 0 packets
bytes: 0 bytes
qdrops: 0 packets
errors: 0 packets
qlen: 0 packets
maxqlen: 2048 packets
oactive: false
oactives: 0
