lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Struct packing/alignment problems


From: Timmy Brolin
Subject: Re: [lwip-users] Struct packing/alignment problems
Date: Sat, 01 May 2004 23:13:58 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Leon Woestenberg wrote:

Hello Timmy,

address@hidden wrote:

Ok, I have improved the performance of my ethernet driver and written a simple ftp client for lwip. I transfer a 50,000,000 Byte file from onboard SDRAM to a war-ftp server running on a PC. (File is written to disk on the PC) I use TCP copy, so each packet is copied from SDRAM to internal RAM prior to transmission.
The DM642 board is connected to the same 100Mbps switch as the PC.
With this setup I get 30.9Mbit/s.

There are however still things to improve in my ethernet driver, so I expect the performance of a fully optimised system to be at least equal to bf3Net.

Wow.

Can you release the DSP port and/or the adaptations you made to lwIP
to make it work for your DSP/compiler, or is this a closed source project?

Leon.

I have basically just written a ethernet driver and applied the alignment patch. The driver is far from complete. Outgoing packets are now DMAed directly from the pbufs to the EMAC, but incomming packets are DMAed from the EMAC to a intermediate buffer, and then copied to the pbufs. The DSP/EMAC hardware support DMA queueing of both incomming and outgoing packets. I do not utilize this feature yet. I suspect that queueing of packets will result in a significant performance increase. Right now, the low level output routine stalls in a loop if the previous packet has not yet been sent. Since interrupts are disabled while in this routine, no packets can be recieved during this time. If more than one packet arrives during this time, it gets dropped. And as we all know, dropped packets are not very good for performance :-)

I'am basically in charge of this project, so I might release the driver when it is a little more complete. Of course, if anyone on this mailing list actually have the DM642 hardware and want lwip to run on it or help improve the driver, then just say so and I will release it in it's current state. But I don't see the point of releasing a ugly piece of code if no one actually have any real use for it anyway.

Timmy





reply via email to

[Prev in Thread] Current Thread [Next in Thread]