netdev - Re: [RFC] gianfar: low gigabit throughput

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080507133346.GA8308@polina.dev.rtsoft.ru>
Date:	Wed, 7 May 2008 17:33:46 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Andy Fleming <afleming@...escale.com>
Cc:	Rick Jones <rick.jones2@...com>, netdev@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: [RFC] gianfar: low gigabit throughput

On Tue, May 06, 2008 at 03:29:06PM -0500, Andy Fleming wrote:
>>>
>>> I've tried to tune gianfar driver in various ways... and it gave
>>> some positive results with this patch:
>>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>>> index fd487be..b5943f9 100644
>>> --- a/drivers/net/gianfar.h
>>> +++ b/drivers/net/gianfar.h
>>> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
>>> #define GFAR_10_TIME    25600
>>>  #define DEFAULT_TX_COALESCE 1
>>> -#define DEFAULT_TXCOUNT	16
>>> -#define DEFAULT_TXTIME	21
>>> +#define DEFAULT_TXCOUNT	80
>>> +#define DEFAULT_TXTIME	105
>>>  #define DEFAULT_RXTIME	21
>>
>> No ethtool coalescing tuning support for gianfar?-)
>
> Yeah, there's coalescing tuning in gianfar.
>
> Anton, those numbers aren't too surprising on a 400 MHz machine, I  
> think.

This is my thinking too, actually. I've seen the MPC885 board with CPU
running at 133 MHz and CSB at 66MHz. It was using the completely
different driver (fs_enet's FEC), and it failed to produce even 60 Mb/s
(with a 100 Mb/s PHY). 50-55 Mb/s was quite normal for that board.

Which means, I think, that ~160 Mb/s is quite good for the 400/133
MHz board.

> But I'd be happy to see any analysis on performance bottlenecks 
> in the driver.  And patches to fix those bottlenecks are even better!  :)

The thing is that I don't see obvious bottlenecks, so I'm afraid we'll
not able to do x2 boost or something... Just fine tuning the driver here
and there... Interrupts coalescing was very obvious step to boost the
troughtput, but there are its drawbacks...

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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