After spending most of the day tracking down the anomalies Taras reported, I've come to the conclusion that the root problem is that the design of the current buffer pool allocator makes it impossible to specify the num_bufs desired with any precision, so the "light" mod I was trying to do just isn't going to work. In the current API the application passes in a memory area that it hopes is big enough and the pool create function carves it up into some unpredictable number of buffers of the specified buf_size. To allow the application to specify the number of buffers it wants really requires a different approach, which is what I was taking with the original buffer/packet patch.
So I'm going to incorporate the new allocator into this patch but that's going to take a bit longer. Not sure if I'll be able to get this done before the weekend given the holiday. The good news is that this restructure positions us to add in all sorts of additional features as needed without requiring significant changes to the basic allocation structures. I'd really like to make use of Ola's new atomics for this since they provide the added benefit of lock-free operation for buffer/packet allocs/frees. Hopefully that patch can be merged sometime this week since the key authors/reviewers are observing a normal work week. Bill
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
