netdev - RE: [PATCH net-next] igc: Avoid transmit queue timeout for XDP

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, 13 Apr 2023 21:19:48 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jacob Keller' <jacob.e.keller@...el.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     Kurt Kanzenbach <kurt@...utronix.de>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Ong Boon Leong <boon.leong.ong@...el.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] igc: Avoid transmit queue timeout for XDP

From: Jacob Keller
> Sent: 13 April 2023 17:40
> 
> On 4/13/2023 9:03 AM, Jakub Kicinski wrote:
> > On Wed, 12 Apr 2023 15:30:38 -0700 Jacob Keller wrote:
> >> Is most driver's XDP implementation broken? There's also
> >> netif_trans_update but this is called out as a legacy only function. Far
> >> more drivers call this but I don't see either call or a direct update to
> >> trans_start in many XDP implementations...
> >>
> >> Am I missing something or are a bunch of other XDP implementations also
> >> wrong?
> >
> > Only drivers which use the same Tx queues for the stack and XDP need
> > this.
> 
> Ok that explains it. igc has few enough queues they need to be shared,
> but other devices have more queues and can use dedicated queues.

Aren't there some generic problems with multiple transmit queues?
The tg3 driver only uses a single tx queue because sending enough
large packets to saturate the network through one queue has the
effect of significantly delaying packets on other queues because
of the 'round robin' algorithm used by the hardware.

Transmit processing is also a lot less demanding than the receive
processing.
So you may want to split the receive traffic into multiple
queues (with the processing happening on multiple cpu) but
keep the transmit processing (which is much less critical)
only running on a single cpu - so with a single queue.
(Trying to process 10000 RTP streams gets 'interesting'.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)