netdev - RE: [PATCH net] r8152: avoid the driver drops a lot of packets

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] [day] [month] [year] [list]

Date: Tue, 5 Sep 2023 12:58:18 +0000
From: Hayes Wang <hayeswang@...ltek.com>
To: Paolo Abeni <pabeni@...hat.com>, "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        nic_swsd
	<nic_swsd@...ltek.com>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org"
	<linux-usb@...r.kernel.org>
Subject: RE: [PATCH net] r8152: avoid the driver drops a lot of packets

Paolo Abeni <pabeni@...hat.com>
> Sent: Tuesday, September 5, 2023 7:21 PM
[...]
> I'm sorry, I have a very superficial knowledge of the USB layer, but it
> looks like that when such condition is reached, in the worst condition
> there could be up to urbs in flight. AFAICS each of them carries a 16K
> buffer, can be up to 10 standard-mtu packets - or much more small ones.
> 
> Setting an upper limits to the rx_queue still looks like a reasonable
> safeguard.

I think it is very hard to queue more than 1000 packets. The NAPI continues
consuming the queued packets. And, the hardware wouldn't complete all
urbs at one time. However, I would add WARN_ON_ONCE() to observe if 
any exception would occur.

> > Besides, if the flow control is disabled, the packets may be dropped by
> > the hardware when the FIFO of the device is full, after the driver stops
> > submitting rx.
> 
> If the incoming rate exceeds the H/W processing capacity, packets are
> dropped: that is expected and unavoidable.
> 
> Possibly exposing the root cause for such drops to user space via
> appropriate stats would be useful.

The number of packet which the device drops could be got through
ethtool.

Best Regards,
Hayes