[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #7040] Work on tcp_enqueue
From: |
Iordan Neshev |
Subject: |
[lwip-devel] [task #7040] Work on tcp_enqueue |
Date: |
Tue, 03 Feb 2009 09:18:15 +0000 |
User-agent: |
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727) |
Follow-up Comment #13, task #7040 (project lwip):
I can confirm that by sending
MSS-sized blocks of data I gained huge
performance boost. My application
generates small chunks of data (20-30)
bytes, which I cached in a MSS-sized
application buffer (not a pbuf).
I'm sending files over GPRS connection
and I am saturating the link, so I
do not need zero-copy.
At first I accomplished transfer rate of
at most 200-300 bytes/sec. Now I'm sending
3-3.5 KBytes/sec :)
At application level I use something like this:
int my_enque(*pcb, u8_t *src, u16_t len, u8_t push_flag);
Most of the times it is called with len = 20-30, push_flag= FALSE.
These bytes are accumulated in the buffer and
when it reaches MSS, I call tcp_write() and tcp_output()
to send it (note: I do not call directly tcp_enque()).
When I want to send the data eventhough the temp buffer
is not filled up to MSS, I pass push_flag = TRUE;
This is used when I'm enqueing the last chunk just
before I close the file and also when I send commands
to the FTP server over the control connection.
Maybe it wold be best if I add the small amounts of bytes
directly to the last pbuf. Then I should not
need the temp buffer any more but I did not want to
touch the core.
The price I have to pay is the extra MSS-sized buffer
and very small amount of code which is not problem
in my case. This approach does not support zero-copy,
but even if it did I would not be able to benefit from
it since the GPRS net is extremely slow and the RTT is
huge compared to Ethernet (an ACK comes afte [500ms - 30-40 sec]!!!
To me integrating somewhere in
the stack something like this:
1. if( len > pcb->mss )
len -= len % pcb->mss;
2. Add len bytes to current pbuf
3. ...
looks pretty good. Everyone should benefit
from this change.
I'm a bit conservative about changing the API.
Also, I don't think that tcp_sndbuf(pcb) should
return a multiple of MSS.
We could add new function which does what my_enque()
does. It should be
implemented in different ways with #ifdefs according to user
needs. So everyone would be free to chose which
approach is best for his application and if he
wants to use my_enque at all because this works for me,
but for most of you it will not.
Greetings,
Iordan
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?7040>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [lwip-devel] [task #7040] Work on tcp_enqueue, Bill Auerbach, 2009/02/02
- [lwip-devel] [task #7040] Work on tcp_enqueue,
Iordan Neshev <=
- [lwip-devel] [task #7040] Work on tcp_enqueue, Jakob Stoklund Olesen, 2009/02/03
- [lwip-devel] [task #7040] Work on tcp_enqueue, Jakob Stoklund Olesen, 2009/02/04
- [lwip-devel] [task #7040] Work on tcp_enqueue, Simon Goldschmidt, 2009/02/05
- [lwip-devel] [task #7040] Work on tcp_enqueue, Jakob Stoklund Olesen, 2009/02/06
- [lwip-devel] [task #7040] Work on tcp_enqueue, Jakob Stoklund Olesen, 2009/02/06
- [lwip-devel] [task #7040] Work on tcp_enqueue, Charles Landau, 2009/02/13