Nucleus Communication Obiects

T\vo objects and sysrem calls to manipulate them have been added to the Operating System to provide an interface to the MULTIBUS [I hardware, The following sections à?lain th€ port and the buffer pool, the new objects.

'12.5.3-l Port

A port is a bi-directional communications access point for tasks running on different agents. Pofts provide a level of addressing that permits seoding data to a particular task (program) running on a board. The port is the software interface to the message passing hardware. All of the "send" and "receiven message system calls have parameters that identit' the ports that are involved in the operation.

You qeate a port with the RQ$CREATE$PORT system call. Two q/pes of ports can be ffeated, a dgjg!A!! that is used to send and receive relatively large amounts of data, and a !ig!Alpe!! that is used to send and receive control signals only. The signal port is provided for compatibility with systems that use the Message Interrupt Controller (MC).The MIC is a subset of the MPC available on earlier products.

When you create a port you speciry the following information in the system call:

. The number ofsimùltaneous transactions that can be outstxndina at the Dort.

(Ignored for signal ports.)

. What q?c of messages this port can send and receive.

. Whether tasks waiting for messages will be queued in FIFO or priority order.

. A port ID, which is a number that udquely identifies this port on this board, The user can enter this, or enter a zero which tells the Nucleus Commùnication Service to create the port TD.

. What the system should do if an oùtgoing message is too large to fit in ary one buffer available at the destination port. You can speciry that the message can or cannot be broken into pieces if it is too large to fit in a single buffer. If you speciry that messages cannot be broken into pieces, an error will be retumed if the situation occurs.

. 1\s with all system calls, you speci! wherc thc corÌdition code generated from the call should be placed.

Ports are deleted from the system using the RO$DELETE$PORT system call.

System calls have been added to provide flexibility in manipulating po s. The iollo\'r'ing paragraphs discuss these system calls.

t2-9 Nucleus Uset's Guide

EXTENDED iRMI(O II MULTIBUSO II SYSTEMS

The BQIggNNEgI system call provides a method of specirying a default destination for

messages sent ftom a port. When a port issues this ca[, it is logicaly connected to \--l another remote port. After issuing the RQ$CONNECT call, no remote destination

(socket, a two-rvord data structurc sho$n below) is specified when sending messages, because the connected port (default) is assumed.

socket LITERALLY ' SîRUCTIIRE(

hosc_id woRD, port_id IIORD)' ;

When receiving messages, any message thaî does not have this default port socket as its source is ignored. This call affects only the port that issues it, not the po.t that is connected. A remote port îhat is connected is not limit€d to sending and receiving messages to the connecting port.

The RO$ATTACHSPORT svstem call Dermits rhe forwardins of messapes. A Dort mav speciîy that all messages sent to it be forwarded to another port. In this arrangement, the port that is fo.warding its messages is referred to as the !gU@!e!l ard the port that receives the messages is referred to as the gi[k!eÉ. One level of forwarding is permitted, that is a sink port may not fo.ward its messages. The message forwarding is canceled by issuing an RQ$DETACH$PORT system ca[.

The RO$ATTACH$BUFFER$POOL sysrem call provides a port with memory resources called butrer pools (discussed in a later section.) These mernory resources are used in

re.ceiving large data messages. These memory resources cÍrn be detached from the port by \ ? using the RQ$DETACH$BUFFER$POOL system call

The RO$CET$PORT$ATTRIBUTES system call allows a task to get infomaîion about any port. The information returned is the same inforúation discussed above as being specified when a port is created, plus the following: does the port have a default socket and is it forwarding its messages.

12.5.3,2 Buffer Pools

Buffer Pools are holdiùg areas for segments which in MULîBUS II systems are ùsually \---l associated with a port. Having a pool of memory readily available to a port cuts down on

system overhead bepause allocating the existing buffers is faster than creating and deleting seqnents.

12.10 Nucleus Uset's Guide

EXTENDED iRMX@ II MULTIBUS@ II SYSTEMS

Buffer pools are empty when created. The user gives segments to the bufrer pool The segments are created using the the RQ$CREATE$SEGMENT system call The created segments are given ro a buffer pool by using the Re$RELEASESBUFFER system call.

The buffers are then used by tasks that require memory. Both MULTIBUS I arld

MULTIBUS II systems cao use buffer pools. In MULTIBUS II systems, ports requte an associated buffer pool as a holding area for messages. Any task that requires frequenr creation and deletioù of segments may imptove performance by using a buffer pool with pre-allocated segmerits.

Buffer pools incur a certain amount of system overhead in their creation. The following formula defines the amount of resources required.

(Max Buffe$ * 4) + 108 bltes = the amount of memory used by any given buffer pool.

When you creato a buffer pool you specif the following information:

r The maximum number ol buffers that can reside in the buffer oool at anv one time (8192 maÌimum.)

. \ryhether or not the buffer pool slpports data chains. Data chairis are a method of receiving messages that are larger than any siogle buffer can hold. Note that data chaining is one of two suppofed methods for receiving messages larger than any single buffer. The other method is message fragmenration.

12532.1 System Calls for Bulfer Pools

The RO$CREATE$BUFFER$POOL sysrem call oeates a buffer pool object. Each buffer pool obje.t acts as a holdirig area lor segme[ts (buifeN.) When a buffer pool is c.eated it is ùot associated with any port, see RQ$ATIACHSBUFFER$pOOL in an earlier section. Buffer pools are deleted using the RO$DELETE$BUFFER$pOOL system call.

The RO$REOUEST$BUFFER system call gets a buffer from the specified buffer pool, ldeally, the data will fit into an existing buffer; if this is not possiblq a special method called data chaining is used. Buffers are rctumed to the buffer pool using the

RO$RELEASE$BUFFER system call.

125322 Data Chains

When a buffer pool is oeated, you can set a bit in the Ihg field that specifies suppof for data chains. Data chaining is supported only on processor boards that contai[ the ADMA (Advanced Direct Memory Access) device.

Nucleùs Uset's Guide t2"tl

EXTENDED iRMX@ II M{JLTIBUSO II SYSTEMS

In buffer pools that support data chainin& if a message is too large îo fit in any single buffer, the message can be broken into smaller pieces. These pieces are placed in smaller flon-contiguous buffers and a data structure called a data chain block is used to keep track of the different parts of the message. Data chains are created automatically by the

receiving board's hardwarg but the user must extract the data by using the information in the data chain block. No element of a data chain can be longer than 64K-2 bj,tes. Figue

12-3 illustrates a data chain block and a data chain.

Data chains incur a certain amounî of system overhead ill thet creation. The rninimum data chain block size can be computed by:

(Max_elements * 8) + 2 byter Where:

Max elcments G a configuration option Maximum Data Chain Elements (MCE) from the ICU Nucleus screen.

L E N G I H B L O C K0

PTB TO

q_19 r{ !

R e s e r v e d W o r d L E N G T H O F

BLOCK 1 PTR TO B L O C K 1 R e s e r v e d F I N A L B L O C K

L E N G T H = O

DATA

Figure 12-3. A Data Chain Block and a Data Chair ^w.0307

t2-12 Nucleus Useds Guide

EXTENDED iRMX@ II MTJLTIBUS@ SYSTEMS

125323 Message Fragmentation

When settiog up a data port you can set a bit in the fl4g field that enables or disables a method of breaking large messages into smaller pieces when no single buffer is large enough for the message. For the port object, this process is called !0€ssagqtag!o@!a!ia!-Messages can be fragmented by the sefrding board, send fragmentation or ftagmented by the receiving board, receive fragmentation.

Message fragnentation is performed as a series of messages sent between the agent sending the data and lhe agent rereiving the data. Becaùse Íiultiple messages must be sent and received to perform message fragmeltation, îhere is more system ov€rhead involved in message fragncntatiol than in data chaining.