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