netdev - RE: [EXT] Re: [PATCH net] net: ethernet: fec: prevent tx starvation under high rx load

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]

Message-ID: <AM6PR0402MB3607AC71BEDBE8784F8970D0FF6C0@AM6PR0402MB3607.eurprd04.prod.outlook.com>
Date:   Wed, 1 Jul 2020 03:22:35 +0000
From:   Andy Duan <fugang.duan@....com>
To:     David Miller <davem@...emloft.net>,
        "tobias@...dekranz.com" <tobias@...dekranz.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH net] net: ethernet: fec: prevent tx starvation
 under high rx load

From: David Miller <davem@...emloft.net> Sent: Wednesday, July 1, 2020 3:58 AM
> From: "Tobias Waldekranz" <tobias@...dekranz.com>
> Date: Tue, 30 Jun 2020 08:39:58 +0200
> 
> > On Mon Jun 29, 2020 at 3:07 PM CEST, David Miller wrote:
> >> I don't see how this can happen since you process the TX queue
> >> unconditionally every NAPI pass, regardless of what bits you see set
> >> in the IEVENT register.
> >>
> >> Or don't you? Oh, I see, you don't:
> >>
> >> for_each_set_bit(queue_id, &fep->work_tx, FEC_ENET_MAX_TX_QS) {
> >>
> >> That's the problem. Just unconditionally process the TX work
> >> regardless of what is in IEVENT. That whole ->tx_work member and the
> >> code that uses it can just be deleted. fec_enet_collect_events() can
> >> just return a boolean saying whether there is any RX or TX work at all.
> >
> > Maybe Andy could chime in here, but I think the ->tx_work construction
> > is load bearing. It seems to me like that is the only thing stopping
> > us from trying to process non-existing queues on older versions of the
> > silicon which only has a single queue.
> 
> Then iterate over "actually existing" queues.
Yes, the iterate over real queues, but only bit2 has the chance to be set, so it
Is compatible with single queue.