[Top][All Lists]

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

Re: [lwip-users] Lwip UDP performance

From: Christiaan Simons
Subject: Re: [lwip-users] Lwip UDP performance
Date: Fri, 24 Mar 2006 09:36:49 +0100

Aidan wrote:

> I'm using the raw api (single threaded) on a Nios2 processor runningat 50
> I'm having trouble getting lwip to process udp packets at a high enough

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
> and I've tried increasing them with no effect:

Increasing buffers wont't improve the achievable UDP througput for small

> 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
> 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
> 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.


Christiaan Simons

Hardware Designer
Axon Digital Design


reply via email to

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