2 # Traffic control configuration.
6 bool "QoS and/or fair queueing"
8 When the kernel has several packets to send out over a network
9 device, it has to decide which ones to send first, which ones to
10 delay, and which ones to drop. This is the job of the packet
11 scheduler, and several different algorithms for how to do this
12 "fairly" have been proposed.
14 If you say N here, you will get the standard packet scheduler, which
15 is a FIFO (first come, first served). If you say Y here, you will be
16 able to choose from among several alternative algorithms which can
17 then be attached to different network devices. This is useful for
18 example if some of your network devices are real time devices that
19 need a certain minimum data flow rate, or if you need to limit the
20 maximum data flow rate for traffic which matches specified criteria.
21 This code is considered to be experimental.
23 To administer these schedulers, you'll need the user-level utilities
24 from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
25 That package also contains some documentation; for more, check out
26 <http://snafu.freedom.org/linux2.2/iproute-notes.html>.
28 This Quality of Service (QoS) support will enable you to use
29 Differentiated Services (diffserv) and Resource Reservation Protocol
30 (RSVP) on your Linux router if you also say Y to "QoS support",
31 "Packet classifier API" and to some classifiers below. Documentation
32 and software is at <http://diffserv.sourceforge.net/>.
34 If you say Y here and to "/proc file system" below, you will be able
35 to read status information about packet schedulers from the file
38 The available schedulers are listed in the following questions; you
39 can say Y to as many as you like. If unsure, say N now.
42 prompt "Packet scheduler clock source"
44 default NET_SCH_CLK_JIFFIES
46 Packet schedulers need a monotonic clock that increments at a static
47 rate. The kernel provides several suitable interfaces, each with
50 - high resolution (us or better)
51 - fast to read (minimal locking, no i/o access)
52 - synchronized on all processors
53 - handles cpu clock frequency changes
55 but nothing provides all of the above.
57 config NET_SCH_CLK_JIFFIES
58 bool "Timer interrupt"
60 Say Y here if you want to use the timer interrupt (jiffies) as clock
61 source. This clock source is fast, synchronized on all processors and
62 handles cpu clock frequency changes, but its resolution is too low
63 for accurate shaping except at very low speed.
65 config NET_SCH_CLK_GETTIMEOFDAY
68 Say Y here if you want to use gettimeofday as clock source. This clock
69 source has high resolution, is synchronized on all processors and
70 handles cpu clock frequency changes, but it is slow.
72 Choose this if you need a high resolution clock source but can't use
73 the CPU's cycle counter.
75 config NET_SCH_CLK_CPU
76 bool "CPU cycle counter"
77 depends on X86_TSC || X86_64 || ALPHA || SPARC64 || PPC64 || IA64
79 Say Y here if you want to use the CPU's cycle counter as clock source.
80 This is a cheap and high resolution clock source, but on some
81 architectures it is not synchronized on all processors and doesn't
82 handle cpu clock frequency changes.
84 The useable cycle counters are:
86 x86/x86_64 - Timestamp Counter
88 sparc64 - %ticks register
90 ia64 - Interval Time Counter
92 Choose this if your CPU's cycle counter is working properly.
97 tristate "CBQ packet scheduler"
100 Say Y here if you want to use the Class-Based Queueing (CBQ) packet
101 scheduling algorithm for some of your network devices. This
102 algorithm classifies the waiting packets into a tree-like hierarchy
103 of classes; the leaves of this tree are in turn scheduled by
104 separate algorithms (called "disciplines" in this context).
106 See the top of <file:net/sched/sch_cbq.c> for references about the
109 CBQ is a commonly used scheduler, so if you're unsure, you should
110 say Y here. Then say Y to all the queueing algorithms below that you
111 want to use as CBQ disciplines. Then say Y to "Packet classifier
112 API" and say Y to all the classifiers you want to use; a classifier
113 is a routine that allows you to sort your outgoing traffic into
114 classes based on a certain criterion.
116 To compile this code as a module, choose M here: the
117 module will be called sch_cbq.
120 tristate "HTB packet scheduler"
123 Say Y here if you want to use the Hierarchical Token Buckets (HTB)
124 packet scheduling algorithm for some of your network devices. See
125 <http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
128 HTB is very similar to the 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 "HFSC packet scheduler"
138 Say Y here if you want to use the Hierarchical Fair Service Curve
139 (HFSC) packet scheduling algorithm for some of your network devices.
141 To compile this code as a module, choose M here: the
142 module will be called sch_hfsc.
144 #tristate ' H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ
146 tristate "ATM pseudo-scheduler"
147 depends on NET_SCHED && ATM
149 Say Y here if you want to use the ATM pseudo-scheduler. This
150 provides a framework for invoking classifiers (aka "filters"), which
151 in turn select classes of this queuing discipline. Each class maps
152 the flow(s) it is handling to a given virtual circuit (see the top of
153 <file:net/sched/sch_atm.c>).
155 To compile this code as a module, choose M here: the
156 module will be called sch_atm.
159 tristate "The simplest PRIO pseudoscheduler"
162 Say Y here if you want to use an n-band priority queue packet
163 "scheduler" for some of your network devices or as a leaf discipline
164 for the CBQ scheduling algorithm. If unsure, say Y.
166 To compile this code as a module, choose M here: the
167 module will be called sch_prio.
173 Say Y here if you want to use the Random Early Detection (RED)
174 packet scheduling algorithm for some of your network devices (see
175 the top of <file:net/sched/sch_red.c> for details and references
176 about the algorithm).
178 To compile this code as a module, choose M here: the
179 module will be called sch_red.
185 Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
186 packet scheduling algorithm for some of your network devices or as a
187 leaf discipline for the CBQ scheduling algorithm (see the top of
188 <file:net/sched/sch_sfq.c> for details and references about the SFQ
191 To compile this code as a module, choose M here: the
192 module will be called sch_sfq.
195 tristate "TEQL queue"
198 Say Y here if you want to use the True Link Equalizer (TLE) packet
199 scheduling algorithm for some of your network devices or as a leaf
200 discipline for the CBQ scheduling algorithm. This queueing
201 discipline allows the combination of several physical devices into
202 one virtual device. (see the top of <file:net/sched/sch_teql.c> for
205 To compile this code as a module, choose M here: the
206 module will be called sch_teql.
212 Say Y here if you want to use the Simple Token Bucket Filter (TBF)
213 packet scheduling algorithm for some of your network devices or as a
214 leaf discipline for the CBQ scheduling algorithm (see the top of
215 <file:net/sched/sch_tbf.c> for a description of the TBF algorithm).
217 To compile this code as a module, choose M here: the
218 module will be called sch_tbf.
221 tristate "GRED queue"
224 Say Y here if you want to use the Generic Random Early Detection
225 (GRED) packet scheduling algorithm for some of your network devices
226 (see the top of <file:net/sched/sch_red.c> for details and
227 references about the algorithm).
229 To compile this code as a module, choose M here: the
230 module will be called sch_gred.
232 config NET_SCH_DSMARK
233 tristate "Diffserv field marker"
236 Say Y if you want to schedule packets according to the
237 Differentiated Services architecture proposed in RFC 2475.
238 Technical information on this method, with pointers to associated
239 RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
241 To compile this code as a module, choose M here: the
242 module will be called sch_dsmark.
245 tristate "Network emulator"
248 Say Y if you want to emulate network delay, loss, and packet
249 re-ordering. This is often useful to simulate networks when
250 testing applications or protocols.
252 To compile this driver as a module, choose M here: the module
253 will be called sch_netem.
257 config NET_SCH_INGRESS
258 tristate "Ingress Qdisc"
261 If you say Y here, you will be able to police incoming bandwidth
262 and drop packets when this bandwidth exceeds your desired rate.
265 To compile this code as a module, choose M here: the
266 module will be called sch_ingress.
272 Say Y here if you want to include Quality Of Service scheduling
273 features, which means that you will be able to request certain
274 rate-of-flow limits for your network devices.
276 This Quality of Service (QoS) support will enable you to use
277 Differentiated Services (diffserv) and Resource Reservation Protocol
278 (RSVP) on your Linux router if you also say Y to "Packet classifier
279 API" and to some classifiers below. Documentation and software is at
280 <http://diffserv.sourceforge.net/>.
282 Note that the answer to this question won't directly affect the
283 kernel: saying N will just cause the configurator to skip all
284 the questions about QoS support.
287 bool "Rate estimator"
290 In order for Quality of Service scheduling to work, the current
291 rate-of-flow for a network device has to be estimated; if you say Y
292 here, the kernel will do just that.
295 bool "Packet classifier API"
298 The CBQ scheduling algorithm requires that network packets which are
299 scheduled to be sent out over a network device be classified
300 according to some criterion. If you say Y here, you will get a
301 choice of several different packet classifiers with the following
304 This will enable you to use Differentiated Services (diffserv) and
305 Resource Reservation Protocol (RSVP) on your Linux router.
306 Documentation and software is at
307 <http://diffserv.sourceforge.net/>.
310 tristate "Basic classifier"
313 Say Y here if you want to be able to classify packets using
314 only extended matches and actions.
316 To compile this code as a module, choose M here: the
317 module will be called cls_basic.
319 config NET_CLS_TCINDEX
320 tristate "TC index classifier"
323 If you say Y here, you will be able to classify outgoing packets
324 according to the tc_index field of the skb. You will want this
325 feature if you want to implement Differentiated Services using
326 sch_dsmark. If unsure, say Y.
328 To compile this code as a module, choose M here: the
329 module will be called cls_tcindex.
331 config NET_CLS_ROUTE4
332 tristate "Routing table based classifier"
336 If you say Y here, you will be able to classify outgoing packets
337 according to the route table entry they matched. If unsure, say Y.
339 To compile this code as a module, choose M here: the
340 module will be called cls_route.
347 tristate "Firewall based classifier"
350 If you say Y here, you will be able to classify outgoing packets
351 according to firewall criteria you specified.
353 To compile this code as a module, choose M here: the
354 module will be called cls_fw.
357 tristate "U32 classifier"
360 If you say Y here, you will be able to classify outgoing packets
361 according to their destination address. If unsure, say Y.
363 To compile this code as a module, choose M here: the
364 module will be called cls_u32.
367 bool "U32 classifier performance counters"
368 depends on NET_CLS_U32
370 gathers stats that could be used to tune u32 classifier performance.
371 Requires a new iproute2
372 You MUST NOT turn this on if you dont have an update iproute2.
375 bool "classify input device (slows things u32/fw) "
376 depends on NET_CLS_U32 || NET_CLS_FW
378 This option will be killed eventually when a
379 metadata action appears because it slows things a little
380 Available only for u32 and fw classifiers.
381 Requires a new iproute2
382 You MUST NOT turn this on if you dont have an update iproute2.
385 bool "Use nfmark as a key in U32 classifier"
386 depends on NET_CLS_U32 && NETFILTER
388 This allows you to match mark in a u32 filter.
390 tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \
391 match mark 0x0090 0xffff \
392 match ip dst 4.4.4.4 \
394 You must use a new iproute2 to use this feature.
397 tristate "Special RSVP classifier"
398 depends on NET_CLS && NET_QOS
400 The Resource Reservation Protocol (RSVP) permits end systems to
401 request a minimum and maximum data flow rate for a connection; this
402 is important for real time data such as streaming sound or video.
404 Say Y here if you want to be able to classify outgoing packets based
405 on their RSVP requests.
407 To compile this code as a module, choose M here: the
408 module will be called cls_rsvp.
411 tristate "Special RSVP classifier for IPv6"
412 depends on NET_CLS && NET_QOS
414 The Resource Reservation Protocol (RSVP) permits end systems to
415 request a minimum and maximum data flow rate for a connection; this
416 is important for real time data such as streaming sound or video.
418 Say Y here if you want to be able to classify outgoing packets based
419 on their RSVP requests and you are using the new Internet Protocol
420 IPv6 as opposed to the older and more common IPv4.
422 To compile this code as a module, choose M here: the
423 module will be called cls_rsvp6.
426 bool "Extended Matches"
429 Say Y here if you want to use extended matches on top of classifiers
430 and select the extended matches below.
432 Extended matches are small classification helpers not worth writing
433 a separate classifier.
435 You must have a recent version of the iproute2 tools in order to use
438 config NET_EMATCH_STACK
440 depends on NET_EMATCH
443 Size of the local stack variable used while evaluating the tree of
444 ematches. Limits the depth of the tree, i.e. the number of
445 encapsulated precedences. Every level requires 4 bytes of additional
448 config NET_EMATCH_CMP
449 tristate "Simple packet data comparison"
450 depends on NET_EMATCH
452 Say Y here if you want to be able to classify packets based on
453 simple packet data comparisons for 8, 16, and 32bit values.
455 To compile this code as a module, choose M here: the
456 module will be called em_cmp.
458 config NET_EMATCH_NBYTE
459 tristate "Multi byte comparison"
460 depends on NET_EMATCH
462 Say Y here if you want to be able to classify packets based on
463 multiple byte comparisons mainly useful for IPv6 address comparisons.
465 To compile this code as a module, choose M here: the
466 module will be called em_nbyte.
468 config NET_EMATCH_U32
469 tristate "U32 hashing key"
470 depends on NET_EMATCH
472 Say Y here if you want to be able to classify packets using
473 the famous u32 key in combination with logic relations.
475 To compile this code as a module, choose M here: the
476 module will be called em_u32.
478 config NET_EMATCH_META
480 depends on NET_EMATCH
482 Say Y here if you want to be ablt to classify packets based on
483 metadata such as load average, netfilter attributes, socket
484 attributes and routing decisions.
486 To compile this code as a module, choose M here: the
487 module will be called em_meta.
489 config NET_EMATCH_TEXT
490 tristate "Textsearch"
491 depends on NET_EMATCH
493 select TEXTSEARCH_KMP
494 select TEXTSEARCH_FSM
496 Say Y here if you want to be ablt to classify packets based on
497 textsearch comparisons.
499 To compile this code as a module, choose M here: the
500 module will be called em_text.
504 depends on EXPERIMENTAL && NET_CLS && NET_QOS
506 This option requires you have a new iproute2. It enables
507 tc extensions which can be used with tc classifiers.
508 You MUST NOT turn this on if you dont have an update iproute2.
510 config NET_ACT_POLICE
511 tristate "Policing Actions"
512 depends on NET_CLS_ACT
514 If you are using a newer iproute2 select this one, otherwise use one
515 below to select a policer.
516 You MUST NOT turn this on if you dont have an update iproute2.
519 tristate "generic Actions"
520 depends on NET_CLS_ACT
522 You must have new iproute2 to use this feature.
523 This adds simple filtering actions like drop, accept etc.
526 bool "generic Actions probability"
527 depends on NET_ACT_GACT
529 Allows generic actions to be randomly or deterministically used.
531 config NET_ACT_MIRRED
532 tristate "Packet In/Egress redirecton/mirror Actions"
533 depends on NET_CLS_ACT
535 requires new iproute2
536 This allows packets to be mirrored or redirected to netdevices
539 tristate "iptables Actions"
540 depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
542 requires new iproute2
543 This allows iptables targets to be used by tc filters
546 tristate "Generic Packet Editor Actions"
547 depends on NET_CLS_ACT
549 requires new iproute2
550 This allows for packets to be generically edited
552 config NET_CLS_POLICE
553 bool "Traffic policing (needed for in/egress)"
554 depends on NET_CLS && NET_QOS && NET_CLS_ACT!=y
556 Say Y to support traffic policing (bandwidth limits). Needed for
557 ingress and egress rate limiting.
560 tristate "Simple action"
561 depends on NET_CLS_ACT
563 You must have new iproute2 to use this feature.
564 This adds a very simple action for demonstration purposes
565 The idea is to give action authors a basic example to look at.
566 All this action will do is print on the console the configured
567 policy string followed by _ then packet count.