[Top][All Lists]

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

Re: [lwip-users] Packet receive in ISR for emac device driver

From: Mike Kleshov
Subject: Re: [lwip-users] Packet receive in ISR for emac device driver
Date: Thu, 8 Oct 2009 18:47:22 +0400

Hi Yann,

> In the first case the RX buffer descriptors of the MAC controller is done
> totally in the ISr. In the second case, I can only update descriptors to
> release the MAC buffer in my_netif->input. But then there could be
> concurrency access from ISR and main thread :-/ Is it possible to avoid to
> enable/disable interupt ? ( on ARM it's a global disable / enable ...).

The way I implemented zero-copy frame reception using scatter-gather
DMA is like this:

1) allocate pbuf's for the receive DMA controller in the main thread
2) the DMA controller fills pbuf's as packets are received
3) when polling for new packets in the main thread, the buffer
descriptors are analyzed, frames are collected and passed to higher
levels of the stack, then go to step 1

There is no need to have a receive ISR with this approach. You have to
allocate enough pbuf's in order to avoid dropping packets between
calls to the poll function. Basically, you allocate enough pbuf's for
worst-case conditions (many incoming frames.)
By using the receive interrupt, you make your pbuf allocation more
dynamic. You would allocate just enough pbuf's to last until you
process the receive interrupt. The ISR would collect the received
frames and allocate more pbuf's. You cannot pass the received frames
higher up the stack from the ISR, so they would pile up. In order to
allocate pbuf's from the ISR, memory pool management has to be
protected from the interrupt.
Is my understanding of the problem correct? If so, I don't think the
interrupt approach is justified. It gives you the questionable
advantage of having more free pbuf's when incoming traffic is low. You
must have a plan how to use this free memory in order to turn it into
a real advantage. When the traffic is heavy, there is no benefit at

- mike

reply via email to

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