![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Top]](icons/top.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This section describes the configuration for the network layer protocols. Table 4-3 describes all configuration options. For some options, the default value is specified using symbolic constants. These symbolic constants are defined in netLib.h. To override any default values assigned to these constants, reconfigure VxWorks with the appropriate values set.
VxWorks allocates and initializes memory for the network stack only once, at network initialization time. Out of this pre-allocated memory, the network stack uses netBufLib routines to set up a memory pool. From this memory pool, the network stack uses netBufLib routines to get the memory needed for data transfer.
The netBufLib routines deal with data in terms of mBlk structures, clBlk structures, and clusters. The mBlk and clBlk structures provide information necessary to manage the data stored in clusters. The clusters, which come in different sizes, contain the data described by the mBlk and clBlk structures. When VxWorks sets up the network stack memory pool, it needs to know the number of mBlks, clBlks, as well as the number of clusters per cluster size. The default counts are specified by symbolic constants defined in h/netBufLib.h. These constants are described in Table 4-4.
|
CAUTION: Change these constants only after you fully understand what they do. Setting inappropriate values can make the TCP/IP stack inoperable.
|
||||||||||||||||||
By default, the VxWorks network stack creates six pools (all within the main network memory pool) for clusters ranging in size from 64 bytes to 2048 bytes. However, valid cluster sizes can range from 64 bytes increasing by powers of two to 64K (65535). If your network stack needs clusters of a valid but non-default size, you can edit the clDescTbl table defined in target/src/config/usrNetwork.c. The following is an example and clDescTbl[ ] table:
CL_DESC clDescTbl [] = /* network cluster pool configuration table */
{
/*
clusterSize num memArea memSize
----------- ---- ------- -------
*/
{64, NUM_64, NULL, 0},
{128, NUM_128, NULL, 0},
{256, NUM_256, NULL, 0},
{512, NUM_512, NULL, 0},
{1024, NUM_1024, NULL, 0},
{2048, NUM_2048, NULL, 0}
};
To add a cluster pool for clusters of 4096 bytes each, edit clDescTbl[ ] as follows: 1
CL_DESC clDescTbl [] = /* network cluster pool configuration table */
{
/*
clusterSize num memArea memSize
----------- ---- ------- -------
*/
{64, NUM_64, NULL, 0},
{128, NUM_128, NULL, 0},
{256, NUM_256, NULL, 0},
{512, NUM_512, NULL, 0},
{1024, NUM_1024, NULL, 0},
{2048, NUM_2048, NULL, 0},
{4096, NUM_4096, NULL, 0}
};
|
|
CAUTION: Adjust the counts for mBlks, clBlks, clusters, and cluster pools only after collecting data on system behavior and deciding whether or how you would like to change that behavior. Carefully planned changes can significantly improve performance, but reckless changes can significantly reduce performance.
|
||||||||||||||||||
The values shown above are reasonable defaults, but the network requirements for your system could be radically different. For example, your use of the network stack could require more clusters of a particular size. Making such a determination is a matter of experimentation and analysis. However, as background information, you need to understand how data divides up into mBlks, clBlks, and clusters.
The mBlk structure is the primary vehicle through which you access data in a memory pool established by netPoolInit( ). Because the mBlk structure merely references the data, this lets network layers communicate data without actually having to copy the data. In addition, data can be chained using mBlks. Thus, you can pass an arbitrarily large amount of data by passing the mBlk at the head of an mBlk chain. Consider Figure 4-5
. 2As shown in Figure 4-5, an mBlk references data only indirectly - through a clBlk structure. This indirection makes it easier for multiple mBlks to share the same cluster. See Figure 4-6
.Please note that using a clBlk structure instead of a pointer to provide a level of indirection is not an extravagance. The clBlk structure tracks how many mBlks share its underlying cluster. This is critical when it comes time to free an mBlk/clBlk/cluster construct. If you use netMblkClFree( ) to free the construct, the mBlk is freed back to the pool and the reference count in the clBlk is decremented. If the reference count drops to zero, the clBlk and cluster are also freed back to the memory pool.
The clDescTbl[ ] shown in the previous section did not make use of the memArea and memSize members. For the default network buffer pool, the memory allocation calls are handled internally and the values of memArea and memSize are set for you. However, if necessary, you can supply these values and thus explicitly determine the size and location of the memory pools. For more information on how to use the memArea and memSize members, see the reference entry for netPoolInit( ).
You can use the ping( ) utility from VxWorks to test whether a particular system is accessible over the network. Like the UNIX command of the same name, ping( )sends one or more packets to another system and waits for a response. You can identify the other system either by name or by its numeric Internet address. This is useful for testing routing tables and host tables, or determining whether another machine is responding to network requests.
The following example shows ping( ) output for an unreachable address:
-> ping "150.12.0.1",1 no answer from 150.12.0.1 value = -1 = 0xffffffff = _end + 0xfff91c4f
If the first argument uses a host name, ping( ) uses the host table to look it up, as in the following example:
-> ping "caspian",1 caspian is alive value = 0 = 0x0
The numeric argument specifies how many packets to expect back (typically, when an address is reachable, that is also how many packets are sent). If you specify more than one packet, ping( ) displays more elaborate output, including summary statistics. For example, the following test sends packets to a remote network address until it receives ten acknowledgments, and reports on the time it takes to get replies:
-> ping "198.41.0.5",10 PING 198.41.0.5: 56 data bytes 64 bytes from 198.41.0.5: icmp_seq=0. time=176. ms 64 bytes from 198.41.0.5: icmp_seq=1. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=2. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=3. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=4. time=80. ms 64 bytes from 198.41.0.5: icmp_seq=5. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=6. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=7. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=8. time=64. ms 64 bytes from 198.41.0.5: icmp_seq=9. time=64. ms ----198.41.0.5 PING Statistics---- 10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 64/76/176 value = 0 = 0x0
The report format matches the format used by the UNIX ping utility. Timings are based on the system clock; its resolution could be too coarse to show any elapsed time when communicating with targets on a local network.
Applications can use ping( ) periodically to test whether another network node is available. To support this use, the ping( ) routine returns a STATUS value and accepts a PING_OPT_SILENT flag as a bit in its third argument to suppress printed output, as in the following code fragment:
/* Check whether other system still there */
if (ping (partnerName, 1, PING_OPT_SILENT) == ERROR)
{
myShutdown(); /* clean up and exit */
}
...
You can set one other flag in the third ping( ) argument: PING_OPT_DONTROUTE restricts ping( ) to hosts that are directly connected, without going through a gateway.
1: For this particular clDescTbl[ ] table only, you can specify memArea values as NULL and memSize values as 0. When the network initialization code actually allocates the necessary memory, it resets these values appropriately. For all other clDescTbl[ ] tables, you must provide these values explicitly before calling netPoolInit( ). For more information, see the reference entry for netPoolInit( ).
2:
To support chaining across multiple packets, the mBlk structure contains two members that
support of chaining. One member points to the next mBlk in the current packet. The other member points to the head mBlk in the next packet (if any).