| > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
