[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1429035897.7346.49.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 14 Apr 2015 11:24:57 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Yuval Mintz <Yuval.Mintz@...gic.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>, "bind@...s.net" <bind@...s.net>,
"peter@...leysoftware.com" <peter@...leysoftware.com>,
Ariel Elior <Ariel.Elior@...gic.com>,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net] bnx2x: Fix netpoll interoperability
On Tue, 2015-04-14 at 18:11 +0000, Yuval Mintz wrote:
> > I believe the original busypoll yield concern was forgotten or reversed.
>
> > If you have many busypoll users, they might get the 'lock', and the poor
> > cpu that received the hardware interrupt and raised RX softirq for this
> > RX queue will spin forever [1]
>
> > busypoll users should backoff and not attempt to grab a lock (especially
> > if this lock is not a ticket lock anymore) if the softirq handler is
> > desperately trying to make progress.
>
> > [1]
> > sofirq handler
>
> > while (1) {
> > if (!bnx2x_fp_lock_napi())
> > continue;
>
> bnx2x returns the budget, it doesn't loop in the poll function.
returning budget literally asks to call again asap.
> [I don't have the napi_poll logic in mind, but I do hope it doesn't iterate
> repeatedly but rather only on next re-schedule]
I can tell you it loops. Look again at the code.
To break the loop, you have to call napi_complete()
> > }
> > }
>
> > I can provide an alternative patch if you like.
>
> If you're willing to make the effort, sure.
Yes, will do that shortly.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists