[ds6-devel] io_stream scheduling refactor

Mauro Tortonesi mauro@deepspace6.net
Sun Dec 29 13:55:23 2002


On Sun, 29 Dec 2002, Chris Leishman wrote:

> Hi all,
>
> I've just commited another minor refactoring to the branch
> "chris_refactor_291202".
> The major points are:
>
> 1)
> io_streams have been modified to handle their own buffers and
> scheduling.  When an io_stream is initialized, it is given a circular
> buffer to read into and write out from.  Methods have also been added
> so that the io_stream can report whether it needs to schedule itself
> for read or write.
>
> This model has the advantage of removing all the buffer management and
> scheduling nuances out of the main select loop (readwrite).  It now
> allows for the scheduling algorithm to vary as the needs of the
> io_stream vary - allowing for mtu's and nru's to be heeded.
>
> It also negates the need for the use of temporary buffers for the
> receipt of UDP packets.  By using the NRU (miNimum Receive Unit), we
> can specify the amount of data that must be able to be received in
> order to allow reading to occur.  The default NRU for UDP sockets is
> 65536 - the maximum MTU a remote host can use.
>
> I have chosen a very simple scheduling model for the current
> implementation.  At the top of each select loop (before calling select)
> each IOS is checked to see if it should be scheduled for read or write
> (using ios_schedule_(read|write)).  If this returns a valid
> filedescriptor, then that is used in the call to select - and if it is
> ready then the appropriate ios_(read|write) method is called for that
> IOS.  The ios_(read|write) method takes care of socktype specific
> notions (eg. using read v's recv or write v's send).
>
> This approach is simple, but could be argued to be more expensive
> (though it isn't really that bad).  An alternative would be to provide
> each IOS with a callback by which it can change its scheduling
> requirements when (and only when) it needs to.  This would be more
> efficient than checking the requirements in every loop, but
> significantly more complex code wise.  For now I didn't think it was
> worth it, but comments would be appreciated!
>
> 2)
> I've modified the connection_attributes to also contain the buffers
> that are used for local and remote.  This has the advantage of being
> able to configure their size before calling readwrite (and is also
> needed in order to init io_streams).
>
> The buffer size for the remote buffer can now be set using the "-b
> size" option.
>
> 3)
> The IOS now specifically contains the MTU and NRU of the connection,
> and these are heeded.  The MTU can be set via the "-m size" option, and
> the NRU via the "-r size" option.  I'm not sure if these are the best
> mnemonics - thoughts?
>
> This will also allow for easy integration of PMTU discovery.
>
>
> Anyway, give your comments.  I'd like to roll this into the HEAD, but I
> figure you should all get a look first.

i will examine the new code in the afternoon.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@deepspace6.net
				mauro@ferrara.linux.it
Deep Space 6 - IPv6 on Linux	http://www.deepspace6.net
Ferrara Linux Users Group	http://www.ferrara.linux.it


More information about the ds6-devel mailing list