lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 29 Dec 2022 00:50:39 +0000
From:   Ping-Ke Shih <pkshih@...ltek.com>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>
CC:     "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        Yan-Hsuan Chuang <tony0620emma@...il.com>,
        Kalle Valo <kvalo@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Chris Morgan <macroalpha82@...il.com>,
        "Nitin Gupta" <nitin.gupta981@...il.com>,
        Neo Jou <neojou@...il.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>
Subject: RE: [RFC PATCH v1 12/19] rtw88: sdio: Add HCI implementation for SDIO based chipsets



> -----Original Message-----
> From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
> Sent: Wednesday, December 28, 2022 8:00 PM
> To: Ping-Ke Shih <pkshih@...ltek.com>
> Cc: linux-wireless@...r.kernel.org; Yan-Hsuan Chuang <tony0620emma@...il.com>; Kalle Valo
> <kvalo@...nel.org>; Ulf Hansson <ulf.hansson@...aro.org>; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org; linux-mmc@...r.kernel.org; Chris Morgan <macroalpha82@...il.com>; Nitin Gupta
> <nitin.gupta981@...il.com>; Neo Jou <neojou@...il.com>; Jernej Skrabec <jernej.skrabec@...il.com>
> Subject: Re: [RFC PATCH v1 12/19] rtw88: sdio: Add HCI implementation for SDIO based chipsets
> 
> Hi Ping-Ke,
> 
> as always: thank you so much for taking time to go through this!
> 
> On Wed, Dec 28, 2022 at 10:39 AM Ping-Ke Shih <pkshih@...ltek.com> wrote:

[...]

> > > +static void rtw_sdio_rx_isr(struct rtw_dev *rtwdev)
> > > +{
> > > +     u32 rx_len;
> > > +
> > > +     while (true) {
> >
> > add a limit to prevent infinite loop.
> Do you have any recommendations on how many packets to pull in one go?
> My thinking is: pulling to little data at once can hurt performance

This is to prevent unexpected things happen, and normally we receive/send
all packets at once like while(true) code. So, maybe we can have rough limit,
like 512 that would be enough for most cases. To have accurate number, you
can do experiments with the highest performance to see the loop count in
real usage, and 5 or 10 times count as limit.

However, when I reviewed rtw88 USB patches, I found we can't always break
the loop, because it could only one chance to free skb(s). So, you should
make sure we really can break the loop logically, and then decide which
limit is suitable for us.

> 
> [...]
> >
> > > +
> > > +static void 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;
> > > +     int ret;
> > > +
> > > +     while (true) {
> >
> > Can we have a limit?
> Similar to the question above: do you have any recommendations on how
> many packets (per queue) to send in one go?
> 

Ping-Ke

Powered by blists - more mailing lists