how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.

hi,everbody:
      I have run linux-2.6.15 on my mpc8541 custom board. but when i test
TSEC use UDP, i found it's efficinecy is lower.
my test enviroment: i only run a UDP recieve program and not to handle data
recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed.
so i think tcp/ip protocal have consume my mpc8541 resource.  i dont know
how to improve tcp/ip code or TSEC driver(gianfar.c).
      can somebody help me ?



 lucky.huang

huangyun@coship.com schrieb:
 > hi,everbody:
 >       I have run linux-2.6.15 on my mpc8541 custom board. but when i test
 > TSEC use UDP, i found it's efficinecy is lower.
 > my test enviroment: i only run a UDP recieve program and not to handle data
 > recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed.
 > so i think tcp/ip protocal have consume my mpc8541 resource.  i dont know
 > how to improve tcp/ip code or TSEC driver(gianfar.c).
 >       can somebody help me ?

Hmm... you should first try one of the current kernels and check the
performance there.
For further details about linux networking, I recommend you to contact
the guys at the netdev list, giving lots of details how you do your
benchmarking and how your workload looks like.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Hi,

We use a 8250 and 8270 of which the performance is highly limited by the 
bandwidth of the memory to the very small internal cache.
I once modified a driver into a "polling" method polling the device 
every millisecond. The amount of messages processed trippled this way! 
On full speed the console could even be used for "normal" operation (in 
contrairy to the interrupt driver driver).
The penalties are obvious: When the bandwith used is low the delay for 
polled messages is higher and the CPU overhead is higher.

Succes,
   Theo.

Clemens Koller schreef:

huangyun@coship.com schrieb:
 > hi,everbody:
 >       I have run linux-2.6.15 on my mpc8541 custom board. but when i test
 > TSEC use UDP, i found it's efficinecy is lower.
 > my test enviroment: i only run a UDP recieve program and not to handle data
 > recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed.
 > so i think tcp/ip protocal have consume my mpc8541 resource.  i dont know
 > how to improve tcp/ip code or TSEC driver(gianfar.c).
 >       can somebody help me ?

Hmm... you should first try one of the current kernels and check the
performance there.
For further details about linux networking, I recommend you to contact
the guys at the netdev list, giving lots of details how you do your
benchmarking and how your workload looks like.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

  

Hi,

We use a 8250 and 8270 of which the performance is highly limited by the 
bandwidth of the memory to the very small internal cache.
I once modified a driver into a "polling" method polling the device 
every millisecond. The amount of messages processed trippled this way! 
On full speed the console could even be used for "normal" operation (in 
contrairy to the interrupt driver driver).
The penalties are obvious: When the bandwith used is low the delay for 
polled messages is higher and the CPU overhead is higher.

Just look at the NAPI[1] (New-NAPI in the latest incarnation) linux
layer for network drivers.  The upshot of this is that where "old"
drivers pull data from the network card onto the kernel network
backlog on interrupt time, NAPI drivers only set an internal flag so
they want to get polled by the kernel when it is ready and basically
disable further interrupts.  They are enabled again by the time the
driver was able to post all packets up to the network stack.

This effectively gives low latencies on low network load because it
more or less stays being interrupt driven but it turns into polling
mode on high network loads and thus prevents interrupt live lock
situations.  

Adapting the network driver in question to NNAPI should improve the
performance of the whole system quite a bit.

Best wishes
  Detlev

[1] http://www.linux-foundation.org/en/Net:NAPI

-- 
Indeed, the author firmly believes that the best serious work is also
good fun.   We needn't apologize if we enjoy doing research.
                                        -- Donald Knuth
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de