[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: Yann Suisini
Subject: Re: [lwip-users] Packet receive in ISR for emac device driver
Date: Thu, 8 Oct 2009 14:09:35 -0700 (PDT)

Thanks for you answer !

Yes you're probably right.
Currently I remove the interrupt ISR because it's not as useful as I thought
Maybe I'll use it in order to improve the reactivity to received frames in
an RTOS context .
Moreover , after a deep read of the MAC part off the lpc , It seems easy to
use it because the exclusive access to the buffer pointers are managed by
the hardware . 
The tricky part for the driver is in fact the RT/TX management of fragmented
packets :)


Mike Kleshov-2 wrote:
> 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
> all.
> - mike
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

View this message in context: 
Sent from the lwip-users mailing list archive at Nabble.com.

reply via email to

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