| ng_source.4 (139097) | ng_source.4 (140561) |
|---|---|
| 1.\" Copyright 2002 Sandvine Inc. 2.\" All rights reserved. 3.\" 4.\" Subject to the following obligations and disclaimer of warranty, use and 5.\" redistribution of this software, in source or object code forms, with or 6.\" without modifications are expressly permitted by Sandvine Inc.; provided, 7.\" however, that: 8.\" 1. Any and all reproductions of the source or object code must include the --- 16 unchanged lines hidden (view full) --- 25.\" PUNITIVE, OR CONSEQUENTIAL DAMAGES, PROCUREMENT OF SUBSTITUTE GOODS OR 26.\" SERVICES, LOSS OF USE, DATA OR PROFITS, HOWEVER CAUSED AND UNDER ANY 27.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 28.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 29.\" THIS SOFTWARE, EVEN IF SANDVINE IS ADVISED OF THE POSSIBILITY OF SUCH 30.\" DAMAGE. 31.\" 32.\" Author: Dave Chapeskie <dchapeskie@sandvine.com> | 1.\" Copyright 2002 Sandvine Inc. 2.\" All rights reserved. 3.\" 4.\" Subject to the following obligations and disclaimer of warranty, use and 5.\" redistribution of this software, in source or object code forms, with or 6.\" without modifications are expressly permitted by Sandvine Inc.; provided, 7.\" however, that: 8.\" 1. Any and all reproductions of the source or object code must include the --- 16 unchanged lines hidden (view full) --- 25.\" PUNITIVE, OR CONSEQUENTIAL DAMAGES, PROCUREMENT OF SUBSTITUTE GOODS OR 26.\" SERVICES, LOSS OF USE, DATA OR PROFITS, HOWEVER CAUSED AND UNDER ANY 27.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 28.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 29.\" THIS SOFTWARE, EVEN IF SANDVINE IS ADVISED OF THE POSSIBILITY OF SUCH 30.\" DAMAGE. 31.\" 32.\" Author: Dave Chapeskie <dchapeskie@sandvine.com> |
| 33.\" $FreeBSD: head/share/man/man4/ng_source.4 139097 2004-12-21 01:09:34Z brueffer $ | 33.\" $FreeBSD: head/share/man/man4/ng_source.4 140561 2005-01-21 08:36:40Z ru $ |
| 34.\" 35.Dd November 1, 2002 36.Dt NG_SOURCE 4 37.Os 38.Sh NAME 39.Nm ng_source 40.Nd netgraph discard node type 41.Sh SYNOPSIS --- 132 unchanged lines hidden (view full) --- 174hook. 175.El 176.Sh SHUTDOWN 177This node shuts down upon receipt of a 178.Dv NGM_SHUTDOWN 179control message, or when the 180.Dv output 181hook has been disconnected. | 34.\" 35.Dd November 1, 2002 36.Dt NG_SOURCE 4 37.Os 38.Sh NAME 39.Nm ng_source 40.Nd netgraph discard node type 41.Sh SYNOPSIS --- 132 unchanged lines hidden (view full) --- 174hook. 175.El 176.Sh SHUTDOWN 177This node shuts down upon receipt of a 178.Dv NGM_SHUTDOWN 179control message, or when the 180.Dv output 181hook has been disconnected. |
| 182.Sh IMPLEMENTATION NOTES 183.No ( Fx 4.4 184version) 185.Pp 186The use of 187.Xr splimp 9 188around the 189.Dv NG_SEND_DATA 190loop is important. 191Without it, 192the time taken by a single invocation of 193.Fn ng_source_intr 194becomes too 195large and the packet rate drops. 196Probably due to the NIC starting to 197send the packets right away. 198.Pp 199Copying all the packets in one loop and sending them in another inside 200of 201.Fn ng_source_send 202is done to limit how long we are at 203.Xr splimp 9 204and gave 205minor packet rate increases (~5% at 256 byte packets). 206However note 207that if there are errors in the send loop, the remaining copied packets 208are simply freed and discarded; thus we skip those packets, and ordering 209of the input queue to the output is not maintained. 210.Pp 211Calling 212.Xr timeout 9 213at the end of 214.Fn ng_source_intr 215instead of near the 216beginning is done to help avoid CPU starvation if 217.Fn ng_source_intr 218takes a long time to run. 219.Pp 220The use of 221.Xr splnet 9 222may be sub-optimal. 223It is used for synchronization 224within the node (e.g., data received on the 225.Dv input 226hook while 227.Fn ng_source_send 228is active) but we do not want to hold it too long and risk 229starving the NIC. 230.Pp 231For clarity and simplicity, debugging messages and instrumentation code 232has been removed. 233On i386 one can include 234.In machine/cpufunc.h 235to have access to the 236.Fn rdtsc 237function to read the instruction counter at the 238start and end of 239.Fn ng_source_intr . 240Also useful is the packet count returned by 241.Fn ng_source_send . 242Do not try to report such things from within 243.Fn ng_source_intr , 244instead include the values in 245.Va sc->stats . |
|
| 182.Sh EXAMPLES 183Attach the node to an 184.Xr ng_ether 4 185node for an interface. 186If 187.Nm ng_ether 188is 189not already loaded you will need to do so. --- 75 unchanged lines hidden (view full) --- 265the Epoch and can be converted into a date string via TCL's [clock 266format] or via the 267.Xr date 1 268command: 269.Bd -literal -offset indent 270date -r 1035305880 271Tue Oct 22 12:58:00 EDT 2002 272.Ed | 246.Sh EXAMPLES 247Attach the node to an 248.Xr ng_ether 4 249node for an interface. 250If 251.Nm ng_ether 252is 253not already loaded you will need to do so. --- 75 unchanged lines hidden (view full) --- 329the Epoch and can be converted into a date string via TCL's [clock 330format] or via the 331.Xr date 1 332command: 333.Bd -literal -offset indent 334date -r 1035305880 335Tue Oct 22 12:58:00 EDT 2002 336.Ed |
| 273.Sh IMPLEMENTATION NOTES 274.No ( Fx 4.4 275version) 276.Pp 277The use of 278.Xr splimp 9 279around the 280.Dv NG_SEND_DATA 281loop is important. 282Without it, 283the time taken by a single invocation of 284.Fn ng_source_intr 285becomes too 286large and the packet rate drops. 287Probably due to the NIC starting to 288send the packets right away. 289.Pp 290Copying all the packets in one loop and sending them in another inside 291of 292.Fn ng_source_send 293is done to limit how long we are at 294.Xr splimp 9 295and gave 296minor packet rate increases (~5% at 256 byte packets). 297However note 298that if there are errors in the send loop, the remaining copied packets 299are simply freed and discarded; thus we skip those packets, and ordering 300of the input queue to the output is not maintained. 301.Pp 302Calling 303.Xr timeout 9 304at the end of 305.Fn ng_source_intr 306instead of near the 307beginning is done to help avoid CPU starvation if 308.Fn ng_source_intr 309takes a long time to run. 310.Pp 311The use of 312.Xr splnet 9 313may be sub-optimal. 314It is used for synchronization 315within the node (e.g., data received on the 316.Dv input 317hook while 318.Fn ng_source_send 319is active) but we do not want to hold it too long and risk 320starving the NIC. 321.Pp 322For clarity and simplicity, debugging messages and instrumentation code 323has been removed. 324On i386 one can include 325.In machine/cpufunc.h 326to have access to the 327.Fn rdtsc 328function to read the instruction counter at the 329start and end of 330.Fn ng_source_intr . 331Also useful is the packet count returned by 332.Fn ng_source_send . 333Do not try to report such things from within 334.Fn ng_source_intr , 335instead include the values in 336.Va sc->stats . | |
| 337.Sh SEE ALSO 338.Xr netgraph 4 , 339.Xr ng_echo 4 , 340.Xr ng_hole 4 , 341.Xr ng_tee 4 , 342.Xr ngctl 8 , 343.Xr nghook 8 344.Sh HISTORY 345The 346.Nm 347node type was implemented in 348.Fx 4.8 . 349.Sh AUTHORS 350.An Dave Chapeskie Aq dchapeskie@SANDVINE.com | 337.Sh SEE ALSO 338.Xr netgraph 4 , 339.Xr ng_echo 4 , 340.Xr ng_hole 4 , 341.Xr ng_tee 4 , 342.Xr ngctl 8 , 343.Xr nghook 8 344.Sh HISTORY 345The 346.Nm 347node type was implemented in 348.Fx 4.8 . 349.Sh AUTHORS 350.An Dave Chapeskie Aq dchapeskie@SANDVINE.com |