]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 | |
20cc6bef | 188 | (GRED) packet scheduling algorithm for some of your network devices |
1da177e4 LT |
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 | ||
db753079 JHS |
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 |