udi_nsr_rx_ops_t(3udi)

NSR receive entry point ops vector

SYNOPSIS

#include <udi.h>

typedef const struct {

	udi_channel_event_ind_op_t *channel_event_ind_op;

	udi_nsr_rx_ind_op_t *nsr_rx_ind_op;

	udi_nsr_exp_rx_ind_op_t *nsr_exp_rx_ind_op;

} udi_nsr_rx_ops_t;
 
/* NSR Receive Ops Vector Number */
 

#define  UDI_NSR_RX_OPS_NUM				6

DESCRIPTION A Network Service Requestor (NSR) uses the udi_nsr_rx_ops_t structure in a udi_ops_init_t as part of its udi_init_info in order to register its entry points for the Network Interface Metalanguage receive channel operations.

REFERENCES udi_nsr_ctrl_ops_t, udi_nsr_tx_ops_t

3.3.3 Network Control Block Registration

The Network Interface Metalanguage uses a number of different types of control blocks for it's various metalanguage operations. These control blocks contain supplementary information for the operation being performed, scratch space for utilization by the owner of the control block, and environment management information for controlling each operation and marshalling arguments when necessary (the environment management portion of the control block is not visible to the ND).

The typical usage of these control blocks by an ND driver or NSR is as follows (from the ND perspective):

  1. Register the control block index for each type of control block by filling in udi_cb_init_t structures referenced by the udi_init_info structure.
  2. Register the ops index for each type of channel by filling in udi_ops_init_t structures referenced by the udi_init_info structure.
  3. All subsequent channel operations will receive a control block appropriate to that operation type on the corresponding channel. The control block and its associated scratch space will be sized as specified by the registration in the previous steps. The ND should perform the requested operation and then return the control block in the corresponding acknowledgement channel operation.
  4. When allocating a control block internally for use, the control block index argument passed to udi_cb_alloc specifies the appropriate type of control block; the resulting allocated control block will be large enough to be used for any of the control blocks within that index group.

3.3.4 Network Interface Metalanguage Binding

3.3.4.1 Network Bind Operation

Once the ND has been initialized and it has registered the UDI Network Interface Metalanguage channel operations, it may receive bind requests from the NSR. As the first stage of this binding, the UDI Management Agent (MA) will bind the child (NSR) to the parent (ND) using the techniques described in the UDI Management Metalanguage chapter. A typical binding can be summarized by the following procedure:

  1. The MA creates the initial bind channel between the ND and the NSR. This channel is the network control channel and uses the UDI Network Interface Metalanguage ctrl_ops role.
  2. The MA sends a udi_usage_ind to the new ND and NSR regions separately to allow them to initialize.
  3. The MA sends udi_channel_event_ind operations of type BIND_CHANNEL as needed to initialize any secondary regions and internal bind channels for the ND and NSR.
  4. The MA sends a udi_channel_event_ind operation of type BIND_CHANNEL to the NSR region.
  5. The NSR prepares its end of the channel for use. The UDI Network Interface Metalanguage control channel is now established between the ND and the NSR.

At this point, the UDI Network Interface Metalanguage control channel is established between the ND and the NSR; the NSR may now initiate Network Bind operations to the ND.

The Network Bind operation (udi_nd_bind_req) exchanges basic information about the media type and supported packet information between the NSR and the ND, as well as identifying the transfer channel indices to be used for communication.

  1. The NSR spawns the transmit channel, specifying that the spawned channel should use the transmit channel ops vector. This may be done in the primary region or in another region created specifically to handle transmit operations.
  2. The NSR spawns the receive channel in a manner similar to the transmit channel.
  3. The NSR issues a udi_nd_bind_req operation over the newly established bind channel to the ND. Part of the udi_nd_bind_req operation information specifies the indices of the spawned transfer channels.

The ND and the NSR have now agreed to communicate and have a common control channel which allows them to communicate directly without requiring assistance from the UDI MA. However, as noted in Section 3.2.4.3, "Transfer Channels", the ND and NSR cannot yet perform data transfer operations; the data handling channels have not been established and will be created by subsequent operations.

  1. The ND verifies the request, prepares itself for handling that NSR binding.
  2. The ND should then call udi_channel_spawn with the spawn index indicated in the Network Bind control block to establish the transmit data channel to the NSR. Simultaneously or on completion of that spawn it should also call udi_channel_spawn to establish the receive data channel to the NSR.
  3. The ND then responds to the NSR with a udi_nsr_bind_ack operation over the network control channel. This acknowledgment should not be generated by the ND until the channel spawn operations have completed to ensure that the NSR does not issue operations to these channels before they are fully created.
  4. The NSR then completes its internal preparations and then responds to the UDI MA over the management channel with a udi_channel_event_complete to indicate completion of the bind operation.

The expedited data ops vectors allow expedited data to be handled separately from normal data and thereby allows a higher priority to be assigned to managing expedited data. If no expedited data is expected, or if the network type or protocol stack cannot support expedited data, the expedited data ops vectors should point to the normal data handling routines.

The data channels are established by spawning the network control channel as indicated by the contents of the network bind control block exchanged in Step 3 above.

At this point, the communications pathways between the ND and the NSR have been fully established. The NSR may now enable the interface, which causes the ND to enable the hardware and to create a pool of transmit control blocks to post to the NSR for sending or receiving network packets. The normal flow of calls associated with the Network Bind operation which supports expedited data operations is illustrated in Figure 3-2

.

Figure 3-2 Connectionless Network Bind Operation

3.3.4.2 Network Unbind Operation

The Network Unbind process is used to detach and release the resources established by the Network Bind operation. During the Network Unbind operation the driver is instructed to stop forwarding any frames and shutdown the channels. The driver acknowledges the Network Unbind operation through a udi_nsr_unbind_ack operation. Once the network unbind has been performed, the control channel and both data channels should be released by calling udi_channel_close. Either end may initiate the closure, but both sides must release the data channels after the Network Unbind acknowledgement.

Note - One or both of the ND and NSR may receive UDI_CHANNEL_CLOSED indications depending on the sequence of events; these are assumed to be indications of the proper unbinding operation and are typically ignored.

The Network Unbind process is used to gracefully terminate network connectivity. If the normal data channels or the control channel is closed by either end, a Network Unbind condition is assumed and the channels are shutdown by both the NSR and the ND.

The normal flow of this operation is illustrated in Figure 3-3

.

Figure 3-3 Unbind Operation


UDI NIC Driver Specification Contents