Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
ACC Programmer's Reference Guide > Chapter 3 ZCOM Tables and Data Structures

Data Buffer Pool

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

The data buffer pool is part of the ZCOM memory structure. The size of data buffer pool is defined in the TTGEN configuration file. The data buffer pool is a global resource within the ZCOM subsystem.

Organization of Buffer Pool

The buffer pool is a contiguous block of memory divided dynamically into a number of variable length buffers. When the ZCOM subsystem is initialized, the single buffer pool is divided into 2 buffers: one small dummy buffer which stays in the free queue all the time, and a main buffer that contain all the remaining free space from the memory block. The size of the dummy buffer is smaller than the minimum size in buffer allocation, so it will never be released from the free pool. The two buffers are linked together in a circular list. This arrangement is to minimize the updates to the free queue header (see next paragraph), hence the buffer management code can be more efficient.

The access to the buffer pool memory block is via the free queue header. The free queue header is the first queue header (header 0). The header contains a pointer to the first free block, the last free block, and some statistics that relate to the use of the free pool. These include the number of blocks in the pool (initially 2), the total number of bytes in the pool, and the number of accesses to the pool to get a memory buffer. The buffer pool structure is shown in Figure 3-8 “Buffer Pool Layout (when first initialized)”.

Figure 3-8 Buffer Pool Layout (when first initialized)

Buffer Pool Layout (when first initialized)

Free Buffer Header Structure (zfbh_type)

The buffer header contains information about the buffer as well as a linkage to the next buffer. (zbhd_type). See Table 3-30 “Free Buffer Header Structure (zfbh_type) and Table 3-31 “ Buffer Structure (zbhd_type).

Table 3-30 Free Buffer Header Structure (zfbh_type)

Field Name

Field Description

Field Type

Size (Bytes)

BFFLAG

System flags (length & status)

uns.int

4

SPARE1

Reserved, not used

int

4

QHEAD

Pointer to next buffer on queue

pointer

8

BFPREV

Pointer to previous buffer on queue

pointer

8

 

Table 3-31  Buffer Structure (zbhd_type)

Field Name

Field Description

Field Type

Size (Bytes)

BFFLAG

System flags (length & status)

uns.int

4

BFLEN

Buffer length in bytes (data portion)

int

4

BFLINK

Pointer to next buffer on queue

pointer

8

BFDATA

Pointer to 1st byte of data in buffer

pointer

8

BFRESP

Pointer to response record

pointer

8

 

BFFLAG - Buffer flags

The use of the memory pool is based around a buffer flag field that indicates the size of a memory block as well as containing a flag that indicates whether the block is currently in use. This field appears at the start and end of each buffer segment. This field is 32 bits long. The size of the buffer is always a multiple of 8-bytes (so each buffer is 64-bit aligned). This allows the low order bit to be used as the Used flag (ZCOM-BFFLAG-BUSY). This field is located at both the start and end of the block, so that adjacent blocks can be identified from either end of any block.

Table 3-32 Buffer flags BFFLAG Field

31

1

0

Block Size

 

Used flag

 

Block size

The size of the memory block in bytes (including buffer flags). The block size is always a multiple of 8 bytes. However, the lower (least significant) bit is used to indicate whether the block is used or not, and is not included in the size of the block.

Used flag

=0 Block is unused,

=1 Block is used

Dummy Used flag - Start and end indicator of memory pool

This is a dummy buffer flag at the beginning and end of the buffer pool area. The used flag is set to indicate this block is used, so the coalesce algorithm will think there is a used block before the start of the pool, and after the end of the pool. The size is set to 0xFFFFFFFE so that these dummy blocks can be distinguished from the legitimate ones.

BFNEXT - Pointer to next buffer on queue

BFPREV - Pointer to previous buffer on queue

These pointers are used to link all the free blocks within the memory pool, to form a circular list. The free queue contains the initial pointer to the first and last free block. The value in the pointer is the address of the buffer flag (i.e., the address of the next block pointer in the block).

BFLEN - Buffer length in bytes (data portion)

This field contains the usable memory size (in bytes) within the buffer. The usable area of a buffer is indicated by its location, BFDATA, and its size, BFLEN.

BFLINK - Pointer to the next buffer on queue

This is the buffer linkage to the next buffer in the chain. It contains the address of the first field (i.e., BFFLAG) of the next buffer. If this is the last buffer on the list, it contains NULL.

BFDATA - Pointer to the buffer data area

This field contains the memory address where the message header resides within the current buffer. This memory address is set up such that the message data, which follows the message header, will be aligned properly depending on its uses (e.g. for inbound DMA, it must be on a 64-byte boundary). Usually, a buffer will have unused area before and after the message. In case of buffer for inbound DMA operation, the sufficient unused area is allocated to satisfy the DMA operation without overflow into the next buffer.

This field is set up by the ZCOM subsystem when a buffer is allocated from the buffer pool and will not be modified until the buffer is released to the buffer pool.

BFRESP - Pointer to response record

This field is valid only when the buffer is associated with a send-and-wait operation. It contains the address of the response record for the waiting program. On completion of such a request, the LDM uses this field to locate the response record, where the return status is placed.

For other types of operation, this field contains invalid data.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2000 Hewlett-Packard Development Company, L.P.