New uTasker Version for Kinetis with advanced IPv6 features available

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

New uTasker Version for Kinetis with advanced IPv6 features available

1,276 Views
mjbcswitzerland
Specialist V

Hi All

 

The uTasker Kinetis V1.4.1 release in now available. This release has quite a lot of new features and also interesting extensions to its simulator.

Full release note details are at http://www.utasker.com/forum/index.php?topic=1721.0

 

Due to additional IPv6 TCP features, including 6in4 tunnelling making optimal use of the Kinetis Ethernet checksum offloading, the following Tower Kit IPv6 video has been prepared to go with it: http://youtu.be/BMPXhtoUeJo

 

Below is a screen shot of the TWR-K70F120 operating in the simulator with support for LEDs, touch inputs and buttons on the board.

 

Regards

 

Mark

 

TWR-K70F120 simulation

 

 

 

0 Kudos
6 Replies

607 Views
PaoloRenzo
Contributor V

Hi Mark

 

I think one of the great but unknown features of our Kinetis ENET controller is the IP/TCP/UDP/ICMP automatic checksum generation/checking in hardware. According to a document I read once, this is one of the main performance bottlenecks TCP/IP stacks have.

 

I only found a small reference in the Kinetis doc for uTasker:

 

"An interesting feature in the EMAC is the new support for IP checksum offloading. This
allows the HW to automatically check or generate checksums for IP, ICMP, TCP and UDP
frames (IPv4 and IPv6), which make the operation much more efficient than when SW needs
to do this – see the following for some figures showing the loading of check sum calculation:
http://www.utasker.com/docs/uTasker/uTaskerBenchmarks.PDF"

 

BTW, the benchmark reference is out of date :smileysad:

 

I did a small benchmark using a TCP/IP stack with/without checksum in hardware and software and I have an average performance increase of 25% (incoming and outgoing packets) when this feature was turned on. Some other HW features were turned on as well like Ethernet header alignment from 14 bytes to 16 bytes, for example. Another great feature, btw.

 

This considering you have IPv6 support (I checked 3 other TCP/IP stacks and 2 of them don't have this yet, the third one is still in experimental stage), this is a very good feature to add in your document, in my humble opinion. Would contact you by a private message to continue discussing about this

 

There are many other features our ENET controller has such as: IEEE1588 support, dma requests and a great FIFO handling by the use of a few registers, that unfortunately many users don't know.  But this will be in another thread. Enough for now :smileyhappy:

 

Great work btw

 

Thanks!

0 Kudos

607 Views
igor-imx
Contributor IV

Sorry to hijack the thread, but i have a question to Paolo Renzo.

You have mentioned you benchmarked the TCP/IP stack with and without TCP offloading settings.

 


Paolo Renzo wrote:

 

I did a small benchmark using a TCP/IP stack with/without checksum in hardware and software and I have an average performance increase of 25% (incoming and outgoing packets) when this feature was turned on. Some other HW features were turned on as well like Ethernet header alignment from 14 bytes to 16 bytes, for example. Another great feature, btw.

 






Did you do this with MQX RTCS?

Im using MQX 3.8 with K60 and MQX RTCS as a tcp/ip stack and would love to know how to enable the performance enhancements you have mentioned (hardware checksum + header alignment).

Can you please share the knowledge? :smileyhappy:

thank you 

0 Kudos

607 Views
PaoloRenzo
Contributor V

I did it with lwIP tcp/ip stack. Basically you have to leave with zeros the checksum area for all the packets. Software no longer calculate these fields. Addionally this feature is enabled in ENET registers.

 

For more details you can find the details in K60 example code. (freertos_lwip) Just follow the preprocessor macro defining "hardware offload" and you'll get all the changes!

 

Can you post what you get after all the changes?

0 Kudos

607 Views
igor-imx
Contributor IV

Thank you for the info.

I will try to get it going and will definately post the results.

 

thanx again

0 Kudos

607 Views
mjbcswitzerland
Specialist V

Hi Paolo

 

I have a couple of extra notes that I forgot to add in the first post:

1) The IPv6 user's guide is here: http://www.utasker.com/docs/uTasker/uTaskerIPV6.PDF

2) The project code as configured in the video (with dual stack, HTTP, FTPclient and server, SMTP, Telnet, USB device, UART with [big] command line menu plus various other protocols and peripherals) occupies 75k Flash and about 30k RAM, whereby the IPv6 part takes up about 5k of this code space

 

Yes the ETH HW acceleration features are great and do result in big improvements in efficiency. The benchmark that was quoted was primarily to point out the effect of the check sum calculation loading on the SW and is still relevant (and the us values are also still valid for the Coldfires, on which it was was tested some time ago). I will however add comparisons for the Kinetis in the near future so that the general speed improvements (there are many other speed improvements too) can be compared.

 

Also, as noted in the video, the project was entirely develeoped and tested in the uTasker simulator which allows all IPv6 stuff to be tested in real time on the PC (as well as the complete tower kit to be simulated in fact!) - I couldn't really imagine developing such things on the HW target using the debugging tools - it is of course possible, but hugely time consuming and probably would result in a nervous breakdown on the way...;-)

 

Regards

 

Mark

 

 

 

 

 

 

 

0 Kudos

607 Views
mjbcswitzerland
Specialist V

Paolo

 

OK. I updated the Benchmark document: http://www.utasker.com/docs/uTasker/uTaskerBenchmarks.PDF so that it compares the effect of using check-sum offloading and also against the M52235 running at 60MHz.

 

A summary of the test results shows that the K70 (or K60) can handle UDP echos with 1024 bytes payload and an extra 1024 byte memcpy() in the application call back doing the echo in 96us. The M52235 requires 1'142us to do the same when UDP checksum is used.

 

The checksum offloading improves the UDP handling efficiency by almost 1000% (eg. the processing of the received UDP frame requires 130us when the checksum calculation needs to be performed in code (using standard algorithm) but only 13.6us if the calculation is done by the Ethernet HW.

The results show however that also the use for DMA for internal buffer transfers is relevant since this increased such operations by almost 200%.

As comparison - as UDP echo server (based on 1024 byte frame payload and UDP checksum enabled) on the K70 (K60) can achieve about 2.6MByte per second with pure SW techniques. With DMA and checksum offloading over 10MBytes/s are possible.

 

[An M52235 operating at 60MHz achieves about 2.8MBytes/s but only when UDP checksums are disabled - with checksum it is limited to 850kBytes/s]. The TCP cases are similar and, since it is not possible to disable checksum operation, it shows that the Kinetis can outperform the Coldfire by a factor of x10].

 

Regards

 

Mark

 

 

0 Kudos