Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Networking Drivers/devnp-mpc85xx: Tx csum capabilities ? /List of Posts
Forum Topic - devnp-mpc85xx: Tx csum capabilities ? : (6 Items)
   
Update
Christopher Pohl
06/02/2008 8:16 AM
post8641
devnp-mpc85xx: Tx csum capabilities ?   
Hi, 

the NIC driver for mpc85xx reports checksum offloading capabilities for the Rx direction only . From my understanding, 
the eTSEC (e.g. MPC8548) also supports Tx offloading. 
What's the reason that Tx is not offered by the driver? 

# ./ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
        inet 127.0.0.1 netmask 0xff000000
tsec0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
        capabilities tx=0
        enabled=0
        address: 00:e0:00:c0:00:fc
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active

Thanks, 
Christopher
Andrew Boyd(deleted)
06/02/2008 10:23 AM
post8647
RE: devnp-mpc85xx: Tx csum capabilities ?   
The io-pkt driver for the mpc85xx does support both
tx and rx checksumming (for the etsec only - the tsec
hardware does not support it).

Use the "enable_tx_hw_csum" driver option.

--
aboyd
Andrew Boyd(deleted)
06/02/2008 10:54 AM
post8650
RE: devnp-mpc85xx: Tx csum capabilities ?   
Rob stopped by my cube, and asked me to explain
my cryptic response. 

Enabling the hw csum option requires that you
construct and feed another transmit descriptor
to the etsec.  My performance measurements showed
that this was not free.  In fact, you may very
well see a *reduction* in throughput with tx cksum
enabled because of this. 

Hence the default is to not enable it.

Please feel free to run your own benchmarks with
the stock rx-only cksum, and with both tx and rx
cksum enabled, and get back to us.

If your processor is sufficently different than 
the one I used (IIRC 8548) then you may also get
different results!

N.B.  I noticed the same thing with jumbo packets.
Using the default MCLBYTES of 2K, I had to feed at
least four tx descriptors to the etsec.  But when
I bumped MCLBYTES up, I noticed a substantial 
improvement in performance.  The overhead to construct
and fetch and process a descriptor is not negligible.

--
aboyd
Robert Craig
06/02/2008 11:03 AM
post8651
RE: devnp-mpc85xx: Tx csum capabilities ?   
As a side note, we also found a bug in the way that the driver capabilities
were being processed that resulted in the checksum enabling not being picked
up properly, so it's possible that the reduction in performance was due to
this.  I'd forgotten that both rx / tx checksumming was available with the
eTSEC so only did my benchmarking using rx.  

	I'll have a closer look at some point and, if the performance is
good, we'll turn tx back on as a default.

	Robert.

-----Original Message-----
From: Andrew Boyd [mailto:aboyd@qnx.com] 
Sent: Monday, June 02, 2008 10:55 AM
To: drivers-networking
Subject: RE: devnp-mpc85xx: Tx csum capabilities ? 


Rob stopped by my cube, and asked me to explain
my cryptic response. 

Enabling the hw csum option requires that you
construct and feed another transmit descriptor
to the etsec.  My performance measurements showed
that this was not free.  In fact, you may very
well see a *reduction* in throughput with tx cksum
enabled because of this. 

Hence the default is to not enable it.

Please feel free to run your own benchmarks with
the stock rx-only cksum, and with both tx and rx
cksum enabled, and get back to us.

If your processor is sufficently different than 
the one I used (IIRC 8548) then you may also get
different results!

N.B.  I noticed the same thing with jumbo packets.
Using the default MCLBYTES of 2K, I had to feed at
least four tx descriptors to the etsec.  But when
I bumped MCLBYTES up, I noticed a substantial 
improvement in performance.  The overhead to construct
and fetch and process a descriptor is not negligible.

--
aboyd


_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post8650
Christopher Pohl
06/02/2008 11:39 AM
post8654
Re: RE: devnp-mpc85xx: Tx csum capabilities ?   
Hi Andrew, 

thanks for the in depth explanation. 

I didn't see that there is a command line option to enable it, sorry for not looking closer before asking. 

When I have some time I'll do some benchmarks. We have an MPC8548 Rev. 2  as well, but for our use case CPU load caused 
by software checksumming might weigh more than the throughput loss.  
We'll have to benchmark CPU usage in that specific case as well. 

Can you tell me what you use internally to benchmark throughput ? netperf ? 

Thanks, 
Christopher
Robert Craig
06/02/2008 11:41 AM
post8655
RE: RE: devnp-mpc85xx: Tx csum capabilities ?   
Hi Christopher:
	I've been using ttcp internally to get quick basic measurements but
we plan to use netperf for official benchmarks.

	Robert.

-----Original Message-----
From: Christopher Pohl [mailto:christopher.pohl@etas.com] 
Sent: Monday, June 02, 2008 11:39 AM
To: drivers-networking
Subject: Re: RE: devnp-mpc85xx: Tx csum capabilities ? 

Hi Andrew, 

thanks for the in depth explanation. 

I didn't see that there is a command line option to enable it, sorry for not
looking closer before asking. 

When I have some time I'll do some benchmarks. We have an MPC8548 Rev. 2  as
well, but for our use case CPU load caused by software checksumming might
weigh more than the throughput loss.  
We'll have to benchmark CPU usage in that specific case as well. 

Can you tell me what you use internally to benchmark throughput ? netperf ? 

Thanks, 
Christopher



_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post8654

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems