On Mon, Sep 24, 2018 at 2:18 PM Song Liu <songliubrav...@fb.com> wrote:
>
>
>
> > On Sep 24, 2018, at 2:05 PM, Eric Dumazet <eduma...@google.com> wrote:
> >
> >>
> >> Interesting, maybe a bnxt specific issue.
> >>
> >> It seems their model is to process TX/RX notification in the same queue,
> >> they throw away RX events if budget == 0
> >>
> >> It means commit e7b9569102995ebc26821789628eef45bd9840d8 is wrong and
> >> must be reverted.
> >>
> >> Otherwise, we have a possibility of blocking a queue under netpoll
> >> pressure.
> >
> > Hmm, actually a revert might not be enough, since code at lines 2030-2031
> > would fire and we might not call napi_complete_done() anyway.
> >
> > Unfortunately this driver logic is quite complex.
> >
> > Could you test on other NIC eventually ?
> >
>
> It actually runs OK on ixgbe.
>
> @Michael, could you please help us with this?
>
I've taken a quick look using today's net tree plus Eric's
poll_one_napi() patch. The problem I'm seeing is that netpoll calls
bnxt_poll() with budget 0. And since work_done >= budget of 0, we
return without calling napi_complete_done() and without arming the
interrupt. netpoll doesn't always call us back until we call
napi_complete_done(), right? So I think if there are in-flight TX
completions, we'll miss those.
