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.
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
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 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 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.
IP is a STREAMS module in the 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.
Look at the dl_info_ack_t struct in /usr/include/sys/dlpi.h.
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.
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 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.
Yes and yes. Please see the dlpi(7P) man page. TCP and IP are STREAMS modules in the Solaris operating environment. The command strconf < /dev/tcp lists all the modules. STREAMS is not supported in SunOS 4 system TCP/IP.
IP multicast is a standard supported feature in the 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.