Re: [lwip-users] LWIP/WIN32 UDP performance (throughtput)

[Mason]

Simon Goldschmidt wrote:

> Sorry for not answering that post, I meant to, but somehow it slipped 
> through...

I was afraid to bother you by asking too many questions  ;-)

> Mason <address@hidden> wrote:
>
>> I don't think it's possible to use mem_malloc as a packet
>> buffer allocator, as there are other types of uses, e.g.
>>
>>   dhcp = (struct dhcp *)mem_malloc(sizeof(struct dhcp));
>>   autoip = (struct autoip *)mem_malloc(sizeof(struct autoip));
> 
> These are not used if you init autoip and dhcp correctly
> (dhcp_set_struct(), autoip_set_struct()). I know that's not a good
> solution and we should add pools for it.

This is all voodoo and black magic to me. It's very cool that you
are so nice to explain stuff when questions are asked, but it
really feels like there is a lot of high-level documentation
missing, wouldn't you agree?

>> What I'd like is to be able to "redirect" pbuf_alloc to use
>> my buffer allocator, but the pbuf struct and the payload buffer
>> would not be contiguous, which violates the implicit assumptions
>> of PBUF_RAM pbufs, IIUC.
>>
>> Have things changed on that front?
> 
> No, not yet. What's missing there are two things:
> a) redirecting pbuf_alloc() to a custom function and
> b) having a PBUF_REF-like type where pbuf_header works in both directions.
> 
> It shouldn't be too hard to implement, but I haven't even found the
> time to work much on the 1.4.1 release-related things, lately, so it
> might take some time until we get there :-(

I think I'll err on the safe side, and make my port do the extra
memcpy in the initial version. Then I can profile the different
use-cases, and if there is a performance problem, then I'll see
how to get rid of the copies. (Probably in 2-3 months)

>> If no, that means I have to memcpy every outgoing frame, right?
> 
> Not if would redirect mem_malloc(). However, your platform would need
> to allow the pbuf struct and payload be in contiguous memory, then.

I've been meaning to talk to you about this issue.
Since I use DMA, there are hard constraints on the location of the buffer.
It must start at an address multiple of 32 (cache line aligned) and the
length must be a multiple of 32, and we must purge the appropriate lines
from cache before the DMA operation.

I suppose I could allocate 32 more bytes to hold the pbuf struct and
fudge the pointers to make the payload start on the right boundary,
but you've said that pbuf_header could move the start of payload,
or something like that... More voodoo stuff.

Like someone said on the list, I think lwip wants control over
the packet buffers, which is a problem when a driver also needs
control over the buffers.

-- 
Regards.