src-test2/sys/net/netisr.c, branch release/5.5.0

Merge missing patch hunk from netisr.c:1.12 from HEAD to RELENG_5:

2005-09-26T18:48:01Z

Include opt_net.h from netisr.c, or compiling in NET_WITH_GIANT will not change the default setting for debug.mpsafenet. Submitted by: Ed Maste

MFC 1.15: Correctly unregister netisr's.

2004-10-14T19:19:24Z

Approved by: re (scottl)

MFC: Apply error and success logic consistently to the function netisr_queue()

2004-09-15T15:14:19Z

and its users. Approved by: re (kensmith)

Merge sys/conf/options:1.478, sys/net/netisr.c:1.12, and

2004-09-03T03:09:55Z

sys/sys/kernel.h:1.118 to RELENG_5: Change the default disposition of debug.mpsafenet from 0 to 1, which will cause the network stack to operate without the Giant lock by default. This change has the potential to improve performance by increasing parallelism and decreasing latency in network processing. Due to the potential exposure of existing or new bugs, the following compatibility functionality is maintained: - It is still possible to disable Giant-free operation by setting debug.mpsafenet to 0 in loader.conf. - Add "options NET_WITH_GIANT", which will restore the default value of debug.mpsafenet to 0, and is intended for use on systems compiled with known unsafe components, or where a more conservative configuration is desired. - Add a new declaration, NET_NEEDS_GIANT("componentname"), which permits kernel components to declare dependence on Giant over the network stack. If the declaration is made by a preloaded module or a compiled in component, the disposition of debug.mpsafenet will be set to 0 and a warning concerning performance degraded operation printed to the console. If it is declared by a loadable kernel module after boot, a warning is displayed but the disposition cannot be changed. This is implemented by defining a new SYSINIT() value, SI_SUB_SETTINGS, which is intended for the processing of configuration choices after tunables are read in and the console is available to generate errors, but before much else gets going. This compatibility behavior will go away when we've finished the last of the locking work and are confident that operation is correct. Approved by: re (scottl, kensmith)

Comment clarifying debug_mpsafenet.

2004-07-18T21:50:22Z

o add a flags parameter to netisr_register that is used to specify

2003-11-08T22:28:40Z

whether or not the isr needs to hold Giant when running; Giant-less operation is also controlled by the setting of debug_mpsafenet o mark all netisr's except NETISR_IP as needing Giant o add a GIANT_REQUIRED assertion to the top of netisr's that need Giant o pickup Giant (when debug_mpsafenet is 1) inside ip_input before calling up with a packet o change netisr handling so swi_net runs w/o Giant; instead we grab Giant before invoking handlers based on whether the handler needs Giant o change netisr handling so that netisr's that are marked MPSAFE may have multiple instances active at a time o add netisr statistics for packets dropped because the isr is inactive Supported by: FreeBSD Foundation

o make debug_mpsafenet globally visible

2003-11-05T23:42:51Z

o move it from subr_bus.c to netisr.c where it more properly belongs o add NET_PICKUP_GIANT and NET_DROP_GIANT macros that will be used to grab Giant as needed when MPSAFE operation is enabled Supported by: FreeBSD Foundation

When direct dispatching an netisr (net.isr.enable=1), if there are already

2003-10-03T18:27:24Z

any queued packets for the isr, process those packets before the newly submitted packet, maintaining ordering of all packets being delivered to the netisr. Remove the bypass counter since we don't bypass anymore. Leave the comment about possible problems and options since later performance optimization may change the strategy for addressing ordering problems here. Specifically, this maintains the strong isr ordering guarantee; additional parallelism and lower latency may be possible by moving to weaker guarantees (per-interface, for example). We will probably at some point also want to remove the one instance netisr dispatch limit currently enforced by a mutex, but it's not clear that's 100% safe yet, even in the netperf branch. Reviewed by: sam, others

Create a tunable for net.isr.enable so that it may be set from

2003-10-02T02:54:10Z

inception, rather than having to wait for the boot to finish.

Temporarily turn net.isr.enable back off again until patches to

2003-10-01T22:15:16Z

correct potential nits in packet ordering are resolved.