Hi,
Thanks for you patch. I tried your patch and see the throughput is
really improved a lot. For packet size of 512, the throughput jumps from 2%
to 55%. For packet size of 1024, the throughput jumps from 50% to 66%.
Although the improvement for packet size of 256 and 188 doesn't change much
(0%->4% and 0%->2% respectively), it helps a lot already.
Regards,
Jacky
----- Original Message -----
From: "Andrew May" <[EMAIL PROTECTED]>
To: <linuxppc-embedded at lists.linuxppc.org>
Sent: Wednesday, January 21, 2004 10:05 AM
Subject: Re: Small UDP packet performance
>
> On Tue, Jan 20, 2004 at 05:16:50PM -0800, Eugene Surovegin wrote:
> > On Tue, Jan 20, 2004 at 03:23:42PM -0800, Andrew May wrote:
> > > Here is what I have done for a NAPI version of the driver. I don't
have time
> > > either to do a patch or merge this up to the latest kernel. I have
frozen down
> > > at 2.4.21-pre4 somewhere and I won't be merging anytime soon. It is
stable for
> > > me.
> >
> > Looks OK, although I chose another way to disable RX IRQs :)
>
> Do tell.
>
> > Sad thing is because of bad MAL design NAPI will be limited to one
> > EMAC per MAL (there is no way to disable IRQ generation on channel
> > basis), it's not an issue for 405, but for 440 I haven't figured
> > out how to overcome this limitation yet.
>
> Yep it is a problem and even for the 405's with more than one ethernet.
>
> > Andrew, I'm just curious, you probably did some measurements with
> > your NAPI driver, care to share them :) ?
>
> It may be hard to compare them. I am adding some data to each packet
> and routing them to another PCI device. I think things max out around
> 18kpps one way. Going full-duplex things even out pretty good both
> ways with the total pps being slightly higher. The most important
> thing is that when the input rate goes higher the output stays at
> the max instead of going down.
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
