2 # Traffic control configuration.
5 menu "QoS and/or fair queueing"
8 bool "QoS and/or fair queueing"
10 When the kernel has several packets to send out over a network
11 device, it has to decide which ones to send first, which ones to
12 delay, and which ones to drop. This is the job of the queueing
13 disciplines, several different algorithms for how to do this
14 "fairly" have been proposed.
16 If you say N here, you will get the standard packet scheduler, which
17 is a FIFO (first come, first served). If you say Y here, you will be
18 able to choose from among several alternative algorithms which can
19 then be attached to different network devices. This is useful for
20 example if some of your network devices are real time devices that
21 need a certain minimum data flow rate, or if you need to limit the
22 maximum data flow rate for traffic which matches specified criteria.
23 This code is considered to be experimental.
25 To administer these schedulers, you'll need the user-level utilities
26 from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
27 That package also contains some documentation; for more, check out
28 <http://linux-net.osdl.org/index.php/Iproute2>.
30 This Quality of Service (QoS) support will enable you to use
31 Differentiated Services (diffserv) and Resource Reservation Protocol
32 (RSVP) on your Linux router if you also say Y to the corresponding
33 classifiers below. Documentation and software is at
34 <http://diffserv.sourceforge.net/>.
36 If you say Y here and to "/proc file system" below, you will be able
37 to read status information about packet schedulers from the file
40 The available schedulers are listed in the following questions; you
41 can say Y to as many as you like. If unsure, say N now.
46 prompt "Packet scheduler clock source"
47 default NET_SCH_CLK_JIFFIES
49 Packet schedulers need a monotonic clock that increments at a static
50 rate. The kernel provides several suitable interfaces, each with
53 - high resolution (us or better)
54 - fast to read (minimal locking, no i/o access)
55 - synchronized on all processors
56 - handles cpu clock frequency changes
58 but nothing provides all of the above.
60 config NET_SCH_CLK_JIFFIES
61 bool "Timer interrupt"
63 Say Y here if you want to use the timer interrupt (jiffies) as clock
64 source. This clock source is fast, synchronized on all processors and
65 handles cpu clock frequency changes, but its resolution is too low
66 for accurate shaping except at very low speed.
68 config NET_SCH_CLK_GETTIMEOFDAY
71 Say Y here if you want to use gettimeofday as clock source. This clock
72 source has high resolution, is synchronized on all processors and
73 handles cpu clock frequency changes, but it is slow.
75 Choose this if you need a high resolution clock source but can't use
76 the CPU's cycle counter.
78 # don't allow on SMP x86 because they can have unsynchronized TSCs.
79 # gettimeofday is a good alternative
80 config NET_SCH_CLK_CPU
81 bool "CPU cycle counter"
82 depends on ((X86_TSC || X86_64) && !SMP) || ALPHA || SPARC64 || PPC64 || IA64
84 Say Y here if you want to use the CPU's cycle counter as clock source.
85 This is a cheap and high resolution clock source, but on some
86 architectures it is not synchronized on all processors and doesn't
87 handle cpu clock frequency changes.
89 The useable cycle counters are:
91 x86/x86_64 - Timestamp Counter
93 sparc64 - %ticks register
95 ia64 - Interval Time Counter
97 Choose this if your CPU's cycle counter is working properly.
101 comment "Queueing/Scheduling"
104 tristate "Class Based Queueing (CBQ)"
106 Say Y here if you want to use the Class-Based Queueing (CBQ) packet
107 scheduling algorithm. This algorithm classifies the waiting packets
108 into a tree-like hierarchy of classes; the leaves of this tree are
109 in turn scheduled by separate algorithms.
111 See the top of <file:net/sched/sch_cbq.c> for more details.
113 CBQ is a commonly used scheduler, so if you're unsure, you should
114 say Y here. Then say Y to all the queueing algorithms below that you
115 want to use as leaf disciplines.
117 To compile this code as a module, choose M here: the
118 module will be called sch_cbq.
121 tristate "Hierarchical Token Bucket (HTB)"
123 Say Y here if you want to use the Hierarchical Token Buckets (HTB)
124 packet scheduling algorithm. See
125 <http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
128 HTB is very similar to CBQ regarding its goals however is has
129 different properties and different algorithm.
131 To compile this code as a module, choose M here: the
132 module will be called sch_htb.
135 tristate "Hierarchical Fair Service Curve (HFSC)"
137 Say Y here if you want to use the Hierarchical Fair Service Curve
138 (HFSC) packet scheduling algorithm.
140 To compile this code as a module, choose M here: the
141 module will be called sch_hfsc.
144 tristate "ATM Virtual Circuits (ATM)"
147 Say Y here if you want to use the ATM pseudo-scheduler. This
148 provides a framework for invoking classifiers, which in turn
149 select classes of this queuing discipline. Each class maps
150 the flow(s) it is handling to a given virtual circuit.
152 See the top of <file:net/sched/sch_atm.c>) for more details.
154 To compile this code as a module, choose M here: the
155 module will be called sch_atm.
158 tristate "Multi Band Priority Queueing (PRIO)"
160 Say Y here if you want to use an n-band priority queue packet
163 To compile this code as a module, choose M here: the
164 module will be called sch_prio.
167 tristate "Random Early Detection (RED)"
169 Say Y here if you want to use the Random Early Detection (RED)
170 packet scheduling algorithm.
172 See the top of <file:net/sched/sch_red.c> for more details.
174 To compile this code as a module, choose M here: the
175 module will be called sch_red.
178 tristate "Stochastic Fairness Queueing (SFQ)"
180 Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
181 packet scheduling algorithm .
183 See the top of <file:net/sched/sch_sfq.c> for more details.
185 To compile this code as a module, choose M here: the
186 module will be called sch_sfq.
189 tristate "True Link Equalizer (TEQL)"
191 Say Y here if you want to use the True Link Equalizer (TLE) packet
192 scheduling algorithm. This queueing discipline allows the combination
193 of several physical devices into one virtual device.
195 See the top of <file:net/sched/sch_teql.c> for more details.
197 To compile this code as a module, choose M here: the
198 module will be called sch_teql.
201 tristate "Token Bucket Filter (TBF)"
203 Say Y here if you want to use the Token Bucket Filter (TBF) packet
204 scheduling algorithm.
206 See the top of <file:net/sched/sch_tbf.c> for more details.
208 To compile this code as a module, choose M here: the
209 module will be called sch_tbf.
212 tristate "Generic Random Early Detection (GRED)"
214 Say Y here if you want to use the Generic Random Early Detection
215 (GRED) packet scheduling algorithm for some of your network devices
216 (see the top of <file:net/sched/sch_red.c> for details and
217 references about the algorithm).
219 To compile this code as a module, choose M here: the
220 module will be called sch_gred.
222 config NET_SCH_DSMARK
223 tristate "Differentiated Services marker (DSMARK)"
225 Say Y if you want to schedule packets according to the
226 Differentiated Services architecture proposed in RFC 2475.
227 Technical information on this method, with pointers to associated
228 RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
230 To compile this code as a module, choose M here: the
231 module will be called sch_dsmark.
234 tristate "Network emulator (NETEM)"
236 Say Y if you want to emulate network delay, loss, and packet
237 re-ordering. This is often useful to simulate networks when
238 testing applications or protocols.
240 To compile this driver as a module, choose M here: the module
241 will be called sch_netem.
245 config NET_SCH_INGRESS
246 tristate "Ingress Qdisc"
248 Say Y here if you want to use classifiers for incoming packets.
251 To compile this code as a module, choose M here: the
252 module will be called sch_ingress.
254 comment "Classification"
260 tristate "Elementary classification (BASIC)"
263 Say Y here if you want to be able to classify packets using
264 only extended matches and actions.
266 To compile this code as a module, choose M here: the
267 module will be called cls_basic.
269 config NET_CLS_TCINDEX
270 tristate "Traffic-Control Index (TCINDEX)"
273 Say Y here if you want to be able to classify packets based on
274 traffic control indices. You will want this feature if you want
275 to implement Differentiated Services together with DSMARK.
277 To compile this code as a module, choose M here: the
278 module will be called cls_tcindex.
280 config NET_CLS_ROUTE4
281 tristate "Routing decision (ROUTE)"
285 If you say Y here, you will be able to classify packets
286 according to the route table entry they matched.
288 To compile this code as a module, choose M here: the
289 module will be called cls_route.
295 tristate "Netfilter mark (FW)"
298 If you say Y here, you will be able to classify packets
299 according to netfilter/firewall marks.
301 To compile this code as a module, choose M here: the
302 module will be called cls_fw.
305 tristate "Universal 32bit comparisons w/ hashing (U32)"
308 Say Y here to be able to classify packetes using a universal
309 32bit pieces based comparison scheme.
311 To compile this code as a module, choose M here: the
312 module will be called cls_u32.
315 bool "Performance counters support"
316 depends on NET_CLS_U32
318 Say Y here to make u32 gather additional statistics useful for
319 fine tuning u32 classifiers.
322 bool "Netfilter marks support"
323 depends on NET_CLS_U32 && NETFILTER
325 Say Y here to be able to use netfilter marks as u32 key.
328 tristate "IPv4 Resource Reservation Protocol (RSVP)"
332 The Resource Reservation Protocol (RSVP) permits end systems to
333 request a minimum and maximum data flow rate for a connection; this
334 is important for real time data such as streaming sound or video.
336 Say Y here if you want to be able to classify outgoing packets based
337 on their RSVP requests.
339 To compile this code as a module, choose M here: the
340 module will be called cls_rsvp.
343 tristate "IPv6 Resource Reservation Protocol (RSVP6)"
347 The Resource Reservation Protocol (RSVP) permits end systems to
348 request a minimum and maximum data flow rate for a connection; this
349 is important for real time data such as streaming sound or video.
351 Say Y here if you want to be able to classify outgoing packets based
352 on their RSVP requests and you are using the IPv6.
354 To compile this code as a module, choose M here: the
355 module will be called cls_rsvp6.
358 bool "Extended Matches"
361 Say Y here if you want to use extended matches on top of classifiers
362 and select the extended matches below.
364 Extended matches are small classification helpers not worth writing
365 a separate classifier for.
367 A recent version of the iproute2 package is required to use
370 config NET_EMATCH_STACK
372 depends on NET_EMATCH
375 Size of the local stack variable used while evaluating the tree of
376 ematches. Limits the depth of the tree, i.e. the number of
377 encapsulated precedences. Every level requires 4 bytes of additional
380 config NET_EMATCH_CMP
381 tristate "Simple packet data comparison"
382 depends on NET_EMATCH
384 Say Y here if you want to be able to classify packets based on
385 simple packet data comparisons for 8, 16, and 32bit values.
387 To compile this code as a module, choose M here: the
388 module will be called em_cmp.
390 config NET_EMATCH_NBYTE
391 tristate "Multi byte comparison"
392 depends on NET_EMATCH
394 Say Y here if you want to be able to classify packets based on
395 multiple byte comparisons mainly useful for IPv6 address comparisons.
397 To compile this code as a module, choose M here: the
398 module will be called em_nbyte.
400 config NET_EMATCH_U32
402 depends on NET_EMATCH
404 Say Y here if you want to be able to classify packets using
405 the famous u32 key in combination with logic relations.
407 To compile this code as a module, choose M here: the
408 module will be called em_u32.
410 config NET_EMATCH_META
412 depends on NET_EMATCH
414 Say Y here if you want to be ablt to classify packets based on
415 metadata such as load average, netfilter attributes, socket
416 attributes and routing decisions.
418 To compile this code as a module, choose M here: the
419 module will be called em_meta.
421 config NET_EMATCH_TEXT
422 tristate "Textsearch"
423 depends on NET_EMATCH
425 select TEXTSEARCH_KMP
427 select TEXTSEARCH_FSM
429 Say Y here if you want to be able to classify packets based on
430 textsearch comparisons.
432 To compile this code as a module, choose M here: the
433 module will be called em_text.
437 depends on EXPERIMENTAL
440 Say Y here if you want to use traffic control actions. Actions
441 get attached to classifiers and are invoked after a successful
442 classification. They are used to overwrite the classification
443 result, instantly drop or redirect packets, etc.
445 A recent version of the iproute2 package is required to use
448 config NET_ACT_POLICE
449 tristate "Traffic Policing"
450 depends on NET_CLS_ACT
452 Say Y here if you want to do traffic policing, i.e. strict
453 bandwidth limiting. This action replaces the existing policing
456 To compile this code as a module, choose M here: the
457 module will be called police.
460 tristate "Generic actions"
461 depends on NET_CLS_ACT
463 Say Y here to take generic actions such as dropping and
466 To compile this code as a module, choose M here: the
467 module will be called gact.
470 bool "Probability support"
471 depends on NET_ACT_GACT
473 Say Y here to use the generic action randomly or deterministically.
475 config NET_ACT_MIRRED
476 tristate "Redirecting and Mirroring"
477 depends on NET_CLS_ACT
479 Say Y here to allow packets to be mirrored or redirected to
482 To compile this code as a module, choose M here: the
483 module will be called mirred.
486 tristate "IPtables targets"
487 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
489 Say Y here to be able to invoke iptables targets after succesful
492 To compile this code as a module, choose M here: the
493 module will be called ipt.
496 tristate "Packet Editing"
497 depends on NET_CLS_ACT
499 Say Y here if you want to mangle the content of packets.
501 To compile this code as a module, choose M here: the
502 module will be called pedit.
505 tristate "Simple Example (Debug)"
506 depends on NET_CLS_ACT
508 Say Y here to add a simple action for demonstration purposes.
509 It is meant as an example and for debugging purposes. It will
510 print a configured policy string followed by the packet count
511 to the console for every packet that passes by.
515 To compile this code as a module, choose M here: the
516 module will be called simple.
518 config NET_CLS_POLICE
519 bool "Traffic Policing (obsolete)"
520 depends on NET_CLS_ACT!=y
523 Say Y here if you want to do traffic policing, i.e. strict
524 bandwidth limiting. This option is obsoleted by the traffic
525 policer implemented as action, it stays here for compatibility
529 bool "Incoming device classification"
530 depends on NET_CLS_U32 || NET_CLS_FW
532 Say Y here to extend the u32 and fw classifier to support
533 classification based on the incoming device. This option is
534 likely to disappear in favour of the metadata ematch.
537 bool "Rate estimator"
539 Say Y here to allow using rate estimators to estimate the current
540 rate-of-flow for network devices, queues, etc. This module is
541 automaticaly selected if needed but can be selected manually for