Nice patch!
One question inline.
On Thu, Aug 6, 2020 at 2:58 AM Felix Fietkau wrote:
>
> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
> poll function does not perform well. Since NAPI poll is bound to the CPU it
> was scheduled from, we can easily end up with a fe
On 8/6/20 12:57 PM, Jakub Kicinski wrote:
> On Thu, 6 Aug 2020 12:25:08 -0700 Eric Dumazet wrote:
>> On 8/6/20 11:55 AM, Jakub Kicinski wrote:
>>> I'm still trying to wrap my head around this.
>>>
>>> Am I understanding correctly that you have one IRQ and multiple NAPI
>>> instances?
>>>
>>> Are
On Thu, 6 Aug 2020 12:25:08 -0700 Eric Dumazet wrote:
> On 8/6/20 11:55 AM, Jakub Kicinski wrote:
> > I'm still trying to wrap my head around this.
> >
> > Am I understanding correctly that you have one IRQ and multiple NAPI
> > instances?
> >
> > Are we not going to end up with pretty terrible c
On 8/6/20 11:55 AM, Jakub Kicinski wrote:
> On Thu, 6 Aug 2020 11:55:58 +0200 Felix Fietkau wrote:
>> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
>> poll function does not perform well. Since NAPI poll is bound to the CPU it
>> was scheduled from, we can easily
On Thu, 6 Aug 2020 11:55:58 +0200 Felix Fietkau wrote:
> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
> poll function does not perform well. Since NAPI poll is bound to the CPU it
> was scheduled from, we can easily end up with a few very busy CPUs spending
> most
Hi Felix,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on linus/master next-20200806]
[cannot apply to net/master ipvs/master v5.8]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 8/6/20 2:55 AM, Felix Fietkau wrote:
> For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
> poll function does not perform well. Since NAPI poll is bound to the CPU it
> was scheduled from, we can easily end up with a few very busy CPUs spending
> most of their time
For some drivers (especially 802.11 drivers), doing a lot of work in the NAPI
poll function does not perform well. Since NAPI poll is bound to the CPU it
was scheduled from, we can easily end up with a few very busy CPUs spending
most of their time in softirq/ksoftirqd and some idle ones.
Introduc
