Aidan wrote: > I'm using the raw api (single threaded) on a Nios2 processor runningat 50 Mhz. > I'm having trouble getting lwip to process udp packets at a high enough rate.
Sounds familiar, I've got similar problems ;-) > I'm sending udp packets to the nios2 in bursts of 16+ packets (~600 bytes) at > ~60Mbps, then leaving a break of ~40ms. The 60 Mbps is probably a > bit too fast, > but I would have thought that the 40ms break would give it enough > time to catch > up if the buffer was of a sufficient size. I've got the following inlwipopts.h > and I've tried increasing them with no effect: Increasing buffers wont't improve the achievable UDP througput for small packets. > The behaviour I've observed is that the first 4 packets of each burst get > processed just fine, but only a few of the remaining packets get through. There might be a problem in your Ethernet driver. A typical driver copies data from your chip into a pbuf-chain. This copying might slow things down. This is the place to look for improved performance. Note that there may be a delay between a receive interrupt from the driver, and the driver actually servicing the hardware. You should try to minimize both delays. (This can be hard, depending on the nature of the driver). > Currently to test performance, my application increments a counter > when it gets a > udp packet and that's pretty much all it does, so it shouldn't be > slowing it down > from that end. > > So a few questions: > * What kind of performance can I expect? What kind of peak performance? This really depends on your HW and SW architecture. > * Should lwip be able to handle 60Mbps bursts of data? Some archs might reach full wire-speed. > * Is lwip polled or interrupt driven. I've had a look at the code > and looks like > it's a bit of both... (I call lan91c111if_service(&netif); from main, the > function is part of the driver provided for nios2.) This is like the cs8900 driver design. The difficualty is in reading data the within the interrupt, this might lock-up your single threaded system (at full wire-speed). Therefore the interrupt merely indicates the chip needs to be serviced, and the reading is done from the infinite (main) loop. > * Does lwip do buffer copying or is the data passed up through the stack using > pointers? Some copying when needed, pointer referencing whenever possible. This diver places the data in the same pbuf-chain as your udp receive callback handler gets it. This is fairly efficient. > * Is there an option to disable the udp checksum check? Or is it a case of > modifying the code? I shouldn't try this. > * Any suggestions on how to get maximum udp performance? Try to improve your Ethernet driver. Try to use DMA transfers, and run your lwIP stack from a thread/task (you'll need a small RTOS) that becomes immediatly active after the Ethernet RX interrupt. I cannot recommend the lwip+uC/OS-II solution that Altera offers. It is built around the lwip sequential API: low performance, too much thread synchronisation slows it down. Bye, Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
