Re: [PATCH net-next v2 0/2] gianfar: Tx timeout issue

[Claudiu Manoil <claudiu.manoil@freescale.com>]

On 3/10/2014 7:18 PM, David Miller wrote:
> From: Claudiu Manoil <claudiu.manoil@freescale.com>
> Date: Fri, 7 Mar 2014 14:42:44 +0200
>
>> There's an older Tx timeout issue showing up on etsec2 devices
>> with 2 CPUs.  I pinned this issue down to processing overhead
>> incurred by supporting multiple Tx/Rx rings, as explained in
>> the 2nd patch below.  But before this, there's also a concurency
>> issue leading to Rx/Tx spurrious interrupts, addressed by the
>> 'Tx NAPI' patch below.
>> The Tx timeout can be triggered with multiple Tx flows,
>> 'iperf -c -N 8' commands, on a 2 CPUs etsec2 based (P1020) board.
>
> Series applied, thanks.
>
>

Thanks David.
However there's a problem with the second patch:
http://patchwork.ozlabs.org/patch/327941/
(gianfar: Use Single-Queue polling for "fsl,etsec2")

According to my comments, I retracted the patch because
of null access in gfar_of_init(): priv is not instantiated
at that time, which makes the run time checks (to limit
the number of supported queues) to be tricky.

What do you prefer: an additional separate patch to fix this
null access issue, or to revert the existing patch?

Another point is that the "Use Single-Queue polling..." patch
(http://patchwork.ozlabs.org/patch/327941/)
aims to obsolete the multi-queue polling, i.e. supporting
multiple queues per single NAPI instance.  How do you fill
about removing multi-queue polling support from the driver?
Is there a point for a linux eth driver to support more than
a Rx/Tx queue per NAPI instance?

Thanks again.
Claudiu