Hello there again, thinking about it... when I replace the tcpip thread with my own thread just like I described in the other thread (which I felt was unrelated), I do very well know that pbufs can only ever by regained by calls directly or indirectly through this thread, so I have a very good idea when it is reasonable to check whether pbufs were regained (far better than uninformed polling at least), which renders this thread's question pointless (for my furth path). Apart from this problem seemingly arising for every port that does _not_ roll its own thread. Really I think it would be great if you could hook up for such events in the pbuf api.
(I'm only argumenting upon my own intermediate conclusions here, maybe these are wrong alltogether...) Kind Regards, Michael Am 04.08.2015 um 18:21 schrieb Michael Steinberg: > Hello, > > during my implementation of a zero copy port to stm32f4 I ran into some > difficulties. As in presumably all implementations, a dma chain/ring is > used to exchance data with the MAC core. I do fill the related dma > descriptors with lwip pbufs (well, custom buffers, read below). However > a situation might arise, when there is no pbuf left when a receive dma > descriptor shall be "rearmed". I could not find a mechanism where lwip > notifies me that a lwip-pbuf is available again, so I think I would have > to poll lwip for buffers, which is out of question. That's why I felt I > had to use custom pbufs, because through the custom pbuf deleter > functions I am notified in such situations. (Please correct me if I'm > wrong alltogether, I would gladly like to use lwips standard buffers, > because currently I have to manage a second "heap-like" buffer ring of > custom pbufs because of that). > > Now during my custom pbuf usage I ran across situations, were lwip would > call mem_trim or other such functions, not checking for whether the > custom-pbuf-flag is set. A notable occasion would f.e. be in line > "pbuf.c":417. In my eyes it might be a lot clearer if custom pbufs are > not indicated by a flag bit, but by their own type maybe? > > Kind regards, > Michael > > > _______________________________________________ > lwip-users mailing list > lwip-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users