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.
49 comment "Queueing/Scheduling"
52 tristate "Class Based Queueing (CBQ)"
54 Say Y here if you want to use the Class-Based Queueing (CBQ) packet
55 scheduling algorithm. This algorithm classifies the waiting packets
56 into a tree-like hierarchy of classes; the leaves of this tree are
57 in turn scheduled by separate algorithms.
59 See the top of <file:net/sched/sch_cbq.c> for more details.
61 CBQ is a commonly used scheduler, so if you're unsure, you should
62 say Y here. Then say Y to all the queueing algorithms below that you
63 want to use as leaf disciplines.
65 To compile this code as a module, choose M here: the
66 module will be called sch_cbq.
69 tristate "Hierarchical Token Bucket (HTB)"
71 Say Y here if you want to use the Hierarchical Token Buckets (HTB)
72 packet scheduling algorithm. See
73 <http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
76 HTB is very similar to CBQ regarding its goals however is has
77 different properties and different algorithm.
79 To compile this code as a module, choose M here: the
80 module will be called sch_htb.
83 tristate "Hierarchical Fair Service Curve (HFSC)"
85 Say Y here if you want to use the Hierarchical Fair Service Curve
86 (HFSC) packet scheduling algorithm.
88 To compile this code as a module, choose M here: the
89 module will be called sch_hfsc.
92 tristate "ATM Virtual Circuits (ATM)"
95 Say Y here if you want to use the ATM pseudo-scheduler. This
96 provides a framework for invoking classifiers, which in turn
97 select classes of this queuing discipline. Each class maps
98 the flow(s) it is handling to a given virtual circuit.
100 See the top of <file:net/sched/sch_atm.c>) for more details.
102 To compile this code as a module, choose M here: the
103 module will be called sch_atm.
106 tristate "Multi Band Priority Queueing (PRIO)"
108 Say Y here if you want to use an n-band priority queue packet
111 To compile this code as a module, choose M here: the
112 module will be called sch_prio.
115 tristate "Multi Band Round Robin Queuing (RR)"
118 Say Y here if you want to use an n-band round robin packet
121 The module uses sch_prio for its framework and is aliased as
122 sch_rr, so it will load sch_prio, although it is referred
126 tristate "Random Early Detection (RED)"
128 Say Y here if you want to use the Random Early Detection (RED)
129 packet scheduling algorithm.
131 See the top of <file:net/sched/sch_red.c> for more details.
133 To compile this code as a module, choose M here: the
134 module will be called sch_red.
137 tristate "Stochastic Fairness Queueing (SFQ)"
139 Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
140 packet scheduling algorithm .
142 See the top of <file:net/sched/sch_sfq.c> for more details.
144 To compile this code as a module, choose M here: the
145 module will be called sch_sfq.
148 tristate "True Link Equalizer (TEQL)"
150 Say Y here if you want to use the True Link Equalizer (TLE) packet
151 scheduling algorithm. This queueing discipline allows the combination
152 of several physical devices into one virtual device.
154 See the top of <file:net/sched/sch_teql.c> for more details.
156 To compile this code as a module, choose M here: the
157 module will be called sch_teql.
160 tristate "Token Bucket Filter (TBF)"
162 Say Y here if you want to use the Token Bucket Filter (TBF) packet
163 scheduling algorithm.
165 See the top of <file:net/sched/sch_tbf.c> for more details.
167 To compile this code as a module, choose M here: the
168 module will be called sch_tbf.
171 tristate "Generic Random Early Detection (GRED)"
173 Say Y here if you want to use the Generic Random Early Detection
174 (GRED) packet scheduling algorithm for some of your network devices
175 (see the top of <file:net/sched/sch_red.c> for details and
176 references about the algorithm).
178 To compile this code as a module, choose M here: the
179 module will be called sch_gred.
181 config NET_SCH_DSMARK
182 tristate "Differentiated Services marker (DSMARK)"
184 Say Y if you want to schedule packets according to the
185 Differentiated Services architecture proposed in RFC 2475.
186 Technical information on this method, with pointers to associated
187 RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
189 To compile this code as a module, choose M here: the
190 module will be called sch_dsmark.
193 tristate "Network emulator (NETEM)"
195 Say Y if you want to emulate network delay, loss, and packet
196 re-ordering. This is often useful to simulate networks when
197 testing applications or protocols.
199 To compile this driver as a module, choose M here: the module
200 will be called sch_netem.
204 config NET_SCH_INGRESS
205 tristate "Ingress Qdisc"
207 Say Y here if you want to use classifiers for incoming packets.
210 To compile this code as a module, choose M here: the
211 module will be called sch_ingress.
213 comment "Classification"
219 tristate "Elementary classification (BASIC)"
222 Say Y here if you want to be able to classify packets using
223 only extended matches and actions.
225 To compile this code as a module, choose M here: the
226 module will be called cls_basic.
228 config NET_CLS_TCINDEX
229 tristate "Traffic-Control Index (TCINDEX)"
232 Say Y here if you want to be able to classify packets based on
233 traffic control indices. You will want this feature if you want
234 to implement Differentiated Services together with DSMARK.
236 To compile this code as a module, choose M here: the
237 module will be called cls_tcindex.
239 config NET_CLS_ROUTE4
240 tristate "Routing decision (ROUTE)"
244 If you say Y here, you will be able to classify packets
245 according to the route table entry they matched.
247 To compile this code as a module, choose M here: the
248 module will be called cls_route.
254 tristate "Netfilter mark (FW)"
257 If you say Y here, you will be able to classify packets
258 according to netfilter/firewall marks.
260 To compile this code as a module, choose M here: the
261 module will be called cls_fw.
264 tristate "Universal 32bit comparisons w/ hashing (U32)"
267 Say Y here to be able to classify packets using a universal
268 32bit pieces based comparison scheme.
270 To compile this code as a module, choose M here: the
271 module will be called cls_u32.
274 bool "Performance counters support"
275 depends on NET_CLS_U32
277 Say Y here to make u32 gather additional statistics useful for
278 fine tuning u32 classifiers.
281 bool "Netfilter marks support"
282 depends on NET_CLS_U32
284 Say Y here to be able to use netfilter marks as u32 key.
287 tristate "IPv4 Resource Reservation Protocol (RSVP)"
291 The Resource Reservation Protocol (RSVP) permits end systems to
292 request a minimum and maximum data flow rate for a connection; this
293 is important for real time data such as streaming sound or video.
295 Say Y here if you want to be able to classify outgoing packets based
296 on their RSVP requests.
298 To compile this code as a module, choose M here: the
299 module will be called cls_rsvp.
302 tristate "IPv6 Resource Reservation Protocol (RSVP6)"
306 The Resource Reservation Protocol (RSVP) permits end systems to
307 request a minimum and maximum data flow rate for a connection; this
308 is important for real time data such as streaming sound or video.
310 Say Y here if you want to be able to classify outgoing packets based
311 on their RSVP requests and you are using the IPv6.
313 To compile this code as a module, choose M here: the
314 module will be called cls_rsvp6.
317 bool "Extended Matches"
320 Say Y here if you want to use extended matches on top of classifiers
321 and select the extended matches below.
323 Extended matches are small classification helpers not worth writing
324 a separate classifier for.
326 A recent version of the iproute2 package is required to use
329 config NET_EMATCH_STACK
331 depends on NET_EMATCH
334 Size of the local stack variable used while evaluating the tree of
335 ematches. Limits the depth of the tree, i.e. the number of
336 encapsulated precedences. Every level requires 4 bytes of additional
339 config NET_EMATCH_CMP
340 tristate "Simple packet data comparison"
341 depends on NET_EMATCH
343 Say Y here if you want to be able to classify packets based on
344 simple packet data comparisons for 8, 16, and 32bit values.
346 To compile this code as a module, choose M here: the
347 module will be called em_cmp.
349 config NET_EMATCH_NBYTE
350 tristate "Multi byte comparison"
351 depends on NET_EMATCH
353 Say Y here if you want to be able to classify packets based on
354 multiple byte comparisons mainly useful for IPv6 address comparisons.
356 To compile this code as a module, choose M here: the
357 module will be called em_nbyte.
359 config NET_EMATCH_U32
361 depends on NET_EMATCH
363 Say Y here if you want to be able to classify packets using
364 the famous u32 key in combination with logic relations.
366 To compile this code as a module, choose M here: the
367 module will be called em_u32.
369 config NET_EMATCH_META
371 depends on NET_EMATCH
373 Say Y here if you want to be able to classify packets based on
374 metadata such as load average, netfilter attributes, socket
375 attributes and routing decisions.
377 To compile this code as a module, choose M here: the
378 module will be called em_meta.
380 config NET_EMATCH_TEXT
381 tristate "Textsearch"
382 depends on NET_EMATCH
384 select TEXTSEARCH_KMP
386 select TEXTSEARCH_FSM
388 Say Y here if you want to be able to classify packets based on
389 textsearch comparisons.
391 To compile this code as a module, choose M here: the
392 module will be called em_text.
398 Say Y here if you want to use traffic control actions. Actions
399 get attached to classifiers and are invoked after a successful
400 classification. They are used to overwrite the classification
401 result, instantly drop or redirect packets, etc.
403 A recent version of the iproute2 package is required to use
406 config NET_ACT_POLICE
407 tristate "Traffic Policing"
408 depends on NET_CLS_ACT
410 Say Y here if you want to do traffic policing, i.e. strict
411 bandwidth limiting. This action replaces the existing policing
414 To compile this code as a module, choose M here: the
415 module will be called police.
418 tristate "Generic actions"
419 depends on NET_CLS_ACT
421 Say Y here to take generic actions such as dropping and
424 To compile this code as a module, choose M here: the
425 module will be called gact.
428 bool "Probability support"
429 depends on NET_ACT_GACT
431 Say Y here to use the generic action randomly or deterministically.
433 config NET_ACT_MIRRED
434 tristate "Redirecting and Mirroring"
435 depends on NET_CLS_ACT
437 Say Y here to allow packets to be mirrored or redirected to
440 To compile this code as a module, choose M here: the
441 module will be called mirred.
444 tristate "IPtables targets"
445 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
447 Say Y here to be able to invoke iptables targets after successful
450 To compile this code as a module, choose M here: the
451 module will be called ipt.
454 tristate "Packet Editing"
455 depends on NET_CLS_ACT
457 Say Y here if you want to mangle the content of packets.
459 To compile this code as a module, choose M here: the
460 module will be called pedit.
463 tristate "Simple Example (Debug)"
464 depends on NET_CLS_ACT
466 Say Y here to add a simple action for demonstration purposes.
467 It is meant as an example and for debugging purposes. It will
468 print a configured policy string followed by the packet count
469 to the console for every packet that passes by.
473 To compile this code as a module, choose M here: the
474 module will be called simple.
476 config NET_CLS_POLICE
477 bool "Traffic Policing (obsolete)"
478 depends on NET_CLS_ACT!=y
481 Say Y here if you want to do traffic policing, i.e. strict
482 bandwidth limiting. This option is obsoleted by the traffic
483 policer implemented as action, it stays here for compatibility
487 bool "Incoming device classification"
488 depends on NET_CLS_U32 || NET_CLS_FW
490 Say Y here to extend the u32 and fw classifier to support
491 classification based on the incoming device. This option is
492 likely to disappear in favour of the metadata ematch.
495 bool "Rate estimator"
497 Say Y here to allow using rate estimators to estimate the current
498 rate-of-flow for network devices, queues, etc. This module is
499 automatically selected if needed but can be selected manually for
500 statistical purposes.