On 09/18/2018 02:13 PM, Eric Dumazet wrote:
> On Tue, Sep 18, 2018 at 1:37 PM Song Liu <songliubrav...@fb.com> wrote:
>>
>
>> Looks like a patch like the following fixes the issue for ixgbe. But I
>> cannot explain it yet.
>>
>> Does this ring a bell?
>
> I dunno, it looks like the NIC is generating an interrupt while it should
> not,
> and constantly sets NAPI_STATE_MISSED.
>
> Or maybe we need to properly check napi_complete_done() return value.
>
> diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> index
> d3e72d0f66ef428b08e4bd88508e05b734bc43a4..c4c565c982a98a5891603cedcdcb72dc1c401813
> 100644
> --- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> +++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
> @@ -1773,8 +1773,8 @@ ixgb_clean(struct napi_struct *napi, int budget)
> ixgb_clean_rx_irq(adapter, &work_done, budget);
>
> /* If budget not fully consumed, exit the polling mode */
> - if (work_done < budget) {
> - napi_complete_done(napi, work_done);
> + if (work_done < budget &&
> + napi_complete_done(napi, work_done)) {
> if (!test_bit(__IXGB_DOWN, &adapter->flags))
> ixgb_irq_enable(adapter);
> }
This would not be the only driver doing this unfortunately... should we
add a __must_check annotation to help catch those (mis)uses? Though that
could cause false positives for drivers using NAPI to clean their TX ring.
--
Florian
