STREAMS FAQ

This appendix provides answers to frequently asked questions (FAQs).

A source of information on STREAMS performance is the paper “The BSD Packet Filter: A New Architecture for User-level Packet Capture” by McCanne & Van Jacobson in the 1993 Winter USENIX proceedings (also available as ftp://ftp.ee.lbl.gov/papers/bpf-usenix93.ps.Z). It includes detailed NIT vs. in-kernel BPF performance measurements and some explanation of results obtained.

With decent code in the kernel (not STREAMS) an in-kernel filter is much faster.

The following discussion provides answers to frequently asked IP interface questions.

What are the rules for naming a Network Interface Card (NIC) device driver?

Naming of the NIC device driver has the following constraints:

• The name can contain alphanumeric and underscore (_) characters only

• The first and last characters of the name cannot be a number

• The name length cannot exceed 16 characters. The recommended length is 3–8 characters

What is the buffer reclaim policy for Network Interface (NIC) drivers?

Network Interface (NIC) drivers on the transmit side need to reclaim transmit buffers placed to the DMA hardware after the DMA operation has been completed. Because the reclaim operation is expensive, drivers often employ some “lazy-reclaim” scheme to either delay the buffer reclaim, coalesce many completed buffers together in one reclaim call, or both. The most aggressive scheme causes the handling of IO completion and buffer reclaiming to be postponed until a new transmit request is made but no empty slot is left on the DMA hardware.

Until recently in the Oracle Solaris operating environment, the network transmit buffers have been allocated from the kernel memory heap. The only detrimental effect from lazy reclaim is a waste of kernel memory that could have been freed up sooner.

The Oracle Solaris operating environment will employ a “zero-copy” scheme whenever possible. Under “zero-copy”, the stack will attempt to use client-supplied buffers through esballoc(9f) directly for network transmit, rather than allocating kernel heap. The “zero-copy” eliminates an expensive copy operation when moving data from a client supplied buffer to a kernel buffer.

Lazy reclaim on a client-supply transmit buffer can seriously impact the operation of the client subsystem or application that relies on a buffer to be released from the networking subsystem expediently. For this reason, NIC drivers employing any lazy reclaim scheme must ensure that buffer reclaim is not held up indefinitely. This requirement can be easily satisfied by ensuring that the driver uses a reclaim timer of tens of seconds or less.

Is there documentation that describes the interface between IP and network drivers, namely, the Oracle-specific requirements not outlined in the DLPI Version 2 specification?

IP is a STREAMS module in the Oracle Solaris operating environment. Any module or driver interface with IP should follow the STREAMS mechanism. There are no specific requirements for the interface between IP and network drivers.

When an ifconfig device0 plumb is issued, the driver immediately receives a DL_INFO_REQ. Exactly what is required in the DL_INFO_ACK from a DLPI Style 2 provider?

Look at the dl_info_ack_t struct in /usr/include/sys/dlpi.h.

Can a driver be a clone driver and also a DLPI Style 2 provider? If so, how do I map the minor number selected in the open routine to an instance prior to a DL_ATTACH_REQ? The technique of using the minor number to obtain the instance in the getinfo routine is not valid prior to the DL_ATTACH_REQ.

Yes, it is possible for the driver to be a CLONE driver and also a DLPI Style 2 provider. The DL_ATTACH_REQ request assigns a physical point of attachment (PPA) to a stream. The DL_ATTACH_REQ request can be issued any time after a file or stream being opened. The DL_ATTACH_REQ request does not have anything to do with assigning, retrieving or mapping minor/instance number. Of course, you can issue a DL_ATTACH_REQ request for a file or stream with desired major/minor number. As for the question of mapping minor number to instance, usually the minor number (getminor(9F)) is the instance number.

In the examples, a minor node is created each time the driver's attach routine is called. How would a clone driver attach to multiple boards; that is, have multiple instances, and still only create one minor node?

For the clone driver, this might not be possible. A non-clone driver, it can use the bits information in a particular minor number, for example FF, to map all other minor nodes.

Do 2.1 Ethernet drivers support LLI 2.0 interfaces?

Do you mean DLPI (Data Link Provider interfaces) ? The Solaris 2.1 ethernet drivers, le and ie. both support DLPI. See the le(7D) man page.

Does Solaris 2.1 DLPI provide both connection-oriented services and connectionless services? Also, is your DLPI Version 2.0, which includes multicast facilities?

Yes and yes. Please see the dlpi(7P) man page. TCP and IP are STREAMS modules in the Oracle Solaris operating environment. The command strconf < /dev/tcp lists all the modules. STREAMS is not supported in SunOS 4 system TCP/IP.

Is multicasting supported on SunOS 4? If not, how can the customer obtain this feature?

IP multicast is a standard supported feature in the Oracle Solaris operating environment, but it is not supported in the SunOS 4 environment. If customers want to run an unsupported IP multicast on their SunOS 4 machines, it is available via anonymous FTP from gregorio.stanford.edu in the file vmtp-ip/ipmulti-sunos41x.tar.Z.