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 :)
Yann. 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > > -- View this message in context: http://www.nabble.com/Packet-receive-in-ISR-for-emac-device-driver-tp25755928p25811682.html Sent from the lwip-users mailing list archive at Nabble.com. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
