[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKFLim4TVioFPkPn=eg3QErioU0M-QbHTR5w7b==_Xa-sP7gw@mail.gmail.com>
Date: Tue, 25 Sep 2018 14:09:08 -0700
From: Michael Chan <michael.chan@...adcom.com>
To: Song Liu <songliubraving@...com>
Cc: Eric Dumazet <edumazet@...gle.com>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
Ariel Elior <ariel.elior@...ium.com>,
Eric Dumazet <eric.dumazet@...il.com>, tariqt@...lanox.com,
Saeed Mahameed <saeedm@...lanox.com>,
jeffrey.t.kirsher@...el.com,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Jay Vosburgh <j.vosburgh@...il.com>, vfalico@...il.com,
Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
On Tue, Sep 25, 2018 at 11:25 AM Song Liu <songliubraving@...com> wrote:
>
> Hi Michael,
>
> This may not be related. But I am looking at this:
>
> bnxt_poll_work() {
>
> while (1) {
> ....
> if (rx_pkts == budget)
> return
> }
> }
>
> With budget of 0, the loop will terminate after processing one packet.
> But I think the expectation is to finish all tx packets. So it doesn't
> feel right. Could you please confirm?
>
Right, this in effect is processing only 1 TX packet so it will be
inefficient at least.
But I think fixing it here still will not fix all the issues, because
even if we process all the TX packets here, we may still miss some
that are in flight. When we exit poll, netpoll may not call us back
again and there may be no interrupts because we don't ARM the IRQ when
budget of 0 is reached. I will send a test patch shortly for review
and testing. Thanks.
Powered by blists - more mailing lists