Networking

MBufManager

MBuf Scavenging

MBufManager has been updated to address problems with exhaustions which are common when network speed and packet processing speed differ by a significant margin. When MBufManager discovers that not enough space remains to perform an allocation it will request that clients obtain more space through the Service_MBufManagerStatus 'scavenge' (reason code 2). Clients should respond to this service by releasing MBufs which they do not need for their continued operation. The number of MBufs released is not important, and clients may wish to release only a single chain per request. Usually the MBufs released will contain cached data which can be reconstructed or incomplete buffered network data which will be retransmitted.

This allows the MBufManager to recover from low memory situations. See the Internet document for the specific behaviour of the Internet module.

The statistics returned by the *ShowStat tool (and other statistics capable interfaces) now includes the number of successful scavenges. Where such scavenges are counted, this indicates that the system has recovered from a situation where previously an MBuf exhaustion would have been reported. MBuf exhaustion only occurs when no clients can return MBufs to the manager on a scavenge call.

Service_MBufManagerStatus 2

On entry

   R0 = reason code (2); defined reason codes are:
         0 = module has started
         1 = module is stopping
         2 = scavenge request
   R1 = service call (&A2)

On exit

   R0, R1 preserved

This service call is issued to request that clients release any spare MBufs such that MBufManager may fulfill an allocation request.

Larger MBuf allocations

Under earlier version of MBufManager the amount of space allocated to the MBufManager was fixed at 128K. The minimum allocation is now 512K, and increases with the size of memory up to a maximum of around 5M. This increase may not be necessary for the vast majority of users, but for high network use it may prevent the slower scavenge operations and thus speed up transfers.

This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.

HTML document version 1.03 3rd November 2015