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

[Bill Auerbach]

>-----Original Message-----
>> 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.

There is one big advantage of using a fixed pool of receive pbufs that the
ISR just loops through as needed (a circular queue of these pbuf pointers
works well): performance!  There is a significant runtime hit calling
pbuf_alloc per packet over not having to call it.

Bill