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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <531EC4EE.8080104@freescale.com>
Date:	Tue, 11 Mar 2014 10:10:22 +0200
From:	Claudiu Manoil <claudiu.manoil@...escale.com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 0/2] gianfar: Tx timeout issue

On 3/10/2014 7:18 PM, David Miller wrote:
> From: Claudiu Manoil <claudiu.manoil@...escale.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

--
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