The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: "luka.gejak@linux.dev" <luka.gejak@linux.dev>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Michael Straube" <straube.linux@gmail.com>,
	Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	Peter Robinson <pbrobinson@gmail.com>,
	"Hans de Goede" <johannes.goede@oss.qualcomm.com>
Subject: RE: [PATCH v7 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation
Date: Tue, 25 Aug 2026 06:36:30 +0000	[thread overview]
Message-ID: <348bea609cee45179ee2a0c7dd03f0d1@realtek.com> (raw)
In-Reply-To: <20260820090412.19574-7-luka.gejak@linux.dev>

luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:

[...]

> +/*
> + * Back-pressure on the data ACs (BK/BE/VI/VO): once the software FIFO fills
> + * past the high watermark, stop the corresponding mac80211 queue so it stops
> + * handing frames down, which bounds the queueing latency. The queue is woken
> + * again from the TX drain path once the FIFO falls back to the low watermark.
> + */
> +static void rtw_sdio_8723bs_stop_tx_queue(struct rtw_dev *rtwdev,
> +                                         enum rtw_tx_queue_type queue,
> +                                         u16 q_map)
> +{
> +       struct rtw_sdio *rtwsdio = (struct rtw_sdio *)rtwdev->priv;
> +
> +       if (!rtw_is_8723bs(rtwdev) || queue >= RTW_TX_QUEUE_BCN)
> +               return;
> +
> +       if (READ_ONCE(rtwsdio->tx_queue_stopped[queue]))
> +               return;
> +
> +       if (skb_queue_len(&rtwsdio->tx_queue[queue]) < RTW_SDIO_TX_FIFO_HIWATER)
> +               return;
> +
> +       WRITE_ONCE(rtwsdio->tx_queue_stopped[queue], true);
> +       ieee80211_stop_queue(rtwdev->hw, q_map);
> +
> +       /*
> +        * The worker may have drained the queue between the length check
> +        * above and the flag becoming visible; its wake check then saw the
> +        * flag still clear and this stop would never be undone. Re-check
> +        * now that the flag is set and undo the stop if so. Both sides can
> +        * wake, which is harmless; the barrier pairs with the one in
> +        * rtw_sdio_8723bs_wake_tx_queue() so at least one side does.
> +        */
> +       smp_mb();

With WRITE_ONCE() and READ_ONCE(), I think it will concurrency work
well. Did you really encounter problems with smp_mb()?

a blank line.

> +       if (skb_queue_len(&rtwsdio->tx_queue[queue]) <=
> +           RTW_SDIO_TX_FIFO_LOWATER) {
> +               WRITE_ONCE(rtwsdio->tx_queue_stopped[queue], false);
> +               ieee80211_wake_queue(rtwdev->hw, q_map);
> +       }
> +}
> +
> +static void rtw_sdio_8723bs_wake_tx_queue(struct rtw_dev *rtwdev,
> +                                         enum rtw_tx_queue_type queue,
> +                                         u16 q_map)
> +{
> +       struct rtw_sdio *rtwsdio = (struct rtw_sdio *)rtwdev->priv;
> +
> +       if (!rtw_is_8723bs(rtwdev) || queue >= RTW_TX_QUEUE_BCN)
> +               return;
> +
> +       /* pairs with the barrier in rtw_sdio_8723bs_stop_tx_queue() */
> +       smp_mb();
> +
> +       if (!READ_ONCE(rtwsdio->tx_queue_stopped[queue]))
> +               return;
> +
> +       if (skb_queue_len(&rtwsdio->tx_queue[queue]) > RTW_SDIO_TX_FIFO_LOWATER)
> +               return;
> +
> +       WRITE_ONCE(rtwsdio->tx_queue_stopped[queue], false);
> +       ieee80211_wake_queue(rtwdev->hw, q_map);
> +}
> +

[...]

> 
> -static void rtw_sdio_process_tx_queue(struct rtw_dev *rtwdev,
> -                                     enum rtw_tx_queue_type queue)
> +/*
> + * Send one frame from @queue. Returns 0 when a frame was written, 1 when the
> + * queue was empty and a negative errno when the write failed, in which case
> + * the frame is put back at the head of the queue.
> + */
> +static int rtw_sdio_process_tx_queue(struct rtw_dev *rtwdev,
> +                                    enum rtw_tx_queue_type queue)
>  {
>         struct rtw_sdio *rtwsdio = (struct rtw_sdio *)rtwdev->priv;
>         struct sk_buff *skb;
> +       u16 q_map;
>         int ret;
> 
>         skb = skb_dequeue(&rtwsdio->tx_queue[queue]);
>         if (!skb)
> -               return;
> +               return 1;
> 
> +       q_map = skb_get_queue_mapping(skb);

Can we move below just before the user?

>         ret = rtw_sdio_write_port(rtwdev, skb, queue);
>         if (ret) {
>                 skb_queue_head(&rtwsdio->tx_queue[queue], skb);
> -               return;
> +               return ret;
>         }
> 
>         rtw_sdio_indicate_tx_status(rtwdev, skb);
> +
> +       rtw_sdio_8723bs_wake_tx_queue(rtwdev, queue, q_map);
> +
> +       return 0;
> +}
> +



  reply	other threads:[~2026-08-25  6:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20  9:04 [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-08-20  9:04 ` [PATCH v7 1/6] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-08-20  9:04 ` [PATCH v7 2/6] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-08-20  9:04 ` [PATCH v7 3/6] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-08-20  9:04 ` [PATCH v7 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-08-25  6:12   ` Ping-Ke Shih
2026-08-25  7:20     ` Luka Gejak
2026-08-25  7:25       ` Ping-Ke Shih
2026-08-25  7:33         ` Luka Gejak
2026-08-25  7:50           ` Ping-Ke Shih
2026-08-25  8:07             ` Luka Gejak
2026-08-25  8:22               ` Ping-Ke Shih
2026-08-25  8:32                 ` Luka Gejak
2026-08-25  8:38                   ` Ping-Ke Shih
2026-08-25  8:42                     ` Luka Gejak
2026-08-25  8:49                       ` Ping-Ke Shih
2026-08-20  9:04 ` [PATCH v7 5/6] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-08-20  9:04 ` [PATCH v7 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation luka.gejak
2026-08-25  6:36   ` Ping-Ke Shih [this message]
2026-08-25  7:22     ` Luka Gejak
2026-08-25  8:27       ` Ping-Ke Shih
2026-08-22 16:51 ` [PATCH v7 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS Luka Gejak
2026-08-23  6:00   ` Luka Gejak
2026-08-25  7:08     ` Ping-Ke Shih
2026-08-25  7:27       ` Luka Gejak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=348bea609cee45179ee2a0c7dd03f0d1@realtek.com \
    --to=pkshih@realtek.com \
    --cc=johannes.goede@oss.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luka.gejak@linux.dev \
    --cc=pbrobinson@gmail.com \
    --cc=rtl8821cerfe2@gmail.com \
    --cc=straube.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox