[PATCH] Gianfar SKB Recycling Support

[Haruki Dai-r35557]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger at osdl.org] 
> Sent: Saturday, May 20, 2006 2:48 AM
> To: Haruki Dai-r35557
> Cc: netdev at vger.kernel.org; Fleming Andy-afleming; Kumar 
> Gala; Haruki Dai-r35557
> Subject: Re: [PATCH] Gianfar SKB Recycling Support
> 
> On Wed, 17 May 2006 15:45:14 -0700
> "Haruki Dai-r35557" <Dai.Haruki at freescale.com> wrote:
> 
> > 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.
> > 
> > Signed-off-by: Dai Haruki <dai.haruki at freescale.com>
> > Signed-off-by: Andy Fleming <afleming at freescale.com>
> > 
> 
> 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.
> 
> 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? 

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