Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue

[Alain M.]

address@hidden escreveu:
> Alain M. wrote:
> > My suggestion would be to create a compile time option:
> > a) keep messages n separate pbufs
> > b) allways concatenate if possible.
> >
> > There is a real trick behind that: if you have a 32 bit arch like ARM, 
> > it can be a lot faster if there exists a function concat_data or 
> > concat_pbufs that by default is memcpy, but is optimyzable. I have a 
> > book that shows up to 5x speed increment for such functions (without 
> > even using asm)...
>
> Sorry if I'm being dumb,

You are surely not being dumb, just I am not explaining right ;)

> but with concatenate, do you mean keep all data 
> for one segment in a single pbuf?

Yes, and a bit more... The problem gets worse on 32 bit arch like arm7 
that only operate in 32 bit aligned chunks. If independent write blocks 
are not a multiple of 4 bytes, they will have to be concatenated later 
on. So it might be just as well to do that early. And it is no use 
atempting zero copy in that case too, for that same reason.

> I think a compile time option for that 
> is not too bad, since b) has the potential to waste memory when sending 
> only small packets (unless you set the MSS real low, of course).

Yes, lwip is aimed a at very different archs. If there is a pbuf module, 
with some block operation macros, all defaulting to standard C functions 
or lwip functions, the user may then determine which will be worth while 
optimizing.

AND, we have to keep in mind that lots of systems are much simpler: I am 
buiding a system where I send only small packets with a single write and 
wait for confirmation for each one...

Alain