Thread (22 messages) 22 messages, 5 authors, 2010-03-02

RE: Gianfar driver failing on MPC8641D based board

From: Kumar Gopalpet-B05799 <hidden>
Date: 2010-02-26 04:58:55
Also in: lkml, netdev

=20
quoted hunk ↗ jump to hunk
-----Original Message-----
From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
Sent: Friday, February 26, 2010 8:45 AM
To: Paul Gortmaker
Cc: Martyn Welch; linuxppc-dev list; netdev@vger.kernel.org;=20
linux-kernel@vger.kernel.org; Kumar Gopalpet-B05799;=20
davem@davemloft.net; Kumar Gala
Subject: Re: Gianfar driver failing on MPC8641D based board

On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
[...]
quoted
I was able to reproduce it on an 8641D and bisected it down to this:
=20
-----------
commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
Author: Anton Vorontsov [off-list ref]
Date:   Tue Nov 10 14:11:10 2009 +0000
=20
    gianfar: Revive SKB recycling
Thanks for the bisect. I have a guess why tx hangs in SMP=20
case. Could anyone try the patch down below?

[...]
quoted
...which probably explains why you weren't seeing it on non-SMP.
I'd imagine it would show up on any of the e500mc boards too.
Yeah.. Pity, I don't have SMP boards anymore. I'll try to get=20
one though.

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c=20
index 8bd3c9f..3ff3bd0 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct=20
*napi, int budget)
			tx_queue =3D priv->tx_queue[rx_queue->qindex];
=20
			tx_cleaned +=3D gfar_clean_tx_ring(tx_queue);
+			if (!tx_cleaned && !tx_queue->num_txbdfree)
+				tx_cleaned +=3D 1; /* don't=20
complete napi */
			rx_cleaned_per_queue =3D=20
gfar_clean_rx_ring(rx_queue,
						=09
budget_per_queue);
			rx_cleaned +=3D rx_cleaned_per_queue;
Anton,=20

There is also one more issue that I have been observing with the patch
"gianfar: Revive SKB recycling".
The issue is when I do a IPV4 forwarding test scenario with
bidirectional flows (SMP environment). I am using Spirent smart bits
(smartflow) for automation testing and I frequently observe smart flow
reporting "Rx packet counte greater than Tx packet count. Duplicate
packets might have been received".

To just get over the issue I have removed this patch and I didn't see
the issue.

To a certain extent I could get over the problem by using atomic_t for
num_txbdfree (atomic_add and atomic_dec instructions for updating the
num_txbdfree) and completely removing the spin_locks in the tx routines.

Also, I feel we might want to make some more changes to the
gfar_clean_tx_ring( ) and gfar_start_xmit() routines so that they can
operate parallely.=20

I am really sorry for not posting it a bit earlier as I am caught up
with some urgent issues.

--

Thanks
Sandeep
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help