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)"
290 The Resource Reservation Protocol (RSVP) permits end systems to
291 request a minimum and maximum data flow rate for a connection; this
292 is important for real time data such as streaming sound or video.
294 Say Y here if you want to be able to classify outgoing packets based
295 on their RSVP requests.
297 To compile this code as a module, choose M here: the
298 module will be called cls_rsvp.
301 tristate "IPv6 Resource Reservation Protocol (RSVP6)"
304 The Resource Reservation Protocol (RSVP) permits end systems to
305 request a minimum and maximum data flow rate for a connection; this
306 is important for real time data such as streaming sound or video.
308 Say Y here if you want to be able to classify outgoing packets based
309 on their RSVP requests and you are using the IPv6 protocol.
311 To compile this code as a module, choose M here: the
312 module will be called cls_rsvp6.
315 bool "Extended Matches"
318 Say Y here if you want to use extended matches on top of classifiers
319 and select the extended matches below.
321 Extended matches are small classification helpers not worth writing
322 a separate classifier for.
324 A recent version of the iproute2 package is required to use
327 config NET_EMATCH_STACK
329 depends on NET_EMATCH
332 Size of the local stack variable used while evaluating the tree of
333 ematches. Limits the depth of the tree, i.e. the number of
334 encapsulated precedences. Every level requires 4 bytes of additional
337 config NET_EMATCH_CMP
338 tristate "Simple packet data comparison"
339 depends on NET_EMATCH
341 Say Y here if you want to be able to classify packets based on
342 simple packet data comparisons for 8, 16, and 32bit values.
344 To compile this code as a module, choose M here: the
345 module will be called em_cmp.
347 config NET_EMATCH_NBYTE
348 tristate "Multi byte comparison"
349 depends on NET_EMATCH
351 Say Y here if you want to be able to classify packets based on
352 multiple byte comparisons mainly useful for IPv6 address comparisons.
354 To compile this code as a module, choose M here: the
355 module will be called em_nbyte.
357 config NET_EMATCH_U32
359 depends on NET_EMATCH
361 Say Y here if you want to be able to classify packets using
362 the famous u32 key in combination with logic relations.
364 To compile this code as a module, choose M here: the
365 module will be called em_u32.
367 config NET_EMATCH_META
369 depends on NET_EMATCH
371 Say Y here if you want to be able to classify packets based on
372 metadata such as load average, netfilter attributes, socket
373 attributes and routing decisions.
375 To compile this code as a module, choose M here: the
376 module will be called em_meta.
378 config NET_EMATCH_TEXT
379 tristate "Textsearch"
380 depends on NET_EMATCH
382 select TEXTSEARCH_KMP
384 select TEXTSEARCH_FSM
386 Say Y here if you want to be able to classify packets based on
387 textsearch comparisons.
389 To compile this code as a module, choose M here: the
390 module will be called em_text.
395 Say Y here if you want to use traffic control actions. Actions
396 get attached to classifiers and are invoked after a successful
397 classification. They are used to overwrite the classification
398 result, instantly drop or redirect packets, etc.
400 A recent version of the iproute2 package is required to use
403 config NET_ACT_POLICE
404 tristate "Traffic Policing"
405 depends on NET_CLS_ACT
407 Say Y here if you want to do traffic policing, i.e. strict
408 bandwidth limiting. This action replaces the existing policing
411 To compile this code as a module, choose M here: the
412 module will be called police.
415 tristate "Generic actions"
416 depends on NET_CLS_ACT
418 Say Y here to take generic actions such as dropping and
421 To compile this code as a module, choose M here: the
422 module will be called gact.
425 bool "Probability support"
426 depends on NET_ACT_GACT
428 Say Y here to use the generic action randomly or deterministically.
430 config NET_ACT_MIRRED
431 tristate "Redirecting and Mirroring"
432 depends on NET_CLS_ACT
434 Say Y here to allow packets to be mirrored or redirected to
437 To compile this code as a module, choose M here: the
438 module will be called mirred.
441 tristate "IPtables targets"
442 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
444 Say Y here to be able to invoke iptables targets after successful
447 To compile this code as a module, choose M here: the
448 module will be called ipt.
451 tristate "Packet Editing"
452 depends on NET_CLS_ACT
454 Say Y here if you want to mangle the content of packets.
456 To compile this code as a module, choose M here: the
457 module will be called pedit.
460 tristate "Simple Example (Debug)"
461 depends on NET_CLS_ACT
463 Say Y here to add a simple action for demonstration purposes.
464 It is meant as an example and for debugging purposes. It will
465 print a configured policy string followed by the packet count
466 to the console for every packet that passes by.
470 To compile this code as a module, choose M here: the
471 module will be called simple.
473 config NET_CLS_POLICE
474 bool "Traffic Policing (obsolete)"
476 select NET_ACT_POLICE
478 Say Y here if you want to do traffic policing, i.e. strict
479 bandwidth limiting. This option is obsolete and just selects
480 the option replacing it. It will be removed in the future.
483 bool "Incoming device classification"
484 depends on NET_CLS_U32 || NET_CLS_FW
486 Say Y here to extend the u32 and fw classifier to support
487 classification based on the incoming device. This option is
488 likely to disappear in favour of the metadata ematch.