Merge of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
[linux-2.6] / net / sched / Kconfig
1 #
2 # Traffic control configuration.
3
4 choice
5         prompt "Packet scheduler clock source"
6         depends on NET_SCHED
7         default NET_SCH_CLK_JIFFIES
8         help
9           Packet schedulers need a monotonic clock that increments at a static
10           rate. The kernel provides several suitable interfaces, each with
11           different properties:
12           
13           - high resolution (us or better)
14           - fast to read (minimal locking, no i/o access)
15           - synchronized on all processors
16           - handles cpu clock frequency changes
17
18           but nothing provides all of the above.
19
20 config NET_SCH_CLK_JIFFIES
21         bool "Timer interrupt"
22         help
23           Say Y here if you want to use the timer interrupt (jiffies) as clock
24           source. This clock source is fast, synchronized on all processors and
25           handles cpu clock frequency changes, but its resolution is too low
26           for accurate shaping except at very low speed.
27
28 config NET_SCH_CLK_GETTIMEOFDAY
29         bool "gettimeofday"
30         help
31           Say Y here if you want to use gettimeofday as clock source. This clock
32           source has high resolution, is synchronized on all processors and
33           handles cpu clock frequency changes, but it is slow.
34
35           Choose this if you need a high resolution clock source but can't use
36           the CPU's cycle counter.
37
38 config NET_SCH_CLK_CPU
39         bool "CPU cycle counter"
40         depends on X86_TSC || X86_64 || ALPHA || SPARC64 || PPC64 || IA64
41         help
42           Say Y here if you want to use the CPU's cycle counter as clock source.
43           This is a cheap and high resolution clock source, but on some
44           architectures it is not synchronized on all processors and doesn't
45           handle cpu clock frequency changes.
46
47           The useable cycle counters are:
48
49                 x86/x86_64      - Timestamp Counter
50                 alpha           - Cycle Counter
51                 sparc64         - %ticks register
52                 ppc64           - Time base
53                 ia64            - Interval Time Counter
54
55           Choose this if your CPU's cycle counter is working properly.
56
57 endchoice
58
59 config NET_SCH_CBQ
60         tristate "CBQ packet scheduler"
61         depends on NET_SCHED
62         ---help---
63           Say Y here if you want to use the Class-Based Queueing (CBQ) packet
64           scheduling algorithm for some of your network devices.  This
65           algorithm classifies the waiting packets into a tree-like hierarchy
66           of classes; the leaves of this tree are in turn scheduled by
67           separate algorithms (called "disciplines" in this context).
68
69           See the top of <file:net/sched/sch_cbq.c> for references about the
70           CBQ algorithm.
71
72           CBQ is a commonly used scheduler, so if you're unsure, you should
73           say Y here. Then say Y to all the queueing algorithms below that you
74           want to use as CBQ disciplines.  Then say Y to "Packet classifier
75           API" and say Y to all the classifiers you want to use; a classifier
76           is a routine that allows you to sort your outgoing traffic into
77           classes based on a certain criterion.
78
79           To compile this code as a module, choose M here: the
80           module will be called sch_cbq.
81
82 config NET_SCH_HTB
83         tristate "HTB packet scheduler"
84         depends on NET_SCHED
85         ---help---
86           Say Y here if you want to use the Hierarchical Token Buckets (HTB)
87           packet scheduling algorithm for some of your network devices. See
88           <http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
89           in-depth articles.
90
91           HTB is very similar to the CBQ regarding its goals however is has 
92           different properties and different algorithm.
93
94           To compile this code as a module, choose M here: the
95           module will be called sch_htb.
96
97 config NET_SCH_HFSC
98         tristate "HFSC packet scheduler"
99         depends on NET_SCHED
100         ---help---
101           Say Y here if you want to use the Hierarchical Fair Service Curve
102           (HFSC) packet scheduling algorithm for some of your network devices.
103
104           To compile this code as a module, choose M here: the
105           module will be called sch_hfsc.
106
107 #tristate '  H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ
108 config NET_SCH_ATM
109         tristate "ATM pseudo-scheduler"
110         depends on NET_SCHED && ATM
111         ---help---
112           Say Y here if you want to use the ATM pseudo-scheduler.  This
113           provides a framework for invoking classifiers (aka "filters"), which
114           in turn select classes of this queuing discipline.  Each class maps
115           the flow(s) it is handling to a given virtual circuit (see the top of
116           <file:net/sched/sch_atm.c>).
117
118           To compile this code as a module, choose M here: the
119           module will be called sch_atm.
120
121 config NET_SCH_PRIO
122         tristate "The simplest PRIO pseudoscheduler"
123         depends on NET_SCHED
124         help
125           Say Y here if you want to use an n-band priority queue packet
126           "scheduler" for some of your network devices or as a leaf discipline
127           for the CBQ scheduling algorithm. If unsure, say Y.
128
129           To compile this code as a module, choose M here: the
130           module will be called sch_prio.
131
132 config NET_SCH_RED
133         tristate "RED queue"
134         depends on NET_SCHED
135         help
136           Say Y here if you want to use the Random Early Detection (RED)
137           packet scheduling algorithm for some of your network devices (see
138           the top of <file:net/sched/sch_red.c> for details and references
139           about the algorithm).
140
141           To compile this code as a module, choose M here: the
142           module will be called sch_red.
143
144 config NET_SCH_SFQ
145         tristate "SFQ queue"
146         depends on NET_SCHED
147         ---help---
148           Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
149           packet scheduling algorithm for some of your network devices or as a
150           leaf discipline for the CBQ scheduling algorithm (see the top of
151           <file:net/sched/sch_sfq.c> for details and references about the SFQ
152           algorithm).
153
154           To compile this code as a module, choose M here: the
155           module will be called sch_sfq.
156
157 config NET_SCH_TEQL
158         tristate "TEQL queue"
159         depends on NET_SCHED
160         ---help---
161           Say Y here if you want to use the True Link Equalizer (TLE) packet
162           scheduling algorithm for some of your network devices or as a leaf
163           discipline for the CBQ scheduling algorithm. This queueing
164           discipline allows the combination of several physical devices into
165           one virtual device. (see the top of <file:net/sched/sch_teql.c> for
166           details).
167
168           To compile this code as a module, choose M here: the
169           module will be called sch_teql.
170
171 config NET_SCH_TBF
172         tristate "TBF queue"
173         depends on NET_SCHED
174         help
175           Say Y here if you want to use the Simple Token Bucket Filter (TBF)
176           packet scheduling algorithm for some of your network devices or as a
177           leaf discipline for the CBQ scheduling algorithm (see the top of
178           <file:net/sched/sch_tbf.c> for a description of the TBF algorithm).
179
180           To compile this code as a module, choose M here: the
181           module will be called sch_tbf.
182
183 config NET_SCH_GRED
184         tristate "GRED queue"
185         depends on NET_SCHED
186         help
187           Say Y here if you want to use the Generic Random Early Detection
188           (GRED) packet scheduling algorithm for some of your network devices
189           (see the top of <file:net/sched/sch_red.c> for details and
190           references about the algorithm).
191
192           To compile this code as a module, choose M here: the
193           module will be called sch_gred.
194
195 config NET_SCH_DSMARK
196         tristate "Diffserv field marker"
197         depends on NET_SCHED
198         help
199           Say Y if you want to schedule packets according to the
200           Differentiated Services architecture proposed in RFC 2475.
201           Technical information on this method, with pointers to associated
202           RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.
203
204           To compile this code as a module, choose M here: the
205           module will be called sch_dsmark.
206
207 config NET_SCH_NETEM
208         tristate "Network emulator"
209         depends on NET_SCHED
210         help
211           Say Y if you want to emulate network delay, loss, and packet
212           re-ordering. This is often useful to simulate networks when
213           testing applications or protocols.
214
215           To compile this driver as a module, choose M here: the module
216           will be called sch_netem.
217
218           If unsure, say N.
219
220 config NET_SCH_INGRESS
221         tristate "Ingress Qdisc"
222         depends on NET_SCHED 
223         help
224           If you say Y here, you will be able to police incoming bandwidth
225           and drop packets when this bandwidth exceeds your desired rate.
226           If unsure, say Y.
227
228           To compile this code as a module, choose M here: the
229           module will be called sch_ingress.
230
231 config NET_QOS
232         bool "QoS support"
233         depends on NET_SCHED
234         ---help---
235           Say Y here if you want to include Quality Of Service scheduling
236           features, which means that you will be able to request certain
237           rate-of-flow limits for your network devices.
238
239           This Quality of Service (QoS) support will enable you to use
240           Differentiated Services (diffserv) and Resource Reservation Protocol
241           (RSVP) on your Linux router if you also say Y to "Packet classifier
242           API" and to some classifiers below. Documentation and software is at
243           <http://diffserv.sourceforge.net/>.
244
245           Note that the answer to this question won't directly affect the
246           kernel: saying N will just cause the configurator to skip all
247           the questions about QoS support.
248
249 config NET_ESTIMATOR
250         bool "Rate estimator"
251         depends on NET_QOS
252         help
253           In order for Quality of Service scheduling to work, the current
254           rate-of-flow for a network device has to be estimated; if you say Y
255           here, the kernel will do just that.
256
257 config NET_CLS
258         bool "Packet classifier API"
259         depends on NET_SCHED
260         ---help---
261           The CBQ scheduling algorithm requires that network packets which are
262           scheduled to be sent out over a network device be classified
263           according to some criterion. If you say Y here, you will get a
264           choice of several different packet classifiers with the following
265           questions.
266
267           This will enable you to use Differentiated Services (diffserv) and
268           Resource Reservation Protocol (RSVP) on your Linux router.
269           Documentation and software is at
270           <http://diffserv.sourceforge.net/>.
271
272 config NET_CLS_BASIC
273         tristate "Basic classifier"
274         depends on NET_CLS
275         ---help---
276           Say Y here if you want to be able to classify packets using
277           only extended matches and actions.
278
279           To compile this code as a module, choose M here: the
280           module will be called cls_basic.
281
282 config NET_CLS_TCINDEX
283         tristate "TC index classifier"
284         depends on NET_CLS
285         help
286           If you say Y here, you will be able to classify outgoing packets
287           according to the tc_index field of the skb. You will want this
288           feature if you want to implement Differentiated Services using
289           sch_dsmark. If unsure, say Y.
290
291           To compile this code as a module, choose M here: the
292           module will be called cls_tcindex.
293
294 config NET_CLS_ROUTE4
295         tristate "Routing table based classifier"
296         depends on NET_CLS
297         select NET_CLS_ROUTE
298         help
299           If you say Y here, you will be able to classify outgoing packets
300           according to the route table entry they matched. If unsure, say Y.
301
302           To compile this code as a module, choose M here: the
303           module will be called cls_route.
304
305 config NET_CLS_ROUTE
306         bool
307         default n
308
309 config NET_CLS_FW
310         tristate "Firewall based classifier"
311         depends on NET_CLS
312         help
313           If you say Y here, you will be able to classify outgoing packets
314           according to firewall criteria you specified.
315
316           To compile this code as a module, choose M here: the
317           module will be called cls_fw.
318
319 config NET_CLS_U32
320         tristate "U32 classifier"
321         depends on NET_CLS
322         help
323           If you say Y here, you will be able to classify outgoing packets
324           according to their destination address. If unsure, say Y.
325
326           To compile this code as a module, choose M here: the
327           module will be called cls_u32.
328
329 config CLS_U32_PERF
330         bool "U32 classifier performance counters"
331         depends on NET_CLS_U32
332         help
333           gathers stats that could be used to tune u32 classifier performance.
334           Requires a new iproute2
335           You MUST NOT turn this on if you dont have an update iproute2.
336
337 config NET_CLS_IND
338         bool "classify input device (slows things u32/fw) "
339         depends on NET_CLS_U32 || NET_CLS_FW
340         help
341           This option will be killed eventually when a 
342           metadata action appears because it slows things a little
343           Available only for u32 and fw classifiers.
344           Requires a new iproute2
345           You MUST NOT turn this on if you dont have an update iproute2.
346
347 config CLS_U32_MARK
348         bool "Use nfmark as a key in U32 classifier"
349         depends on NET_CLS_U32 && NETFILTER
350         help
351           This allows you to match mark in a u32 filter.
352           Example:
353           tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \
354                 match mark 0x0090 0xffff \
355                 match ip dst 4.4.4.4 \
356                 flowid 1:90
357           You must use a new iproute2 to use this feature.
358
359 config NET_CLS_RSVP
360         tristate "Special RSVP classifier"
361         depends on NET_CLS && NET_QOS
362         ---help---
363           The Resource Reservation Protocol (RSVP) permits end systems to
364           request a minimum and maximum data flow rate for a connection; this
365           is important for real time data such as streaming sound or video.
366
367           Say Y here if you want to be able to classify outgoing packets based
368           on their RSVP requests.
369
370           To compile this code as a module, choose M here: the
371           module will be called cls_rsvp.
372
373 config NET_CLS_RSVP6
374         tristate "Special RSVP classifier for IPv6"
375         depends on NET_CLS && NET_QOS
376         ---help---
377           The Resource Reservation Protocol (RSVP) permits end systems to
378           request a minimum and maximum data flow rate for a connection; this
379           is important for real time data such as streaming sound or video.
380
381           Say Y here if you want to be able to classify outgoing packets based
382           on their RSVP requests and you are using the new Internet Protocol
383           IPv6 as opposed to the older and more common IPv4.
384
385           To compile this code as a module, choose M here: the
386           module will be called cls_rsvp6.
387
388 config NET_EMATCH
389         bool "Extended Matches"
390         depends on NET_CLS
391         ---help---
392           Say Y here if you want to use extended matches on top of classifiers
393           and select the extended matches below.
394
395           Extended matches are small classification helpers not worth writing
396           a separate classifier.
397
398           You must have a recent version of the iproute2 tools in order to use
399           extended matches.
400
401 config NET_EMATCH_STACK
402         int "Stack size"
403         depends on NET_EMATCH
404         default "32"
405         ---help---
406           Size of the local stack variable used while evaluating the tree of
407           ematches. Limits the depth of the tree, i.e. the number of
408           encapsulated precedences. Every level requires 4 bytes of addtional
409           stack space.
410
411 config NET_EMATCH_CMP
412         tristate "Simple packet data comparison"
413         depends on NET_EMATCH
414         ---help---
415           Say Y here if you want to be able to classify packets based on
416           simple packet data comparisons for 8, 16, and 32bit values.
417
418           To compile this code as a module, choose M here: the
419           module will be called em_cmp.
420
421 config NET_EMATCH_NBYTE
422         tristate "Multi byte comparison"
423         depends on NET_EMATCH
424         ---help---
425           Say Y here if you want to be able to classify packets based on
426           multiple byte comparisons mainly useful for IPv6 address comparisons.
427
428           To compile this code as a module, choose M here: the
429           module will be called em_nbyte.
430
431 config NET_EMATCH_U32
432         tristate "U32 hashing key"
433         depends on NET_EMATCH
434         ---help---
435           Say Y here if you want to be able to classify packets using
436           the famous u32 key in combination with logic relations.
437
438           To compile this code as a module, choose M here: the
439           module will be called em_u32.
440
441 config NET_EMATCH_META
442         tristate "Metadata"
443         depends on NET_EMATCH
444         ---help---
445           Say Y here if you want to be ablt to classify packets based on
446           metadata such as load average, netfilter attributes, socket
447           attributes and routing decisions.
448
449           To compile this code as a module, choose M here: the
450           module will be called em_meta.
451
452 config NET_CLS_ACT
453         bool "Packet ACTION"
454         depends on EXPERIMENTAL && NET_CLS && NET_QOS
455         ---help---
456         This option requires you have a new iproute2. It enables
457         tc extensions which can be used with tc classifiers.
458           You MUST NOT turn this on if you dont have an update iproute2.
459
460 config NET_ACT_POLICE
461         tristate "Policing Actions"
462         depends on NET_CLS_ACT 
463         ---help---
464         If you are using a newer iproute2 select this one, otherwise use one
465         below to select a policer.
466           You MUST NOT turn this on if you dont have an update iproute2.
467
468 config NET_ACT_GACT
469         tristate "generic Actions"
470         depends on NET_CLS_ACT
471         ---help---
472         You must have new iproute2 to use this feature.
473         This adds simple filtering actions like drop, accept etc.
474
475 config GACT_PROB
476         bool "generic Actions probability"
477         depends on NET_ACT_GACT
478         ---help---
479         Allows generic actions to be randomly or deterministically used.
480
481 config NET_ACT_MIRRED
482         tristate "Packet In/Egress redirecton/mirror Actions"
483         depends on NET_CLS_ACT
484         ---help---
485         requires new iproute2
486         This allows packets to be mirrored or redirected to netdevices
487
488 config NET_ACT_IPT
489         tristate "iptables Actions"
490         depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
491         ---help---
492         requires new iproute2
493         This allows iptables targets to be used by tc filters
494
495 config NET_ACT_PEDIT
496         tristate "Generic Packet Editor Actions"
497         depends on NET_CLS_ACT
498         ---help---
499         requires new iproute2
500         This allows for packets to be generically edited
501
502 config NET_CLS_POLICE
503         bool "Traffic policing (needed for in/egress)"
504         depends on NET_CLS && NET_QOS && NET_CLS_ACT!=y
505         help
506           Say Y to support traffic policing (bandwidth limits).  Needed for
507           ingress and egress rate limiting.
508
509 config NET_ACT_SIMP
510         tristate "Simple action"
511         depends on NET_CLS_ACT
512         ---help---
513         You must have new iproute2 to use this feature.
514         This adds a very simple action for demonstration purposes
515         The idea is to give action authors a basic example to look at.
516         All this action will do is print on the console the configured
517         policy string followed by _ then packet count.
518