#
# Traffic control configuration.
#
-choice
- prompt "Packet scheduler clock source"
- depends on NET_SCHED
- default NET_SCH_CLK_JIFFIES
- help
- Packet schedulers need a monotonic clock that increments at a static
- rate. The kernel provides several suitable interfaces, each with
- different properties:
-
- - high resolution (us or better)
- - fast to read (minimal locking, no i/o access)
- - synchronized on all processors
- - handles cpu clock frequency changes
-
- but nothing provides all of the above.
-
-config NET_SCH_CLK_JIFFIES
- bool "Timer interrupt"
- help
- Say Y here if you want to use the timer interrupt (jiffies) as clock
- source. This clock source is fast, synchronized on all processors and
- handles cpu clock frequency changes, but its resolution is too low
- for accurate shaping except at very low speed.
-
-config NET_SCH_CLK_GETTIMEOFDAY
- bool "gettimeofday"
- help
- Say Y here if you want to use gettimeofday as clock source. This clock
- source has high resolution, is synchronized on all processors and
- handles cpu clock frequency changes, but it is slow.
- Choose this if you need a high resolution clock source but can't use
- the CPU's cycle counter.
+menuconfig NET_SCHED
+ bool "QoS and/or fair queueing"
+ select NET_SCH_FIFO
+ ---help---
+ When the kernel has several packets to send out over a network
+ device, it has to decide which ones to send first, which ones to
+ delay, and which ones to drop. This is the job of the queueing
+ disciplines, several different algorithms for how to do this
+ "fairly" have been proposed.
+
+ If you say N here, you will get the standard packet scheduler, which
+ is a FIFO (first come, first served). If you say Y here, you will be
+ able to choose from among several alternative algorithms which can
+ then be attached to different network devices. This is useful for
+ example if some of your network devices are real time devices that
+ need a certain minimum data flow rate, or if you need to limit the
+ maximum data flow rate for traffic which matches specified criteria.
+ This code is considered to be experimental.
+
+ To administer these schedulers, you'll need the user-level utilities
+ from the package iproute2+tc at <ftp://ftp.tux.org/pub/net/ip-routing/>.
+ That package also contains some documentation; for more, check out
+ <http://linux-net.osdl.org/index.php/Iproute2>.
-config NET_SCH_CLK_CPU
- bool "CPU cycle counter"
- depends on X86_TSC || X86_64 || ALPHA || SPARC64 || PPC64 || IA64
- help
- Say Y here if you want to use the CPU's cycle counter as clock source.
- This is a cheap and high resolution clock source, but on some
- architectures it is not synchronized on all processors and doesn't
- handle cpu clock frequency changes.
+ This Quality of Service (QoS) support will enable you to use
+ Differentiated Services (diffserv) and Resource Reservation Protocol
+ (RSVP) on your Linux router if you also say Y to the corresponding
+ classifiers below. Documentation and software is at
+ <http://diffserv.sourceforge.net/>.
- The useable cycle counters are:
+ If you say Y here and to "/proc file system" below, you will be able
+ to read status information about packet schedulers from the file
+ /proc/net/psched.
- x86/x86_64 - Timestamp Counter
- alpha - Cycle Counter
- sparc64 - %ticks register
- ppc64 - Time base
- ia64 - Interval Time Counter
+ The available schedulers are listed in the following questions; you
+ can say Y to as many as you like. If unsure, say N now.
- Choose this if your CPU's cycle counter is working properly.
+if NET_SCHED
-endchoice
+comment "Queueing/Scheduling"
config NET_SCH_CBQ
- tristate "CBQ packet scheduler"
- depends on NET_SCHED
+ tristate "Class Based Queueing (CBQ)"
---help---
Say Y here if you want to use the Class-Based Queueing (CBQ) packet
- scheduling algorithm for some of your network devices. This
- algorithm classifies the waiting packets into a tree-like hierarchy
- of classes; the leaves of this tree are in turn scheduled by
- separate algorithms (called "disciplines" in this context).
+ scheduling algorithm. This algorithm classifies the waiting packets
+ into a tree-like hierarchy of classes; the leaves of this tree are
+ in turn scheduled by separate algorithms.
- See the top of <file:net/sched/sch_cbq.c> for references about the
- CBQ algorithm.
+ See the top of <file:net/sched/sch_cbq.c> for more details.
CBQ is a commonly used scheduler, so if you're unsure, you should
say Y here. Then say Y to all the queueing algorithms below that you
- want to use as CBQ disciplines. Then say Y to "Packet classifier
- API" and say Y to all the classifiers you want to use; a classifier
- is a routine that allows you to sort your outgoing traffic into
- classes based on a certain criterion.
+ want to use as leaf disciplines.
To compile this code as a module, choose M here: the
module will be called sch_cbq.
config NET_SCH_HTB
- tristate "HTB packet scheduler"
- depends on NET_SCHED
+ tristate "Hierarchical Token Bucket (HTB)"
---help---
Say Y here if you want to use the Hierarchical Token Buckets (HTB)
- packet scheduling algorithm for some of your network devices. See
+ packet scheduling algorithm. See
<http://luxik.cdi.cz/~devik/qos/htb/> for complete manual and
in-depth articles.
- HTB is very similar to the CBQ regarding its goals however is has
+ HTB is very similar to CBQ regarding its goals however is has
different properties and different algorithm.
To compile this code as a module, choose M here: the
module will be called sch_htb.
config NET_SCH_HFSC
- tristate "HFSC packet scheduler"
- depends on NET_SCHED
+ tristate "Hierarchical Fair Service Curve (HFSC)"
---help---
Say Y here if you want to use the Hierarchical Fair Service Curve
- (HFSC) packet scheduling algorithm for some of your network devices.
+ (HFSC) packet scheduling algorithm.
To compile this code as a module, choose M here: the
module will be called sch_hfsc.
-#tristate ' H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ
config NET_SCH_ATM
- tristate "ATM pseudo-scheduler"
- depends on NET_SCHED && ATM
+ tristate "ATM Virtual Circuits (ATM)"
+ depends on ATM
---help---
Say Y here if you want to use the ATM pseudo-scheduler. This
- provides a framework for invoking classifiers (aka "filters"), which
- in turn select classes of this queuing discipline. Each class maps
- the flow(s) it is handling to a given virtual circuit (see the top of
- <file:net/sched/sch_atm.c>).
+ provides a framework for invoking classifiers, which in turn
+ select classes of this queuing discipline. Each class maps
+ the flow(s) it is handling to a given virtual circuit.
+
+ See the top of <file:net/sched/sch_atm.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_atm.
config NET_SCH_PRIO
- tristate "The simplest PRIO pseudoscheduler"
- depends on NET_SCHED
- help
+ tristate "Multi Band Priority Queueing (PRIO)"
+ ---help---
Say Y here if you want to use an n-band priority queue packet
- "scheduler" for some of your network devices or as a leaf discipline
- for the CBQ scheduling algorithm. If unsure, say Y.
+ scheduler.
To compile this code as a module, choose M here: the
module will be called sch_prio.
+config NET_SCH_MULTIQ
+ tristate "Hardware Multiqueue-aware Multi Band Queuing (MULTIQ)"
+ ---help---
+ Say Y here if you want to use an n-band queue packet scheduler
+ to support devices that have multiple hardware transmit queues.
+
+ To compile this code as a module, choose M here: the
+ module will be called sch_multiq.
+
config NET_SCH_RED
- tristate "RED queue"
- depends on NET_SCHED
- help
+ tristate "Random Early Detection (RED)"
+ ---help---
Say Y here if you want to use the Random Early Detection (RED)
- packet scheduling algorithm for some of your network devices (see
- the top of <file:net/sched/sch_red.c> for details and references
- about the algorithm).
+ packet scheduling algorithm.
+
+ See the top of <file:net/sched/sch_red.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_red.
config NET_SCH_SFQ
- tristate "SFQ queue"
- depends on NET_SCHED
+ tristate "Stochastic Fairness Queueing (SFQ)"
---help---
Say Y here if you want to use the Stochastic Fairness Queueing (SFQ)
- packet scheduling algorithm for some of your network devices or as a
- leaf discipline for the CBQ scheduling algorithm (see the top of
- <file:net/sched/sch_sfq.c> for details and references about the SFQ
- algorithm).
+ packet scheduling algorithm.
+
+ See the top of <file:net/sched/sch_sfq.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_sfq.
config NET_SCH_TEQL
- tristate "TEQL queue"
- depends on NET_SCHED
+ tristate "True Link Equalizer (TEQL)"
---help---
Say Y here if you want to use the True Link Equalizer (TLE) packet
- scheduling algorithm for some of your network devices or as a leaf
- discipline for the CBQ scheduling algorithm. This queueing
- discipline allows the combination of several physical devices into
- one virtual device. (see the top of <file:net/sched/sch_teql.c> for
- details).
+ scheduling algorithm. This queueing discipline allows the combination
+ of several physical devices into one virtual device.
+
+ See the top of <file:net/sched/sch_teql.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_teql.
config NET_SCH_TBF
- tristate "TBF queue"
- depends on NET_SCHED
- help
- Say Y here if you want to use the Simple Token Bucket Filter (TBF)
- packet scheduling algorithm for some of your network devices or as a
- leaf discipline for the CBQ scheduling algorithm (see the top of
- <file:net/sched/sch_tbf.c> for a description of the TBF algorithm).
+ tristate "Token Bucket Filter (TBF)"
+ ---help---
+ Say Y here if you want to use the Token Bucket Filter (TBF) packet
+ scheduling algorithm.
+
+ See the top of <file:net/sched/sch_tbf.c> for more details.
To compile this code as a module, choose M here: the
module will be called sch_tbf.
config NET_SCH_GRED
- tristate "GRED queue"
- depends on NET_SCHED
- help
+ tristate "Generic Random Early Detection (GRED)"
+ ---help---
Say Y here if you want to use the Generic Random Early Detection
(GRED) packet scheduling algorithm for some of your network devices
(see the top of <file:net/sched/sch_red.c> for details and
module will be called sch_gred.
config NET_SCH_DSMARK
- tristate "Diffserv field marker"
- depends on NET_SCHED
- help
+ tristate "Differentiated Services marker (DSMARK)"
+ ---help---
Say Y if you want to schedule packets according to the
Differentiated Services architecture proposed in RFC 2475.
Technical information on this method, with pointers to associated
module will be called sch_dsmark.
config NET_SCH_NETEM
- tristate "Network emulator"
- depends on NET_SCHED
- help
+ tristate "Network emulator (NETEM)"
+ ---help---
Say Y if you want to emulate network delay, loss, and packet
re-ordering. This is often useful to simulate networks when
testing applications or protocols.
If unsure, say N.
+config NET_SCH_DRR
+ tristate "Deficit Round Robin scheduler (DRR)"
+ help
+ Say Y here if you want to use the Deficit Round Robin (DRR) packet
+ scheduling algorithm.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sch_drr.
+
+ If unsure, say N.
+
config NET_SCH_INGRESS
tristate "Ingress Qdisc"
- depends on NET_SCHED
- help
- If you say Y here, you will be able to police incoming bandwidth
- and drop packets when this bandwidth exceeds your desired rate.
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here if you want to use classifiers for incoming packets.
If unsure, say Y.
To compile this code as a module, choose M here: the
module will be called sch_ingress.
-config NET_QOS
- bool "QoS support"
- depends on NET_SCHED
- ---help---
- Say Y here if you want to include Quality Of Service scheduling
- features, which means that you will be able to request certain
- rate-of-flow limits for your network devices.
-
- This Quality of Service (QoS) support will enable you to use
- Differentiated Services (diffserv) and Resource Reservation Protocol
- (RSVP) on your Linux router if you also say Y to "Packet classifier
- API" and to some classifiers below. Documentation and software is at
- <http://diffserv.sourceforge.net/>.
-
- Note that the answer to this question won't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about QoS support.
-
-config NET_ESTIMATOR
- bool "Rate estimator"
- depends on NET_QOS
- help
- In order for Quality of Service scheduling to work, the current
- rate-of-flow for a network device has to be estimated; if you say Y
- here, the kernel will do just that.
+comment "Classification"
config NET_CLS
- bool "Packet classifier API"
- depends on NET_SCHED
- ---help---
- The CBQ scheduling algorithm requires that network packets which are
- scheduled to be sent out over a network device be classified
- according to some criterion. If you say Y here, you will get a
- choice of several different packet classifiers with the following
- questions.
-
- This will enable you to use Differentiated Services (diffserv) and
- Resource Reservation Protocol (RSVP) on your Linux router.
- Documentation and software is at
- <http://diffserv.sourceforge.net/>.
+ boolean
config NET_CLS_BASIC
- tristate "Basic classifier"
- depends on NET_CLS
+ tristate "Elementary classification (BASIC)"
+ select NET_CLS
---help---
Say Y here if you want to be able to classify packets using
only extended matches and actions.
module will be called cls_basic.
config NET_CLS_TCINDEX
- tristate "TC index classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to the tc_index field of the skb. You will want this
- feature if you want to implement Differentiated Services using
- sch_dsmark. If unsure, say Y.
+ tristate "Traffic-Control Index (TCINDEX)"
+ select NET_CLS
+ ---help---
+ Say Y here if you want to be able to classify packets based on
+ traffic control indices. You will want this feature if you want
+ to implement Differentiated Services together with DSMARK.
To compile this code as a module, choose M here: the
module will be called cls_tcindex.
config NET_CLS_ROUTE4
- tristate "Routing table based classifier"
- depends on NET_CLS
+ tristate "Routing decision (ROUTE)"
select NET_CLS_ROUTE
- help
- If you say Y here, you will be able to classify outgoing packets
- according to the route table entry they matched. If unsure, say Y.
+ select NET_CLS
+ ---help---
+ If you say Y here, you will be able to classify packets
+ according to the route table entry they matched.
To compile this code as a module, choose M here: the
module will be called cls_route.
config NET_CLS_ROUTE
bool
- default n
config NET_CLS_FW
- tristate "Firewall based classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to firewall criteria you specified.
+ tristate "Netfilter mark (FW)"
+ select NET_CLS
+ ---help---
+ If you say Y here, you will be able to classify packets
+ according to netfilter/firewall marks.
To compile this code as a module, choose M here: the
module will be called cls_fw.
config NET_CLS_U32
- tristate "U32 classifier"
- depends on NET_CLS
- help
- If you say Y here, you will be able to classify outgoing packets
- according to their destination address. If unsure, say Y.
+ tristate "Universal 32bit comparisons w/ hashing (U32)"
+ select NET_CLS
+ ---help---
+ Say Y here to be able to classify packets using a universal
+ 32bit pieces based comparison scheme.
To compile this code as a module, choose M here: the
module will be called cls_u32.
config CLS_U32_PERF
- bool "U32 classifier performance counters"
+ bool "Performance counters support"
depends on NET_CLS_U32
- help
- gathers stats that could be used to tune u32 classifier performance.
- Requires a new iproute2
- You MUST NOT turn this on if you dont have an update iproute2.
-
-config NET_CLS_IND
- bool "classify input device (slows things u32/fw) "
- depends on NET_CLS_U32 || NET_CLS_FW
- help
- This option will be killed eventually when a
- metadata action appears because it slows things a little
- Available only for u32 and fw classifiers.
- Requires a new iproute2
- You MUST NOT turn this on if you dont have an update iproute2.
+ ---help---
+ Say Y here to make u32 gather additional statistics useful for
+ fine tuning u32 classifiers.
config CLS_U32_MARK
- bool "Use nfmark as a key in U32 classifier"
- depends on NET_CLS_U32 && NETFILTER
- help
- This allows you to match mark in a u32 filter.
- Example:
- tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \
- match mark 0x0090 0xffff \
- match ip dst 4.4.4.4 \
- flowid 1:90
- You must use a new iproute2 to use this feature.
+ bool "Netfilter marks support"
+ depends on NET_CLS_U32
+ ---help---
+ Say Y here to be able to use netfilter marks as u32 key.
config NET_CLS_RSVP
- tristate "Special RSVP classifier"
- depends on NET_CLS && NET_QOS
+ tristate "IPv4 Resource Reservation Protocol (RSVP)"
+ select NET_CLS
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
request a minimum and maximum data flow rate for a connection; this
module will be called cls_rsvp.
config NET_CLS_RSVP6
- tristate "Special RSVP classifier for IPv6"
- depends on NET_CLS && NET_QOS
+ tristate "IPv6 Resource Reservation Protocol (RSVP6)"
+ select NET_CLS
---help---
The Resource Reservation Protocol (RSVP) permits end systems to
request a minimum and maximum data flow rate for a connection; this
is important for real time data such as streaming sound or video.
Say Y here if you want to be able to classify outgoing packets based
- on their RSVP requests and you are using the new Internet Protocol
- IPv6 as opposed to the older and more common IPv4.
+ on their RSVP requests and you are using the IPv6 protocol.
To compile this code as a module, choose M here: the
module will be called cls_rsvp6.
+config NET_CLS_FLOW
+ tristate "Flow classifier"
+ select NET_CLS
+ ---help---
+ If you say Y here, you will be able to classify packets based on
+ a configurable combination of packet keys. This is mostly useful
+ in combination with SFQ.
+
+ To compile this code as a module, choose M here: the
+ module will be called cls_flow.
+
+config NET_CLS_CGROUP
+ tristate "Control Group Classifier"
+ select NET_CLS
+ depends on CGROUPS
+ ---help---
+ Say Y here if you want to classify packets based on the control
+ cgroup of their process.
+
+ To compile this code as a module, choose M here: the
+ module will be called cls_cgroup.
+
config NET_EMATCH
bool "Extended Matches"
- depends on NET_CLS
+ select NET_CLS
---help---
Say Y here if you want to use extended matches on top of classifiers
and select the extended matches below.
Extended matches are small classification helpers not worth writing
- a separate classifier.
+ a separate classifier for.
- You must have a recent version of the iproute2 tools in order to use
+ A recent version of the iproute2 package is required to use
extended matches.
config NET_EMATCH_STACK
module will be called em_nbyte.
config NET_EMATCH_U32
- tristate "U32 hashing key"
+ tristate "U32 key"
depends on NET_EMATCH
---help---
Say Y here if you want to be able to classify packets using
tristate "Metadata"
depends on NET_EMATCH
---help---
- Say Y here if you want to be ablt to classify packets based on
+ Say Y here if you want to be able to classify packets based on
metadata such as load average, netfilter attributes, socket
attributes and routing decisions.
depends on NET_EMATCH
select TEXTSEARCH
select TEXTSEARCH_KMP
+ select TEXTSEARCH_BM
select TEXTSEARCH_FSM
---help---
- Say Y here if you want to be ablt to classify packets based on
+ Say Y here if you want to be able to classify packets based on
textsearch comparisons.
To compile this code as a module, choose M here: the
module will be called em_text.
config NET_CLS_ACT
- bool "Packet ACTION"
- depends on EXPERIMENTAL && NET_CLS && NET_QOS
+ bool "Actions"
---help---
- This option requires you have a new iproute2. It enables
- tc extensions which can be used with tc classifiers.
- You MUST NOT turn this on if you dont have an update iproute2.
+ Say Y here if you want to use traffic control actions. Actions
+ get attached to classifiers and are invoked after a successful
+ classification. They are used to overwrite the classification
+ result, instantly drop or redirect packets, etc.
+
+ A recent version of the iproute2 package is required to use
+ extended matches.
config NET_ACT_POLICE
- tristate "Policing Actions"
+ tristate "Traffic Policing"
depends on NET_CLS_ACT
---help---
- If you are using a newer iproute2 select this one, otherwise use one
- below to select a policer.
- You MUST NOT turn this on if you dont have an update iproute2.
+ Say Y here if you want to do traffic policing, i.e. strict
+ bandwidth limiting. This action replaces the existing policing
+ module.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_police.
config NET_ACT_GACT
- tristate "generic Actions"
+ tristate "Generic actions"
depends on NET_CLS_ACT
---help---
- You must have new iproute2 to use this feature.
- This adds simple filtering actions like drop, accept etc.
+ Say Y here to take generic actions such as dropping and
+ accepting packets.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_gact.
config GACT_PROB
- bool "generic Actions probability"
+ bool "Probability support"
depends on NET_ACT_GACT
---help---
- Allows generic actions to be randomly or deterministically used.
+ Say Y here to use the generic action randomly or deterministically.
config NET_ACT_MIRRED
- tristate "Packet In/Egress redirecton/mirror Actions"
+ tristate "Redirecting and Mirroring"
depends on NET_CLS_ACT
---help---
- requires new iproute2
- This allows packets to be mirrored or redirected to netdevices
+ Say Y here to allow packets to be mirrored or redirected to
+ other devices.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_mirred.
config NET_ACT_IPT
- tristate "iptables Actions"
+ tristate "IPtables targets"
depends on NET_CLS_ACT && NETFILTER && IP_NF_IPTABLES
---help---
- requires new iproute2
- This allows iptables targets to be used by tc filters
+ Say Y here to be able to invoke iptables targets after successful
+ classification.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_ipt.
+
+config NET_ACT_NAT
+ tristate "Stateless NAT"
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here to do stateless NAT on IPv4 packets. You should use
+ netfilter for NAT unless you know what you are doing.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_nat.
config NET_ACT_PEDIT
- tristate "Generic Packet Editor Actions"
+ tristate "Packet Editing"
depends on NET_CLS_ACT
---help---
- requires new iproute2
- This allows for packets to be generically edited
+ Say Y here if you want to mangle the content of packets.
-config NET_CLS_POLICE
- bool "Traffic policing (needed for in/egress)"
- depends on NET_CLS && NET_QOS && NET_CLS_ACT!=y
- help
- Say Y to support traffic policing (bandwidth limits). Needed for
- ingress and egress rate limiting.
+ To compile this code as a module, choose M here: the
+ module will be called act_pedit.
config NET_ACT_SIMP
- tristate "Simple action"
+ tristate "Simple Example (Debug)"
depends on NET_CLS_ACT
---help---
- You must have new iproute2 to use this feature.
- This adds a very simple action for demonstration purposes
- The idea is to give action authors a basic example to look at.
- All this action will do is print on the console the configured
- policy string followed by _ then packet count.
+ Say Y here to add a simple action for demonstration purposes.
+ It is meant as an example and for debugging purposes. It will
+ print a configured policy string followed by the packet count
+ to the console for every packet that passes by.
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_simple.
+config NET_ACT_SKBEDIT
+ tristate "SKB Editing"
+ depends on NET_CLS_ACT
+ ---help---
+ Say Y here to change skb priority or queue_mapping settings.
+
+ If unsure, say N.
+
+ To compile this code as a module, choose M here: the
+ module will be called act_skbedit.
+
+config NET_CLS_IND
+ bool "Incoming device classification"
+ depends on NET_CLS_U32 || NET_CLS_FW
+ ---help---
+ Say Y here to extend the u32 and fw classifier to support
+ classification based on the incoming device. This option is
+ likely to disappear in favour of the metadata ematch.
+
+endif # NET_SCHED
+
+config NET_SCH_FIFO
+ bool
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff