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 "Random Early Detection (RED)"
117 Say Y here if you want to use the Random Early Detection (RED)
118 packet scheduling algorithm.
120 See the top of <file:net/sched/sch_red.c> for more details.
122 To compile this code as a module, choose M here: the
123 module will be called sch_red.
126 tristate "Stochastic Fairness Queueing (SFQ)"
128 Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
129 packet scheduling algorithm .
131 See the top of <file:net/sched/sch_sfq.c> for more details.
133 To compile this code as a module, choose M here: the
134 module will be called sch_sfq.
137 tristate "True Link Equalizer (TEQL)"
139 Say Y here if you want to use the True Link Equalizer (TLE) packet
140 scheduling algorithm. This queueing discipline allows the combination
141 of several physical devices into one virtual device.
143 See the top of <file:net/sched/sch_teql.c> for more details.
145 To compile this code as a module, choose M here: the
146 module will be called sch_teql.
149 tristate "Token Bucket Filter (TBF)"
151 Say Y here if you want to use the Token Bucket Filter (TBF) packet
152 scheduling algorithm.
154 See the top of <file:net/sched/sch_tbf.c> for more details.
156 To compile this code as a module, choose M here: the
157 module will be called sch_tbf.
160 tristate "Generic Random Early Detection (GRED)"
162 Say Y here if you want to use the Generic Random Early Detection
163 (GRED) packet scheduling algorithm for some of your network devices
164 (see the top of <file:net/sched/sch_red.c> for details and
165 references about the algorithm).
167 To compile this code as a module, choose M here: the
168 module will be called sch_gred.
170 config NET_SCH_DSMARK
171 tristate "Differentiated Services marker (DSMARK)"
173 Say Y if you want to schedule packets according to the
174 Differentiated Services architecture proposed in RFC 2475.
175 Technical information on this method, with pointers to associated
176 RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
178 To compile this code as a module, choose M here: the
179 module will be called sch_dsmark.
182 tristate "Network emulator (NETEM)"
184 Say Y if you want to emulate network delay, loss, and packet
185 re-ordering. This is often useful to simulate networks when
186 testing applications or protocols.
188 To compile this driver as a module, choose M here: the module
189 will be called sch_netem.
193 config NET_SCH_INGRESS
194 tristate "Ingress Qdisc"
196 Say Y here if you want to use classifiers for incoming packets.
199 To compile this code as a module, choose M here: the
200 module will be called sch_ingress.
202 comment "Classification"
208 tristate "Elementary classification (BASIC)"
211 Say Y here if you want to be able to classify packets using
212 only extended matches and actions.
214 To compile this code as a module, choose M here: the
215 module will be called cls_basic.
217 config NET_CLS_TCINDEX
218 tristate "Traffic-Control Index (TCINDEX)"
221 Say Y here if you want to be able to classify packets based on
222 traffic control indices. You will want this feature if you want
223 to implement Differentiated Services together with DSMARK.
225 To compile this code as a module, choose M here: the
226 module will be called cls_tcindex.
228 config NET_CLS_ROUTE4
229 tristate "Routing decision (ROUTE)"
233 If you say Y here, you will be able to classify packets
234 according to the route table entry they matched.
236 To compile this code as a module, choose M here: the
237 module will be called cls_route.
243 tristate "Netfilter mark (FW)"
246 If you say Y here, you will be able to classify packets
247 according to netfilter/firewall marks.
249 To compile this code as a module, choose M here: the
250 module will be called cls_fw.
253 tristate "Universal 32bit comparisons w/ hashing (U32)"
256 Say Y here to be able to classify packets using a universal
257 32bit pieces based comparison scheme.
259 To compile this code as a module, choose M here: the
260 module will be called cls_u32.
263 bool "Performance counters support"
264 depends on NET_CLS_U32
266 Say Y here to make u32 gather additional statistics useful for
267 fine tuning u32 classifiers.
270 bool "Netfilter marks support"
271 depends on NET_CLS_U32
273 Say Y here to be able to use netfilter marks as u32 key.
276 tristate "IPv4 Resource Reservation Protocol (RSVP)"
280 The Resource Reservation Protocol (RSVP) permits end systems to
281 request a minimum and maximum data flow rate for a connection; this
282 is important for real time data such as streaming sound or video.
284 Say Y here if you want to be able to classify outgoing packets based
285 on their RSVP requests.
287 To compile this code as a module, choose M here: the
288 module will be called cls_rsvp.
291 tristate "IPv6 Resource Reservation Protocol (RSVP6)"
295 The Resource Reservation Protocol (RSVP) permits end systems to
296 request a minimum and maximum data flow rate for a connection; this
297 is important for real time data such as streaming sound or video.
299 Say Y here if you want to be able to classify outgoing packets based
300 on their RSVP requests and you are using the IPv6.
302 To compile this code as a module, choose M here: the
303 module will be called cls_rsvp6.
306 bool "Extended Matches"
309 Say Y here if you want to use extended matches on top of classifiers
310 and select the extended matches below.
312 Extended matches are small classification helpers not worth writing
313 a separate classifier for.
315 A recent version of the iproute2 package is required to use
318 config NET_EMATCH_STACK
320 depends on NET_EMATCH
323 Size of the local stack variable used while evaluating the tree of
324 ematches. Limits the depth of the tree, i.e. the number of
325 encapsulated precedences. Every level requires 4 bytes of additional
328 config NET_EMATCH_CMP
329 tristate "Simple packet data comparison"
330 depends on NET_EMATCH
332 Say Y here if you want to be able to classify packets based on
333 simple packet data comparisons for 8, 16, and 32bit values.
335 To compile this code as a module, choose M here: the
336 module will be called em_cmp.
338 config NET_EMATCH_NBYTE
339 tristate "Multi byte comparison"
340 depends on NET_EMATCH
342 Say Y here if you want to be able to classify packets based on
343 multiple byte comparisons mainly useful for IPv6 address comparisons.
345 To compile this code as a module, choose M here: the
346 module will be called em_nbyte.
348 config NET_EMATCH_U32
350 depends on NET_EMATCH
352 Say Y here if you want to be able to classify packets using
353 the famous u32 key in combination with logic relations.
355 To compile this code as a module, choose M here: the
356 module will be called em_u32.
358 config NET_EMATCH_META
360 depends on NET_EMATCH
362 Say Y here if you want to be able to classify packets based on
363 metadata such as load average, netfilter attributes, socket
364 attributes and routing decisions.
366 To compile this code as a module, choose M here: the
367 module will be called em_meta.
369 config NET_EMATCH_TEXT
370 tristate "Textsearch"
371 depends on NET_EMATCH
373 select TEXTSEARCH_KMP
375 select TEXTSEARCH_FSM
377 Say Y here if you want to be able to classify packets based on
378 textsearch comparisons.
380 To compile this code as a module, choose M here: the
381 module will be called em_text.
387 Say Y here if you want to use traffic control actions. Actions
388 get attached to classifiers and are invoked after a successful
389 classification. They are used to overwrite the classification
390 result, instantly drop or redirect packets, etc.
392 A recent version of the iproute2 package is required to use
395 config NET_ACT_POLICE
396 tristate "Traffic Policing"
397 depends on NET_CLS_ACT
399 Say Y here if you want to do traffic policing, i.e. strict
400 bandwidth limiting. This action replaces the existing policing
403 To compile this code as a module, choose M here: the
404 module will be called police.
407 tristate "Generic actions"
408 depends on NET_CLS_ACT
410 Say Y here to take generic actions such as dropping and
413 To compile this code as a module, choose M here: the
414 module will be called gact.
417 bool "Probability support"
418 depends on NET_ACT_GACT
420 Say Y here to use the generic action randomly or deterministically.
422 config NET_ACT_MIRRED
423 tristate "Redirecting and Mirroring"
424 depends on NET_CLS_ACT
426 Say Y here to allow packets to be mirrored or redirected to
429 To compile this code as a module, choose M here: the
430 module will be called mirred.
433 tristate "IPtables targets"
434 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
436 Say Y here to be able to invoke iptables targets after successful
439 To compile this code as a module, choose M here: the
440 module will be called ipt.
443 tristate "Packet Editing"
444 depends on NET_CLS_ACT
446 Say Y here if you want to mangle the content of packets.
448 To compile this code as a module, choose M here: the
449 module will be called pedit.
452 tristate "Simple Example (Debug)"
453 depends on NET_CLS_ACT
455 Say Y here to add a simple action for demonstration purposes.
456 It is meant as an example and for debugging purposes. It will
457 print a configured policy string followed by the packet count
458 to the console for every packet that passes by.
462 To compile this code as a module, choose M here: the
463 module will be called simple.
465 config NET_CLS_POLICE
466 bool "Traffic Policing (obsolete)"
467 depends on NET_CLS_ACT!=y
470 Say Y here if you want to do traffic policing, i.e. strict
471 bandwidth limiting. This option is obsoleted by the traffic
472 policer implemented as action, it stays here for compatibility
476 bool "Incoming device classification"
477 depends on NET_CLS_U32 || NET_CLS_FW
479 Say Y here to extend the u32 and fw classifier to support
480 classification based on the incoming device. This option is
481 likely to disappear in favour of the metadata ematch.
484 bool "Rate estimator"
486 Say Y here to allow using rate estimators to estimate the current
487 rate-of-flow for network devices, queues, etc. This module is
488 automatically selected if needed but can be selected manually for
489 statistical purposes.
projects / linux-2.6 / blob