Receive task crash on Etherlink driver (elnk.c)

[Chris Johns]

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