lwip-members
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-members] Pbufs


From: Jani Monoses
Subject: Re: [lwip-members] Pbufs
Date: Wed, 26 Mar 2003 17:14:34 +0200

I thought about pbufs lately and I think that some ideas that were raised
before are worth noting and implementing sometime.
Leon's suggestion of pools with sizes of 2^X and Kieran's payload /header 
separation
both seem improvements.
I thought of having only pool type pbufs with special predefined sizes (would 
this not
be as good as your mem_pool for header Kieran?) and also with application 
definiable sizes.

An app or lwip submodule could 
register_pbuf_pool(struct pbuf_pool *)
where pbuf_pool would define pool size/pool count, operations suchs as 
pbuf_alloc free etc.
This way RAM pbufs could be implemented over pool pbufs.
For pools such as current only the size would be app defined the operations 
would be the same
So you can have 2^X or ethernet_hdr_sized pbufs.
And apps and lwip modules wuld be changed to allocate from their respective 
pools.
This would ease on locking too for sure.

> Thanks for doing the pbuf_realloc thing - something I've been meaning to
> do for some time!
> 
> I've made a number of other additions to pbuf code in the last few weeks.
> I added a PBUF_HEADER type which simply allocates a pbuf large enough for
> a TCP/IP header from a new memp pool.  Allocating this size of pbuf is a
> common operation when applications are passing in their own data (in the
> way that has lead to the PBUF_REF suggestion), so it made sense to me to
> make this fast.  It's also particularly useful for me as the network
> delivers the packet headers and payloads separately.
> 
> If anyone else is interested I can merge this into the main tree without
> too much trouble, but thought I'd ask for comments first.
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-members mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-members




reply via email to

[Prev in Thread] Current Thread [Next in Thread]