>-----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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
