Re: [PATCH rtw-next v3 3/3] wifi: rtl8xxxu: preserve RX requests across recoverable transfer errors

[Kim Wooseok]

Yes. I want to preserve normal RX replenishment once the batching
threshold is reached. The 100 ms delay is intended to limit retries
when normal progress is absent.

In the mixed-traffic test, normal progress brought the worker execution
forward to 18.773 ms after the retry was queued. I would let that refill
proceed instead of holding the available URBs for the remaining delay.

For repeated errors, I want to keep the first retry deadline rather
than restart the delay with each error. That is why I would keep
schedule_delayed_work() for errors and mod_delayed_work() for normal
completions.

Thanks,
Wooseok


On Mon, 21 Sep 2026 00:24:47 +0000, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> Kim Wooseok <5mghybrid@xxxxxxxxx> wrote:
> > > Not prefer using bare system_wq.
> > > Can both use schedule_delayed_work()?
> >
> > In v3, the error path uses queue_delayed_work(system_wq, ..., delay),
> > while normal completions use mod_delayed_work(system_wq, ..., 0).
> >
> > I can replace the error-path call with schedule_delayed_work().
> > However, the normal-completion path is intended to bring an existing
> > delayed retry forward when the pending count exceeds the batching
> > threshold, which schedule_delayed_work(..., 0) cannot do because it
> > leaves an already pending timer unchanged.
>
> I knew this point. Does it matter to schedule a normal case immediately
> after an error case (defer to schedule) happened within 100ms?
> (Just an open question)
>
> >
> > Would it be OK to retain mod_delayed_work() for normal completions,
> > changing its queue argument to system_percpu_wq?
>
> OK if above question is yes.
>
> Or both change to use mod_delayed_work()?
>
> >
> > With that change, schedule_delayed_work() would select system_percpu_wq
> > internally, and mod_delayed_work() would use the same queue explicitly.
> >