Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 |
Lucas Correia Villa Real | 20cc6be | 2005-05-03 14:34:20 -0700 | [diff] [blame^] | 188 | (GRED) packet scheduling algorithm for some of your network devices |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
Jamal Hadi Salim | db75307 | 2005-04-24 20:10:16 -0700 | [diff] [blame] | 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 | |