| > 1/ TX Buffering: set size of TX ring buffer via socket option.
|
| The size of the TX buffer is interesting in applications which want to do
their
| own queue management. That is, real-time applications that would prefer
| dropping certain packets and re-order other packets based on the state of the
| session. We are used to the standard UNIX "push" model where you shove
stuff in
| the kernel via write. Perhaps a different architecture would be for the TX
| buffer to be in user-land and the kernel to pull from it. There is a lot of
| overhead [context-switch] added, but there might be a good way of coding
this.
| By doing so, the application chooses exactly what to send and when. Perhaps
| this is equivalent to a 0 TX buffer size.
|
| Alternatively, there could be an API for managing the TX buffer in the
kernel,
| or maybe tagging packets with an expiry time or something. The bottom line
is,
| that other than just regulating the TX buffer size, there might be smarter
| things that we could do and may turn out to be useful. Giving the
application
| the power to control what is sent and when, in accordance with the CCID, will
| allow the application to make use of all of DCCP's benefits.
I went through Lai's paper again and read Ian's code: no need to go into
user-space,
thanks to Ian's efforts, the same packet ring principle is already in the
kernel.
Things that would be good to work on (imho) are:
* Notification Mechanism Between CCID <==> Main Module
The Lai implementation used a hybrid polling / asynchronous notification
principle,
which involved setting a flag and using a syscall. The mechanism you
suggested
earlier sounds very interesting - if you have any patches, could you make
them
available via your website please?
* Setting Size of TX Buffer
This relates to the second paragraph above. There are simulations which
show that
the size of the TX queue (currently infinite) influences the packet drop
rate.
For further work, it would be good to set an upper limit on qlen.
As you say, with qlen = 0, one could disable in-kernel buffering if desired.
Wouldn't it then be that dcccp_sendmsg() either blocks or returns -EAGAIN
if the write_queue's qlen is > maximal value (special case for 0).
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
