Re: [lwip-devel] (no subject)

[lukem . lwip]

On Fri, 19 Mar 2004, Leon Woestenberg wrote:
> I would suggest using standard C names, with lwip_ prefix, such
> as malloc() lwip_free(). The memory allocator should then implement
> those functions.

Sounds like a great idea to me. Perhaps the memory allocator could be a
part of the port instead of the main lwIP tree? This would make a lot of
sense to me. The only problem is how to support both a general purpose and
pool allocator for those that really want it (anyone?).

> What exactly did you measure? and can you post profiling results.

Custom profiling software using the itanium-2 performance counter
registers. The measurements were the percentage of performance counter
overflows which occur in a particular function. I don't want to post
profiling results because they are for our entire system, not just lwIP.

> Request/Reply type UDP connection, or bi-directional TCP traffic, etc.
> under what conditions?

It was UDP echo at over 500Mbit/s, with 7 clients.

> > coroborate my profiling results, because it appears to me that the pool
> > allocator may be a case of premature optimisation.
> >
> If that is the case, where do you think most optimisation can be
> achieved instead. Maybe we should concentrate on that?

> How about memory fragmentation?

This would need to be measured - or at least we need a good
characterisation of the allocation / free patterns under some different
workloads - in order to answer that question well.

I think the premise with which you started your message is a good one - we
should aim for maximum flexibility so that people who need to can
customise for their application.

--
Luke