2 # Traffic control configuration.
5 menu "QoS and/or fair queueing"
8 bool "QoS and/or fair queueing"
11 When the kernel has several packets to send out over a network
12 device, it has to decide which ones to send first, which ones to
13 delay, and which ones to drop. This is the job of the queueing
14 disciplines, several different algorithms for how to do this
15 "fairly" have been proposed.
17 If you say N here, you will get the standard packet scheduler, which
18 is a FIFO (first come, first served). If you say Y here, you will be
19 able to choose from among several alternative algorithms which can
20 then be attached to different network devices. This is useful for
21 example if some of your network devices are real time devices that
22 need a certain minimum data flow rate, or if you need to limit the
23 maximum data flow rate for traffic which matches specified criteria.
24 This code is considered to be experimental.
26 To administer these schedulers, you'll need the user-level utilities
27 from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
28 That package also contains some documentation; for more, check out
29 <http://linux-net.osdl.org/index.php/Iproute2>.
31 This Quality of Service (QoS) support will enable you to use
32 Differentiated Services (diffserv) and Resource Reservation Protocol
33 (RSVP) on your Linux router if you also say Y to the corresponding
34 classifiers below. Documentation and software is at
35 <http://diffserv.sourceforge.net/>.
37 If you say Y here and to "/proc file system" below, you will be able
38 to read status information about packet schedulers from the file
41 The available schedulers are listed in the following questions; you
42 can say Y to as many as you like. If unsure, say N now.
50 prompt "Packet scheduler clock source"
51 default NET_SCH_CLK_GETTIMEOFDAY
53 Packet schedulers need a monotonic clock that increments at a static
54 rate. The kernel provides several suitable interfaces, each with
57 - high resolution (us or better)
58 - fast to read (minimal locking, no i/o access)
59 - synchronized on all processors
60 - handles cpu clock frequency changes
62 but nothing provides all of the above.
64 config NET_SCH_CLK_JIFFIES
65 bool "Timer interrupt"
67 Say Y here if you want to use the timer interrupt (jiffies) as clock
68 source. This clock source is fast, synchronized on all processors and
69 handles cpu clock frequency changes, but its resolution is too low
70 for accurate shaping except at very low speed.
72 config NET_SCH_CLK_GETTIMEOFDAY
75 Say Y here if you want to use gettimeofday as clock source. This clock
76 source has high resolution, is synchronized on all processors and
77 handles cpu clock frequency changes, but it is slow.
79 Choose this if you need a high resolution clock source but can't use
80 the CPU's cycle counter.
82 # don't allow on SMP x86 because they can have unsynchronized TSCs.
83 # gettimeofday is a good alternative
84 config NET_SCH_CLK_CPU
85 bool "CPU cycle counter"
86 depends on ((X86_TSC || X86_64) && !SMP) || ALPHA || SPARC64 || PPC64 || IA64
88 Say Y here if you want to use the CPU's cycle counter as clock source.
89 This is a cheap and high resolution clock source, but on some
90 architectures it is not synchronized on all processors and doesn't
91 handle cpu clock frequency changes.
93 The useable cycle counters are:
95 x86/x86_64 - Timestamp Counter
97 sparc64 - %ticks register
99 ia64 - Interval Time Counter
101 Choose this if your CPU's cycle counter is working properly.
105 comment "Queueing/Scheduling"
108 tristate "Class Based Queueing (CBQ)"
110 Say Y here if you want to use the Class-Based Queueing (CBQ) packet
111 scheduling algorithm. This algorithm classifies the waiting packets
112 into a tree-like hierarchy of classes; the leaves of this tree are
113 in turn scheduled by separate algorithms.
115 See the top of <file:net/sched/sch_cbq.c> for more details.
117 CBQ is a commonly used scheduler, so if you're unsure, you should
118 say Y here. Then say Y to all the queueing algorithms below that you
119 want to use as leaf disciplines.
121 To compile this code as a module, choose M here: the
122 module will be called sch_cbq.
125 tristate "Hierarchical Token Bucket (HTB)"
127 Say Y here if you want to use the Hierarchical Token Buckets (HTB)
128 packet scheduling algorithm. See
129 <http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
132 HTB is very similar to CBQ regarding its goals however is has
133 different properties and different algorithm.
135 To compile this code as a module, choose M here: the
136 module will be called sch_htb.
139 tristate "Hierarchical Fair Service Curve (HFSC)"
141 Say Y here if you want to use the Hierarchical Fair Service Curve
142 (HFSC) packet scheduling algorithm.
144 To compile this code as a module, choose M here: the
145 module will be called sch_hfsc.
148 tristate "ATM Virtual Circuits (ATM)"
151 Say Y here if you want to use the ATM pseudo-scheduler. This
152 provides a framework for invoking classifiers, which in turn
153 select classes of this queuing discipline. Each class maps
154 the flow(s) it is handling to a given virtual circuit.
156 See the top of <file:net/sched/sch_atm.c>) for more details.
158 To compile this code as a module, choose M here: the
159 module will be called sch_atm.
162 tristate "Multi Band Priority Queueing (PRIO)"
164 Say Y here if you want to use an n-band priority queue packet
167 To compile this code as a module, choose M here: the
168 module will be called sch_prio.
171 tristate "Random Early Detection (RED)"
173 Say Y here if you want to use the Random Early Detection (RED)
174 packet scheduling algorithm.
176 See the top of <file:net/sched/sch_red.c> for more details.
178 To compile this code as a module, choose M here: the
179 module will be called sch_red.
182 tristate "Stochastic Fairness Queueing (SFQ)"
184 Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
185 packet scheduling algorithm .
187 See the top of <file:net/sched/sch_sfq.c> for more details.
189 To compile this code as a module, choose M here: the
190 module will be called sch_sfq.
193 tristate "True Link Equalizer (TEQL)"
195 Say Y here if you want to use the True Link Equalizer (TLE) packet
196 scheduling algorithm. This queueing discipline allows the combination
197 of several physical devices into one virtual device.
199 See the top of <file:net/sched/sch_teql.c> for more details.
201 To compile this code as a module, choose M here: the
202 module will be called sch_teql.
205 tristate "Token Bucket Filter (TBF)"
207 Say Y here if you want to use the Token Bucket Filter (TBF) packet
208 scheduling algorithm.
210 See the top of <file:net/sched/sch_tbf.c> for more details.
212 To compile this code as a module, choose M here: the
213 module will be called sch_tbf.
216 tristate "Generic Random Early Detection (GRED)"
218 Say Y here if you want to use the Generic Random Early Detection
219 (GRED) packet scheduling algorithm for some of your network devices
220 (see the top of <file:net/sched/sch_red.c> for details and
221 references about the algorithm).
223 To compile this code as a module, choose M here: the
224 module will be called sch_gred.
226 config NET_SCH_DSMARK
227 tristate "Differentiated Services marker (DSMARK)"
229 Say Y if you want to schedule packets according to the
230 Differentiated Services architecture proposed in RFC 2475.
231 Technical information on this method, with pointers to associated
232 RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
234 To compile this code as a module, choose M here: the
235 module will be called sch_dsmark.
238 tristate "Network emulator (NETEM)"
240 Say Y if you want to emulate network delay, loss, and packet
241 re-ordering. This is often useful to simulate networks when
242 testing applications or protocols.
244 To compile this driver as a module, choose M here: the module
245 will be called sch_netem.
249 config NET_SCH_INGRESS
250 tristate "Ingress Qdisc"
252 Say Y here if you want to use classifiers for incoming packets.
255 To compile this code as a module, choose M here: the
256 module will be called sch_ingress.
258 comment "Classification"
264 tristate "Elementary classification (BASIC)"
267 Say Y here if you want to be able to classify packets using
268 only extended matches and actions.
270 To compile this code as a module, choose M here: the
271 module will be called cls_basic.
273 config NET_CLS_TCINDEX
274 tristate "Traffic-Control Index (TCINDEX)"
277 Say Y here if you want to be able to classify packets based on
278 traffic control indices. You will want this feature if you want
279 to implement Differentiated Services together with DSMARK.
281 To compile this code as a module, choose M here: the
282 module will be called cls_tcindex.
284 config NET_CLS_ROUTE4
285 tristate "Routing decision (ROUTE)"
289 If you say Y here, you will be able to classify packets
290 according to the route table entry they matched.
292 To compile this code as a module, choose M here: the
293 module will be called cls_route.
299 tristate "Netfilter mark (FW)"
302 If you say Y here, you will be able to classify packets
303 according to netfilter/firewall marks.
305 To compile this code as a module, choose M here: the
306 module will be called cls_fw.
309 tristate "Universal 32bit comparisons w/ hashing (U32)"
312 Say Y here to be able to classify packets using a universal
313 32bit pieces based comparison scheme.
315 To compile this code as a module, choose M here: the
316 module will be called cls_u32.
319 bool "Performance counters support"
320 depends on NET_CLS_U32
322 Say Y here to make u32 gather additional statistics useful for
323 fine tuning u32 classifiers.
326 bool "Netfilter marks support"
327 depends on NET_CLS_U32
329 Say Y here to be able to use netfilter marks as u32 key.
332 tristate "IPv4 Resource Reservation Protocol (RSVP)"
336 The Resource Reservation Protocol (RSVP) permits end systems to
337 request a minimum and maximum data flow rate for a connection; this
338 is important for real time data such as streaming sound or video.
340 Say Y here if you want to be able to classify outgoing packets based
341 on their RSVP requests.
343 To compile this code as a module, choose M here: the
344 module will be called cls_rsvp.
347 tristate "IPv6 Resource Reservation Protocol (RSVP6)"
351 The Resource Reservation Protocol (RSVP) permits end systems to
352 request a minimum and maximum data flow rate for a connection; this
353 is important for real time data such as streaming sound or video.
355 Say Y here if you want to be able to classify outgoing packets based
356 on their RSVP requests and you are using the IPv6.
358 To compile this code as a module, choose M here: the
359 module will be called cls_rsvp6.
362 bool "Extended Matches"
365 Say Y here if you want to use extended matches on top of classifiers
366 and select the extended matches below.
368 Extended matches are small classification helpers not worth writing
369 a separate classifier for.
371 A recent version of the iproute2 package is required to use
374 config NET_EMATCH_STACK
376 depends on NET_EMATCH
379 Size of the local stack variable used while evaluating the tree of
380 ematches. Limits the depth of the tree, i.e. the number of
381 encapsulated precedences. Every level requires 4 bytes of additional
384 config NET_EMATCH_CMP
385 tristate "Simple packet data comparison"
386 depends on NET_EMATCH
388 Say Y here if you want to be able to classify packets based on
389 simple packet data comparisons for 8, 16, and 32bit values.
391 To compile this code as a module, choose M here: the
392 module will be called em_cmp.
394 config NET_EMATCH_NBYTE
395 tristate "Multi byte comparison"
396 depends on NET_EMATCH
398 Say Y here if you want to be able to classify packets based on
399 multiple byte comparisons mainly useful for IPv6 address comparisons.
401 To compile this code as a module, choose M here: the
402 module will be called em_nbyte.
404 config NET_EMATCH_U32
406 depends on NET_EMATCH
408 Say Y here if you want to be able to classify packets using
409 the famous u32 key in combination with logic relations.
411 To compile this code as a module, choose M here: the
412 module will be called em_u32.
414 config NET_EMATCH_META
416 depends on NET_EMATCH
418 Say Y here if you want to be able to classify packets based on
419 metadata such as load average, netfilter attributes, socket
420 attributes and routing decisions.
422 To compile this code as a module, choose M here: the
423 module will be called em_meta.
425 config NET_EMATCH_TEXT
426 tristate "Textsearch"
427 depends on NET_EMATCH
429 select TEXTSEARCH_KMP
431 select TEXTSEARCH_FSM
433 Say Y here if you want to be able to classify packets based on
434 textsearch comparisons.
436 To compile this code as a module, choose M here: the
437 module will be called em_text.
443 Say Y here if you want to use traffic control actions. Actions
444 get attached to classifiers and are invoked after a successful
445 classification. They are used to overwrite the classification
446 result, instantly drop or redirect packets, etc.
448 A recent version of the iproute2 package is required to use
451 config NET_ACT_POLICE
452 tristate "Traffic Policing"
453 depends on NET_CLS_ACT
455 Say Y here if you want to do traffic policing, i.e. strict
456 bandwidth limiting. This action replaces the existing policing
459 To compile this code as a module, choose M here: the
460 module will be called police.
463 tristate "Generic actions"
464 depends on NET_CLS_ACT
466 Say Y here to take generic actions such as dropping and
469 To compile this code as a module, choose M here: the
470 module will be called gact.
473 bool "Probability support"
474 depends on NET_ACT_GACT
476 Say Y here to use the generic action randomly or deterministically.
478 config NET_ACT_MIRRED
479 tristate "Redirecting and Mirroring"
480 depends on NET_CLS_ACT
482 Say Y here to allow packets to be mirrored or redirected to
485 To compile this code as a module, choose M here: the
486 module will be called mirred.
489 tristate "IPtables targets"
490 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
492 Say Y here to be able to invoke iptables targets after successful
495 To compile this code as a module, choose M here: the
496 module will be called ipt.
499 tristate "Packet Editing"
500 depends on NET_CLS_ACT
502 Say Y here if you want to mangle the content of packets.
504 To compile this code as a module, choose M here: the
505 module will be called pedit.
508 tristate "Simple Example (Debug)"
509 depends on NET_CLS_ACT
511 Say Y here to add a simple action for demonstration purposes.
512 It is meant as an example and for debugging purposes. It will
513 print a configured policy string followed by the packet count
514 to the console for every packet that passes by.
518 To compile this code as a module, choose M here: the
519 module will be called simple.
521 config NET_CLS_POLICE
522 bool "Traffic Policing (obsolete)"
523 depends on NET_CLS_ACT!=y
526 Say Y here if you want to do traffic policing, i.e. strict
527 bandwidth limiting. This option is obsoleted by the traffic
528 policer implemented as action, it stays here for compatibility
532 bool "Incoming device classification"
533 depends on NET_CLS_U32 || NET_CLS_FW
535 Say Y here to extend the u32 and fw classifier to support
536 classification based on the incoming device. This option is
537 likely to disappear in favour of the metadata ematch.
540 bool "Rate estimator"
542 Say Y here to allow using rate estimators to estimate the current
543 rate-of-flow for network devices, queues, etc. This module is
544 automatically selected if needed but can be selected manually for
545 statistical purposes.