#
# Traffic control configuration.
# 
config NET_SCH_CBQ
	tristate "CBQ packet scheduler"
	depends on NET_SCHED
	---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).

	  See the top of <file:net/sched/sch_cbq.c> for references about the
	  CBQ algorithm.

	  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.

	  This code is also available as a module called sch_cbq ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_HTB
	tristate "HTB packet scheduler"
	depends on NET_SCHED
	---help---
	  Say Y here if you want to use the Hierarchical Token Buckets (HTB)
	  packet scheduling algorithm for some of your network devices. See
	  URL 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 
	  different properties and different algorithm.

	  This code is also available as a module called sch_htb ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_CSZ
	tristate "CSZ packet scheduler"
	depends on NET_SCHED
	---help---
	  Say Y here if you want to use the Clark-Shenker-Zhang (CSZ) packet
	  scheduling algorithm for some of your network devices.  At the
	  moment, this is the only algorithm that can guarantee service for
	  real-time applications (see the top of <file:net/sched/sch_csz.c>
	  for details and references about the algorithm).

	  Note: this scheduler is currently broken.

	  This code is also available as a module called sch_csz ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

#tristate '  H-PFQ packet scheduler' CONFIG_NET_SCH_HPFQ
#tristate '  H-FSC packet scheduler' CONFIG_NET_SCH_HFCS
config NET_SCH_ATM
	tristate "ATM pseudo-scheduler"
	depends on NET_SCHED && 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>).

	  This code is also available as a module called sch_atm ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_PRIO
	tristate "The simplest PRIO pseudoscheduler"
	depends on NET_SCHED
	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.

	  This code is also available as a module called sch_prio ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_RED
	tristate "RED queue"
	depends on NET_SCHED
	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).

	  This code is also available as a module called sch_red ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_SFQ
	tristate "SFQ queue"
	depends on NET_SCHED
	---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).

	  This code is also available as a module called sch_sfq ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_TEQL
	tristate "TEQL queue"
	depends on NET_SCHED
	---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).

	  This code is also available as a module called sch_teql ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

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).

	  This code is also available as a module called sch_tbf ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_GRED
	tristate "GRED queue"
	depends on NET_SCHED
	help
	  Say Y here if you want to use the Generic 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).

	  This code is also available as a module called sch_gred ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want). If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_DSMARK
	tristate "Diffserv field marker"
	depends on NET_SCHED
	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
	  RFCs, is available at <http://www.gta.ufrj.br/diffserv/>.

	  This code is also available as a module called sch_dsmark ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_SCH_INGRESS
	tristate "Ingress Qdisc"
	depends on NET_SCHED && NETFILTER
	help
	  If you say Y here, you will be able to police incoming bandwidth
	  and drop packets when this bandwidth exceeds your desired rate.
	  If unsure, say Y.

	  This code is also available as a module called cls_ingress
	  ( = code which can be inserted in and removed from the running
	  kernel whenever you want).  If you want to compile it as a module,
	  say M here and read <file:Documentation/modules.txt>.

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.

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/>.

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.

	  This code is also available as a module called cls_tcindex
	  ( = code which can be inserted in and removed from the running
	  kernel whenever you want). If you want to compile it as a module,
	  say M here and read <file:Documentation/modules.txt>.

config NET_CLS_ROUTE4
	tristate "Routing table based classifier"
	depends on NET_CLS
	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.

	  This code is also available as a module called cls_route ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_CLS_ROUTE
	bool
	depends on NET_CLS_ROUTE4
	default y

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.

	  This code is also available as a module called cls_fw ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

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.

	  This code is also available as a module called cls_u32 ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_CLS_RSVP
	tristate "Special RSVP classifier"
	depends on NET_CLS && NET_QOS
	---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.

	  This code is also available as a module called cls_rsvp ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_CLS_RSVP6
	tristate "Special RSVP classifier for IPv6"
	depends on NET_CLS && NET_QOS
	---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.

	  This code is also available as a module called cls_rsvp6 ( = code
	  which can be inserted in and removed from the running kernel
	  whenever you want).  If you want to compile it as a module, say M
	  here and read <file:Documentation/modules.txt>.

config NET_CLS_POLICE
	bool "Traffic policing (needed for in/egress)"
	depends on NET_CLS && NET_QOS
	help
	  Say Y to support traffic policing (bandwidth limits).  Needed for
	  ingress and egress rate limiting.

