[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLQa-FruxSUQycawQAHY=wCFP_Q3LHEQfusL1pUbNVxyg@mail.gmail.com>
Date: Fri, 17 Feb 2023 13:57:33 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Felix Fietkau <nbd@....name>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2] net/core: add optional threading for rps backlog processing
On Fri, Feb 17, 2023 at 1:35 PM Felix Fietkau <nbd@....name> wrote:
>
> On 17.02.23 13:23, Eric Dumazet wrote:
> > On Fri, Feb 17, 2023 at 11:06 AM Felix Fietkau <nbd@....name> wrote:
> >>
> >> When dealing with few flows or an imbalance on CPU utilization, static RPS
> >> CPU assignment can be too inflexible. Add support for enabling threaded NAPI
> >> for RPS backlog processing in order to allow the scheduler to better balance
> >> processing. This helps better spread the load across idle CPUs.
> >>
> >> Signed-off-by: Felix Fietkau <nbd@....name>
> >> ---
> >>
> >> RFC v2:
> >> - fix rebase error in rps locking
> >
> > Why only deal with RPS ?
> >
> > It seems you propose the sofnet_data backlog be processed by a thread,
> > instead than from softirq ?
> Right. I originally wanted to mainly improve RPS, but my patch does
> cover backlog in general. I will update the description in the next
> version. Does the approach in general make sense to you?
>
I do not know, this seems to lack some (perf) numbers, and
descriptions of added max latencies and stuff like that :)
Powered by blists - more mailing lists