RE: [PATCH] Gianfar SKB Recycling Support

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]=20
Sent: Saturday, May 20, 2006 2:48 AM
To: Haruki Dai-r35557
Cc: netdev@vger.kernel.org; Fleming Andy-afleming; Kumar=20
Gala; Haruki Dai-r35557
Subject: Re: [PATCH] Gianfar SKB Recycling Support
=20
On Wed, 17 May 2006 15:45:14 -0700
"Haruki Dai-r35557" [off-list ref] wrote:
=20

quoted

This patch improves the IP forwarding throughput of
the Freescale TSEC/eTSEC Gianfar driver. By recycling
the Socket buffer and Data buffer, reduce the unnecessary
memory allocation and de-allocation in the forwarding
processing chain.
=20
Signed-off-by: Dai Haruki <redacted>
Signed-off-by: Andy Fleming <redacted>
=20

=20
In case the general impression wasn't clear from the earlier comments.
This patch is an interesting benchmark tweak, but unlikely to ever
make it into the mainline kernel. The kernel needs to be a general
purpose system and deal with multiple types of hardware and resource
control.
=20
But don't give up looking at performance. If you can find ways to
speed up the overall socket buffer handling without breaking existing
semantics; then the patches would be positively received.

I admit the explanation of the implementation is indeed unclear. I will
put the recycling mechanism explanation. Is it better put as the
driver's comment? Or, the separate document like, say,
Document/net/skb_recycling.txt?

Just in case, I need to confirm that the patch is rejected even though
the expalanation is added?=20

I will surely work for making this mechanism more generic to the other
interface. I want to make sure that this patch is not the purpose of
benchmark tweak. This recycling mechanism makes the Linux's position in
the packet forwarding application better compare to the other
proprietary OS/Stack in terms of the throughput performance.=20
=20
 For the gianfar user, this patch also improves interrupt response under
the situation when previous gianfar tied up with the a lot of TX hw
interrupt even under NAPI (current gianfar NAPI implementation only help
Rx side since we have separate interrupt line). I will separate the
gianfar specific improvement, and post to this list again.



- Dai