mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Mehmet Fide <mehmet.fide@gmail.com>
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: RE: [PATCH rtw-next 2/2] wifi: rtw88: usb: only let the frames a dozing station needs use the after-DTIM queue
Date: Sun, 6 Sep 2026 03:51:29 +0000	[thread overview]
Message-ID: <e0c709bd661044d799c3f04ec7348c4d@realtek.com> (raw)
In-Reply-To: <20260902104146.3853102-3-mehmet.fide@gmail.com>

Mehmet Fide <mehmet.fide@gmail.com> wrote:
> From: Mehmet Fide <mehmet.fide@screeningeagle.com>
> 
> With the budget in place the high queue can no longer take the chip
> down, but ordinary chatter still competes with the frames a sleeping
> station actually needs. mac80211 marks every broadcast and multicast
> frame with IEEE80211_TX_CTL_SEND_AFTER_DTIM while a station dozes,
> mDNS and SSDP included, so under normal traffic the budget is spent on
> frames nobody waits for.
> 
> Do what the vendor driver does with its default "allow special" high
> queue filter: admit only ARP, EAPOL and DHCP to the after-DTIM path,
> the frames a station coming out of power save has to see; everything
> else goes out on its access category queue at line rate. Encrypted
> group frames carry the IV between the header and the SNAP header, so
> the parser accounts for hw_key->iv_len. With the filter in place the
> page pool stays at 1803 through the same 180 second storm, a DHCP
> flood still takes the after-DTIM path (and is then held by the budget),
> and join/ping cycling without power save is unchanged (10/10).
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
> ---
>  drivers/net/wireless/realtek/rtw88/usb.c | 42 +++++++++++++++++++++++-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
> index 80965e5ea778..dd65b304b2c7 100644
> --- a/drivers/net/wireless/realtek/rtw88/usb.c
> +++ b/drivers/net/wireless/realtek/rtw88/usb.c
> @@ -5,6 +5,9 @@
>  #include <linux/module.h>
>  #include <linux/usb.h>
>  #include <linux/mutex.h>
> +#include <linux/ip.h>
> +#include <linux/udp.h>
> +#include <linux/unaligned.h>

The existing is messed already. But could please put them in increasing
alphabet order? (only apply the part of '#include <linux/*')

>  #include "main.h"
>  #include "debug.h"
>  #include "mac.h"
> @@ -562,6 +565,43 @@ static int rtw_usb_write_data_h2c(struct rtw_dev *rtwdev, u8 *buf, u32 size)
>         return rtw_usb_write_data(rtwdev, &pkt_info, buf);
>  }
> 
> +static bool rtw_usb_bmc_needs_dtim(struct sk_buff *skb)
> +{
> +       struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> +       struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
> +       unsigned int hdrlen = ieee80211_hdrlen(hdr->frame_control);
> +       unsigned int paylen = sizeof(rfc1042_header) + sizeof(__be16);

In reverse X'mas tree order. If you want keep 'struct' and 'unsigned int'
together individually. We can have

	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
	unsigned int paylen = sizeof(rfc1042_header) + sizeof(__be16);
	unsigned int hdrlen = ieee80211_hdrlen(hdr->frame_control);


> +       const struct udphdr *udp;
> +       const struct iphdr *ip;
> +       const u8 *snap;
> +       __be16 proto;
> +
> +       if (info->control.hw_key)
> +               hdrlen += info->control.hw_key->iv_len;
> +
> +       if (skb->len < hdrlen + paylen)
> +               return false;
> +
> +       snap = skb->data + hdrlen;
> +       proto = get_unaligned((__be16 *)(snap + sizeof(rfc1042_header)));
> +
> +       if (proto == htons(ETH_P_ARP) || proto == htons(ETH_P_PAE))

Can we just 'skb->protocol == htons(ETH_P_ARP)' ?

> +               return true;
> +
> +       if (proto != htons(ETH_P_IP) || skb->len < hdrlen + paylen + sizeof(*ip))
> +               return false;
> +
> +       ip = (const struct iphdr *)(snap + paylen);
> +       if (ip->protocol != IPPROTO_UDP)
> +               return false;
> +
> +       udp = (const struct udphdr *)((const u8 *)ip + ip->ihl * 4);
> +       if (skb->len < (unsigned int)((const u8 *)udp - skb->data) + sizeof(*udp))
> +               return false;

udphdr = udp_hdr(skb); ?

reference to rtw89_core_tx_btc_spec_pkt_notify().

> +
> +       return udp->dest == htons(67) || udp->dest == htons(68);
> +}
> +
>  #define RTW_USB_HIQ_RATE       10
>  #define RTW_USB_HIQ_BURST      16
> 
> @@ -605,7 +645,7 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct rtw_usb *rtwusb,
>         else if (is_broadcast_ether_addr(hdr->addr1) ||
>                  is_multicast_ether_addr(hdr->addr1))
>                 qsel = (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) &&
> -                      rtw_usb_hiq_take(rtwusb) ?
> +                      rtw_usb_bmc_needs_dtim(skb) && rtw_usb_hiq_take(rtwusb) ?
>                        TX_DESC_QSEL_HIGH : skb->priority;
>         else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
>                 qsel = skb->priority;
> --
> 2.54.0


  reply	other threads:[~2026-09-06  3:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 10:41 [PATCH rtw-next 0/2] wifi: rtw88: usb: keep bmc traffic from exhausting the TX page pool Mehmet Fide
2026-09-02 10:41 ` [PATCH rtw-next 1/2] wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue Mehmet Fide
2026-09-06  3:41   ` Ping-Ke Shih
2026-09-06  8:20     ` Mehmet Fide
2026-09-02 10:41 ` [PATCH rtw-next 2/2] wifi: rtw88: usb: only let the frames a dozing station needs use " Mehmet Fide
2026-09-06  3:51   ` Ping-Ke Shih [this message]
2026-09-06  8:20     ` Mehmet Fide

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=e0c709bd661044d799c3f04ec7348c4d@realtek.com \
    --to=pkshih@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mehmet.fide@gmail.com \
    --cc=mehmet.fide@screeningeagle.com \
    --cc=rtl8821cerfe2@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

all inboxes | Powered by JetHome®