Receive task crash on Etherlink driver (elnk.c)

SAeeD salpha.2004 at
Sun Jul 14 12:41:50 UTC 2013

Finally, after much investigations I found out something.

First, there is a bug in elnk driver as reported by Greg Menke at
2003-07-18 (described in c/src/ChangeLog)

Second, there are some differences between elnk.c and if_xl.c (in
FreeBSD). The major difference I noticed, was that if_xl.c locks a
mutex before each driver action (ISR, Network Tasks, start function,
etc.) and unlocks it at the end.
I didn't modify elnk.c according to this observation to see the impact
but I guess it may make things better in elnk driver.

I hope this helps or at least prevents future usage of elnk.c!!


On 6/4/13, Chris Johns <chrisj at> wrote:
> SAeeD wrote:
>> 2. What happens when the received packet rates exceeds so very much
>> that rxDaemon can not update curr_rx_md before arrival of a new
>> packet?
> You need to size the receive queue at the hardware layer (DMA chains) so
> you can meet the burst rate verses the rx task latency you might see.
> Then you need to size the network stack pool sizes, and there are a few
> configurations here, to meet the sustained data rate of the network.
> Finally you need enough processing power to be able to process the data
> or you will at some point in time run out of buffers and start to see
> data dropped.
> You need to set the priorities to give the networking tasks enough of
> the processing time to process the incoming load. The hardware needs to
> have enough packets available to allow the rx task to wake and start
> processing the receive queue. It is assumed the rx processing loop is
> fast enough to get the packets from the hardware and to refresh with new
> packets. If your rx task uses all the processing time to handle the
> incoming packets you will soon run out of network stack buffers. If your
> rx task can process the packets much faster than they arrive it will
> sleep and the network task will wake. This will take the input queue
> processing the data finally delivering to the user's socket. If the user
> is not blocked in the socket the data is queued else it is copied to the
> user's buffer and the network buffer released back to the pool available
> for the receive task to queue at the hardware.
>> 3. As I know, elnk uses DMA to place the received packet in the
>> memory. It places the packet in the mbuf, but what happens when a
>> packet is larger than a single mbuf? How does the DMA breaks the
>> packet to fit in a mbuf chain, rather than a single mbuf? How does
>> next mbuf address pointer set?
> I have not looked at the specifics of the elink driver. Typically the
> hardware supports DMA scatter/gather functionality. The hardware is
> either set up to scatter the packet's data across a number of mbuf parts
> or it fills a single mbuf cluster buffer. In transmit the hardware can
> gather the data in the packet in realtime from a number of buffer
> fragments.
>> Even few rays of light would enlighten me very much! :)
> I hope this helps a little.
> Chris

More information about the users mailing list