Pond Configuration Reference

At the moment, there is only one pond in the Comms Frameowrk. This pond manages the pools of MBufs available to the device drivers and to the Comms Framework components. The pond is initialised by the Root Server when the device starts. For each pool, you specify the initial and maximum number of buffers and the size of these buffers by specifying options in the c32start.ini file. This file is located in z\private\101f7988.

Options

To describe the pond, define MBufSizeAllocInfo <n> for each pool.

Each MBufSizeAllocInfo <n> line describes a pool of RMBufs. The <n> suffix must be a unique number.

# MBufSizeAllocInfo[n] = size, initial, growth, threshold
# for example 
MBufSizeAllocInfo1 = 128, 128, 64, 48 
MBufSizeAllocInfo2 = 1600, 64, 16, 12 

The following table lists theMBufSizeAllocInfo parameters in the order they must be specified:

The initial allocation of memory is defined by the sum of the initial allocations from each of the MBufSizeAllocInfo <n> specifications.

If no MBufSizeAllocInfo <n> options are provided, the system builds a default pool of 128-byte buffers, initially set at 128 buffers, with a growth of 64 buffers and a threshold of 40 buffers.

Recommendations

Growth thresholds are typically set at around 25% so that the background allocator can allocate new buffers before the current pool is exhausted. Systems where there is potential to use buffers in sudden bursts should set the threshold to a higher number or start with a larger initial number of buffers.

Legacy code may rely on 128-byte buffers. 128-byte buffers also work well as the small buffers used when adding headers to the data. You should always specify a pool of 128-byte buffers in your c32start.ini file. You should also avoid having a pool of buffers smaller than 128 bytes, because some legacy code may assume 128 bytes as the minimum size.

The Maximum Transmission Unit (MTU) is an important characteristic of Communications protocols. The MTU is the maximum size of the data packet in a given layer. For example, the Ethernet protocol fixes its MTU to 1,500 bytes, and the 802.11 protocol has a 2,272-bytes MTU. To ensure that incoming data can be written into a single buffer rather than split, you need to specify your pools according to the protocols in use in your system. For each of these protocols, the pond should contain a pool with buffers as large or larger than the MTU. Protocols with similar MTUs usually share the same pool, to avoid increasing the allocation time with searches through too many pools.

Increasing the number of pools increases the time required to fulfil an allocation request. Therefore, you should keep the number of pools small. You need to find a balance between searching many pools for a single adequate buffer and searching fewer pools but having to construct a chain of buffers to fulfil an allocation request.

Note: if the c32start.ini configuration specifies more memory than the device has available, or an impossible combination of initial pool sizes and total pond size, the pond initialisation will fail and the Root Server will panic during device start-up.

[Global]

MBufSizeAllocInfo1 = 128, 128, 64, 48
MBufSizeAllocInfo2 = 1600, 64, 16, 12