Receive task crash on Etherlink driver (elnk.c)
chrisj at rtems.org
Mon Jun 3 23:00:57 UTC 2013
> 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
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
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.
More information about the users