should maintain source ordering without advice from the protocol.
will ignore any flow IDs present on
.Vt mbuf headers for the purposes of work placement.
should maintain flow ordering as defined by the
.Vt mbuf header flow ID field. If the protocol implements nh_m2flow, then netisr will query the protocol in the event that the
.Vt mbuf doesnt have a flow ID, falling back on source ordering.
|NETISR_POLICY_CPU||netisr will entirely delegate all work placement decisions to the protocol, querying nh_m2cpuid for each packet.|
Registration is declared using
.Vt struct netisr_handler , whose fields are defined as follows:
|Vt const char * nh_name||Unique character string name of the protocol, which may be included in sysctl(2) MIB names, so should not contain whitespace.|
|Vt netisr_handler_t nh_handler|
|Protocol handler function that will be invoked on each packet received for the protocol.|
|Vt netisr_m2flow_t nh_m2flow|
|Optional protocol function to generate a flow ID and set M_FLOWID for packets that do not enter netisr with M_FLOWID defined. Will be used only with NETISR_POLICY_FLOW.|
|Vt netisr_m2cpuid_t nh_m2cpuid|
|Protocol function to determine what CPU a packet should be processed on. Will be used only with NETISR_POLICY_CPU.|
|Vt netisr_drainedcpu_t nh_drainedcpu|
|Optional callback function that will be invoked when a per-CPU queue was drained. It will never fire for directly dispatched packets. Unless fully understood, this special-purpose function should not be used.|
|Vt u_int nh_proto||Protocol number used by both protocols to identify themselves to netisr, and by packet sources to select what handler will be used to process packets. A table of supported protocol numbers appears below. For implementation reasons, protocol numbers great than 15 are currently unsupported.|
|Vt u_int nh_qlimit||The maximum per-CPU queue depth for the protocol; due to internal implementation details, the effective queue depth may be as much as twice this number.|
|Vt u_int nh_policy||The ordering and work placement policy for the protocol, as described earlier.|
Packet sources, such as network interfaces, may request protocol processing using the netisr_dispatch and netisr_queue interfaces. Both accept a protocol number and
.Vt mbuf argument, but while netisr_queue will always execute the protocol handler asynchronously in a deferred context, netisr_dispatch will optionally direct dispatch if permitted by global and per-protocol policy.
In order to provide additional load balancing and flow information, packet sources may also specify an opaque source identifier, which in practice might be a network interface number or socket pointer, using the netisr_dispatch_src and netisr_queue_src variants.
The follow protocol numbers are currently defined:
NETISR_IP IPv4 NETISR_IGMP IGMPv3 loopback NETISR_ROUTE Routing socket loopback NETISR_AARP Appletalk AARP NETISR_ATALK1 Appletalk phase 1 NETISR_ATALK2 Appletalk phase 2 NETISR_ARP ARP NETISR_IPX IPX/SPX NETISR_IPV6 IPv6 NETISR_NATM ATM NETISR_EPAIR netstat(1), epair(4)
This manual page and the netisr implementation were written by
.An Robert N. M. Watson .