Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
[linux-2.6.git] / net / ipv4 / Kconfig
index 712ebac..aa2a2c7 100644 (file)
@@ -1,49 +1,21 @@
 #
 # IP configuration
 #
-choice 
-       prompt "Choose IP: FIB lookup"
-       depends on INET
-       default IP_FIB_HASH
-
-config IP_FIB_HASH
-       bool "FIB_HASH"
-       ---help---
-       Current FIB is very proven and good enough for most users.
-
-config IP_FIB_TRIE
-       bool "FIB_TRIE"
-       ---help---
-       Use new experimental LC-trie as FIB lookup algoritm. 
-        This improves lookup performance
-       
-       LC-trie is described in:
-       
-       IP-address lookup using LC-tries. Stefan Nilsson and Gunnar Karlsson
-       IEEE Journal on Selected Areas in Communications, 17(6):1083-1092, June 1999
-       An experimental study of compression methods for dynamic tries
-       Stefan Nilsson and Matti Tikkanen. Algorithmica, 33(1):19-33, 2002.
-       http://www.nada.kth.se/~snilsson/public/papers/dyntrie2/
-       
-endchoice
-
 config IP_MULTICAST
        bool "IP: multicasting"
-       depends on INET
        help
          This is code for addressing several networked computers at once,
          enlarging your kernel by about 2 KB. You need multicasting if you
          intend to participate in the MBONE, a high bandwidth network on top
          of the Internet which carries audio and video broadcasts. More
          information about the MBONE is on the WWW at
-         <http://www-itg.lbl.gov/mbone/>. Information about the multicast
+         <http://www.savetz.com/mbone/>. Information about the multicast
          capabilities of the various network cards is contained in
          <file:Documentation/networking/multicast.txt>. For most people, it's
          safe to say N.
 
 config IP_ADVANCED_ROUTER
        bool "IP: advanced router"
-       depends on INET
        ---help---
          If you intend to run your Linux box mostly as a router, i.e. as a
          computer that forwards and redistributes network packets, say Y; you
@@ -63,7 +35,7 @@ config IP_ADVANCED_ROUTER
 
          at boot time after the /proc file system has been mounted.
 
-         If you turn on IP forwarding, you will also get the rp_filter, which
+         If you turn on IP forwarding, you should consider the rp_filter, which
          automatically rejects incoming packets if the routing table entry
          for their source address doesn't match the network interface they're
          arriving on. This has security advantages because it prevents the
@@ -71,17 +43,29 @@ config IP_ADVANCED_ROUTER
          asymmetric routing (packets from you to a host take a different path
          than packets from that host to you) or if you operate a non-routing
          host which has several IP addresses on different interfaces. To turn
-         rp_filter off use:
+         rp_filter on use:
+
+         echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter
+          or
+         echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
 
-         echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter
-         or
-         echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
+         Note that some distributions enable it in startup scripts.
+         For details about rp_filter strict and loose mode read
+         <file:Documentation/networking/ip-sysctl.txt>.
 
          If unsure, say N here.
 
+config IP_FIB_TRIE_STATS
+       bool "FIB TRIE statistics"
+       depends on IP_ADVANCED_ROUTER
+       ---help---
+         Keep track of statistics on structure of FIB TRIE table.
+         Useful for testing and measuring TRIE performance.
+
 config IP_MULTIPLE_TABLES
        bool "IP: policy routing"
        depends on IP_ADVANCED_ROUTER
+       select FIB_RULES
        ---help---
          Normally, a router decides what to do with a received packet based
          solely on the packet's final destination address. If you say Y here,
@@ -97,13 +81,6 @@ config IP_MULTIPLE_TABLES
 
          If unsure, say N.
 
-config IP_ROUTE_FWMARK
-       bool "IP: use netfilter MARK value as routing key"
-       depends on IP_MULTIPLE_TABLES && NETFILTER
-       help
-         If you say Y here, you will be able to specify different routes for
-         packets with different mark values (see iptables(8), MARK target).
-
 config IP_ROUTE_MULTIPATH
        bool "IP: equal cost multipath"
        depends on IP_ADVANCED_ROUTER
@@ -116,48 +93,6 @@ config IP_ROUTE_MULTIPATH
          equal "cost" and chooses one of them in a non-deterministic fashion
          if a matching packet arrives.
 
-config IP_ROUTE_MULTIPATH_CACHED
-       bool "IP: equal cost multipath with caching support (EXPERIMENTAL)"
-       depends on: IP_ROUTE_MULTIPATH
-       help
-         Normally, equal cost multipath routing is not supported by the
-         routing cache. If you say Y here, alternative routes are cached
-         and on cache lookup a route is chosen in a configurable fashion.
-
-         If unsure, say N.
-
-config IP_ROUTE_MULTIPATH_RR
-       tristate "MULTIPATH: round robin algorithm"
-       depends on IP_ROUTE_MULTIPATH_CACHED
-       help
-         Mulitpath routes are chosen according to Round Robin
-
-config IP_ROUTE_MULTIPATH_RANDOM
-       tristate "MULTIPATH: random algorithm"
-       depends on IP_ROUTE_MULTIPATH_CACHED
-       help
-         Multipath routes are chosen in a random fashion. Actually,
-         there is no weight for a route. The advantage of this policy
-         is that it is implemented stateless and therefore introduces only
-         a very small delay.
-
-config IP_ROUTE_MULTIPATH_WRANDOM
-       tristate "MULTIPATH: weighted random algorithm"
-       depends on IP_ROUTE_MULTIPATH_CACHED
-       help
-         Multipath routes are chosen in a weighted random fashion. 
-         The per route weights are the weights visible via ip route 2. As the
-         corresponding state management introduces some overhead routing delay
-         is increased.
-
-config IP_ROUTE_MULTIPATH_DRR
-       tristate "MULTIPATH: interface round robin algorithm"
-       depends on IP_ROUTE_MULTIPATH_CACHED
-       help
-         Connections are distributed in a round robin fashion over the
-         available interfaces. This policy makes sense if the connections 
-         should be primarily distributed on interfaces and not on routes. 
-
 config IP_ROUTE_VERBOSE
        bool "IP: verbose route monitoring"
        depends on IP_ADVANCED_ROUTER
@@ -169,9 +104,11 @@ config IP_ROUTE_VERBOSE
          handled by the klogd daemon which is responsible for kernel messages
          ("man klogd").
 
+config IP_ROUTE_CLASSID
+       bool
+
 config IP_PNP
        bool "IP: kernel level autoconfiguration"
-       depends on INET
        help
          This enables automatic configuration of IP addresses of devices and
          of the routing table during kernel boot, based on either information
@@ -196,7 +133,7 @@ config IP_PNP_DHCP
 
          If unsure, say Y. Note that if you want to use DHCP, a DHCP server
          must be operating on your network.  Read
-         <file:Documentation/nfsroot.txt> for details.
+         <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
 
 config IP_PNP_BOOTP
        bool "IP: BOOTP support"
@@ -211,7 +148,7 @@ config IP_PNP_BOOTP
          does BOOTP itself, providing all necessary information on the kernel
          command line, you can say N here. If unsure, say Y. Note that if you
          want to use BOOTP, a BOOTP server must be operating on your network.
-         Read <file:Documentation/nfsroot.txt> for details.
+         Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
 
 config IP_PNP_RARP
        bool "IP: RARP support"
@@ -223,14 +160,11 @@ config IP_PNP_RARP
          discovered automatically at boot time using the RARP protocol (an
          older protocol which is being obsoleted by BOOTP and DHCP), say Y
          here. Note that if you want to use RARP, a RARP server must be
-         operating on your network. Read <file:Documentation/nfsroot.txt> for
-         details.
+         operating on your network. Read
+         <file:Documentation/filesystems/nfs/nfsroot.txt> for details.
 
-# not yet ready..
-#   bool '    IP: ARP support' CONFIG_IP_PNP_ARP               
 config NET_IPIP
        tristate "IP: tunneling"
-       depends on INET
        select INET_TUNNEL
        ---help---
          Tunneling means encapsulating data of one protocol type within
@@ -246,10 +180,15 @@ config NET_IPIP
          be inserted in and removed from the running kernel whenever you
          want). Most people won't need this and can say N.
 
+config NET_IPGRE_DEMUX
+       tristate "IP: GRE demultiplexer"
+       help
+        This is helper module to demultiplex GRE packets on GRE version field criteria.
+        Required by ip_gre and pptp modules.
+
 config NET_IPGRE
        tristate "IP: GRE tunnels over IP"
-       depends on INET
-       select XFRM
+       depends on (IPV6 || IPV6=n) && NET_IPGRE_DEMUX
        help
          Tunneling means encapsulating data of one protocol type within
          another protocol and sending it over a channel that understands the
@@ -283,6 +222,20 @@ config IP_MROUTE
          <file:Documentation/networking/multicast.txt>. If you haven't heard
          about it, you don't need it.
 
+config IP_MROUTE_MULTIPLE_TABLES
+       bool "IP: multicast policy routing"
+       depends on IP_MROUTE && IP_ADVANCED_ROUTER
+       select FIB_RULES
+       help
+         Normally, a multicast router runs a userspace daemon and decides
+         what to do with a multicast packet based on the source and
+         destination addresses. If you say Y here, the multicast router
+         will also be able to take interfaces and packet marks into
+         account and run multiple instances of userspace daemons
+         simultaneously, each one handling a single table.
+
+         If unsure, say N.
+
 config IP_PIMSM_V1
        bool "IP: PIM-SM version 1 support"
        depends on IP_MROUTE
@@ -306,33 +259,23 @@ config IP_PIMSM_V2
          you want to play with it.
 
 config ARPD
-       bool "IP: ARP daemon support (EXPERIMENTAL)"
-       depends on INET && EXPERIMENTAL
+       bool "IP: ARP daemon support"
        ---help---
-         Normally, the kernel maintains an internal cache which maps IP
-         addresses to hardware addresses on the local network, so that
-         Ethernet/Token Ring/ etc. frames are sent to the proper address on
-         the physical networking layer. For small networks having a few
-         hundred directly connected hosts or less, keeping this address
-         resolution (ARP) cache inside the kernel works well. However,
-         maintaining an internal ARP cache does not work well for very large
-         switched networks, and will use a lot of kernel memory if TCP/IP
-         connections are made to many machines on the network.
-
-         If you say Y here, the kernel's internal ARP cache will never grow
-         to more than 256 entries (the oldest entries are expired in a LIFO
-         manner) and communication will be attempted with the user space ARP
-         daemon arpd. Arpd then answers the address resolution request either
-         from its own cache or by asking the net.
-
-         This code is experimental and also obsolete. If you want to use it,
-         you need to find a version of the daemon arpd on the net somewhere,
-         and you should also say Y to "Kernel/User network link driver",
-         below. If unsure, say N.
+         The kernel maintains an internal cache which maps IP addresses to
+         hardware addresses on the local network, so that Ethernet/Token Ring/
+         etc. frames are sent to the proper address on the physical networking
+         layer. Normally, kernel uses the ARP protocol to resolve these
+         mappings.
+
+         Saying Y here adds support to have an user space daemon to do this
+         resolution instead. This is useful for implementing an alternate
+         address resolution protocol (e.g. NHRP on mGRE tunnels) and also for
+         testing purposes.
+
+         If unsure, say N.
 
 config SYN_COOKIES
-       bool "IP: TCP syncookie support (disabled per default)"
-       depends on INET
+       bool "IP: TCP syncookie support"
        ---help---
          Normal TCP/IP networking is open to an attack known as "SYN
          flooding". This denial-of-service attack prevents legitimate remote
@@ -357,19 +300,18 @@ config SYN_COOKIES
          server is really overloaded. If this happens frequently better turn
          them off.
 
-         If you say Y here, note that SYN cookies aren't enabled by default;
-         you can enable them by saying Y to "/proc file system support" and
+         If you say Y here, you can disable SYN cookies at run time by
+         saying Y to "/proc file system support" and
          "Sysctl support" below and executing the command
 
-         echo 1 >/proc/sys/net/ipv4/tcp_syncookies
+         echo 0 > /proc/sys/net/ipv4/tcp_syncookies
 
-         at boot time after the /proc file system has been mounted.
+         after the /proc file system has been mounted.
 
          If unsure, say N.
 
 config INET_AH
        tristate "IP: AH transformation"
-       depends on INET
        select XFRM
        select CRYPTO
        select CRYPTO_HMAC
@@ -382,11 +324,12 @@ config INET_AH
 
 config INET_ESP
        tristate "IP: ESP transformation"
-       depends on INET
        select XFRM
        select CRYPTO
+       select CRYPTO_AUTHENC
        select CRYPTO_HMAC
        select CRYPTO_MD5
+       select CRYPTO_CBC
        select CRYPTO_SHA1
        select CRYPTO_DES
        ---help---
@@ -396,51 +339,98 @@ config INET_ESP
 
 config INET_IPCOMP
        tristate "IP: IPComp transformation"
-       depends on INET
-       select XFRM
-       select INET_TUNNEL
-       select CRYPTO
-       select CRYPTO_DEFLATE
+       select INET_XFRM_TUNNEL
+       select XFRM_IPCOMP
        ---help---
          Support for IP Payload Compression Protocol (IPComp) (RFC3173),
          typically needed for IPsec.
-         
+
          If unsure, say Y.
 
+config INET_XFRM_TUNNEL
+       tristate
+       select INET_TUNNEL
+       default n
+
 config INET_TUNNEL
-       tristate "IP: tunnel transformation"
-       depends on INET
+       tristate
+       default n
+
+config INET_XFRM_MODE_TRANSPORT
+       tristate "IP: IPsec transport mode"
+       default y
        select XFRM
        ---help---
-         Support for generic IP tunnel transformation, which is required by
-         the IP tunneling module as well as tunnel mode IPComp.
-         
+         Support for IPsec transport mode.
+
          If unsure, say Y.
 
-config IP_TCPDIAG
-       tristate "IP: TCP socket monitoring interface"
-       depends on INET
+config INET_XFRM_MODE_TUNNEL
+       tristate "IP: IPsec tunnel mode"
        default y
+       select XFRM
        ---help---
-         Support for TCP socket monitoring interface used by native Linux
-         tools such as ss. ss is included in iproute2, currently downloadable
-         at <http://developer.osdl.org/dev/iproute2>. If you want IPv6 support
-         and have selected IPv6 as a module, you need to build this as a
-         module too.
+         Support for IPsec tunnel mode.
+
+         If unsure, say Y.
+
+config INET_XFRM_MODE_BEET
+       tristate "IP: IPsec BEET mode"
+       default y
+       select XFRM
+       ---help---
+         Support for IPsec BEET mode.
+
+         If unsure, say Y.
+
+config INET_LRO
+       tristate "Large Receive Offload (ipv4/tcp)"
+       default y
+       ---help---
+         Support for Large Receive Offload (ipv4/tcp).
+
+         If unsure, say Y.
+
+config INET_DIAG
+       tristate "INET: socket monitoring interface"
+       default y
+       ---help---
+         Support for INET (TCP, DCCP, etc) socket monitoring interface used by
+         native Linux tools such as ss. ss is included in iproute2, currently
+         downloadable at:
          
+           http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
+
+         If unsure, say Y.
+
+config INET_TCP_DIAG
+       depends on INET_DIAG
+       def_tristate INET_DIAG
+
+config INET_UDP_DIAG
+       tristate "UDP: socket monitoring interface"
+       depends on INET_DIAG
+       default n
+       ---help---
+         Support for UDP socket monitoring interface used by the ss tool.
          If unsure, say Y.
 
-config IP_TCPDIAG_IPV6
-       def_bool (IP_TCPDIAG=y && IPV6=y) || (IP_TCPDIAG=m && IPV6)
+menuconfig TCP_CONG_ADVANCED
+       bool "TCP: advanced congestion control"
+       ---help---
+         Support for selection of various TCP congestion control
+         modules.
+
+         Nearly all users can safely say no here, and a safe default
+         selection will be made (CUBIC with new Reno as a fallback).
 
-# TCP Reno is builtin (required as fallback)
-menu "TCP congestion control"
-       depends on INET
+         If unsure, say N.
+
+if TCP_CONG_ADVANCED
 
 config TCP_CONG_BIC
        tristate "Binary Increase Congestion (BIC) control"
-       depends on INET
-       default y
+       default m
        ---help---
        BIC-TCP is a sender-side only change that ensures a linear RTT
        fairness under large windows while offering both scalability and
@@ -452,7 +442,191 @@ config TCP_CONG_BIC
        increase provides TCP friendliness.
        See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
 
-endmenu
+config TCP_CONG_CUBIC
+       tristate "CUBIC TCP"
+       default y
+       ---help---
+       This is version 2.0 of BIC-TCP which uses a cubic growth function
+       among other techniques.
+       See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf
+
+config TCP_CONG_WESTWOOD
+       tristate "TCP Westwood+"
+       default m
+       ---help---
+       TCP Westwood+ is a sender-side only modification of the TCP Reno
+       protocol stack that optimizes the performance of TCP congestion
+       control. It is based on end-to-end bandwidth estimation to set
+       congestion window and slow start threshold after a congestion
+       episode. Using this estimation, TCP Westwood+ adaptively sets a
+       slow start threshold and a congestion window which takes into
+       account the bandwidth used  at the time congestion is experienced.
+       TCP Westwood+ significantly increases fairness wrt TCP Reno in
+       wired networks and throughput over wireless links.
+
+config TCP_CONG_HTCP
+        tristate "H-TCP"
+        default m
+       ---help---
+       H-TCP is a send-side only modifications of the TCP Reno
+       protocol stack that optimizes the performance of TCP
+       congestion control for high speed network links. It uses a
+       modeswitch to change the alpha and beta parameters of TCP Reno
+       based on network conditions and in a way so as to be fair with
+       other Reno and H-TCP flows.
+
+config TCP_CONG_HSTCP
+       tristate "High Speed TCP"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       Sally Floyd's High Speed TCP (RFC 3649) congestion control.
+       A modification to TCP's congestion control mechanism for use
+       with large congestion windows. A table indicates how much to
+       increase the congestion window by when an ACK is received.
+       For more detail see http://www.icir.org/floyd/hstcp.html
+
+config TCP_CONG_HYBLA
+       tristate "TCP-Hybla congestion control algorithm"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       TCP-Hybla is a sender-side only change that eliminates penalization of
+       long-RTT, large-bandwidth connections, like when satellite legs are
+       involved, especially when sharing a common bottleneck with normal
+       terrestrial connections.
+
+config TCP_CONG_VEGAS
+       tristate "TCP Vegas"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       TCP Vegas is a sender-side only change to TCP that anticipates
+       the onset of congestion by estimating the bandwidth. TCP Vegas
+       adjusts the sending rate by modifying the congestion
+       window. TCP Vegas should provide less packet loss, but it is
+       not as aggressive as TCP Reno.
+
+config TCP_CONG_SCALABLE
+       tristate "Scalable TCP"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       Scalable TCP is a sender-side only change to TCP which uses a
+       MIMD congestion control algorithm which has some nice scaling
+       properties, though is known to have fairness issues.
+       See http://www.deneholme.net/tom/scalable/
+
+config TCP_CONG_LP
+       tristate "TCP Low Priority"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
+       to utilize only the excess network bandwidth as compared to the
+       ``fair share`` of bandwidth as targeted by TCP.
+       See http://www-ece.rice.edu/networks/TCP-LP/
+
+config TCP_CONG_VENO
+       tristate "TCP Veno"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       TCP Veno is a sender-side only enhancement of TCP to obtain better
+       throughput over wireless networks. TCP Veno makes use of state
+       distinguishing to circumvent the difficult judgment of the packet loss
+       type. TCP Veno cuts down less congestion window in response to random
+       loss packets.
+       See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186> 
+
+config TCP_CONG_YEAH
+       tristate "YeAH TCP"
+       depends on EXPERIMENTAL
+       select TCP_CONG_VEGAS
+       default n
+       ---help---
+       YeAH-TCP is a sender-side high-speed enabled TCP congestion control
+       algorithm, which uses a mixed loss/delay approach to compute the
+       congestion window. It's design goals target high efficiency,
+       internal, RTT and Reno fairness, resilience to link loss while
+       keeping network elements load as low as possible.
+
+       For further details look here:
+         http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
+
+config TCP_CONG_ILLINOIS
+       tristate "TCP Illinois"
+       depends on EXPERIMENTAL
+       default n
+       ---help---
+       TCP-Illinois is a sender-side modification of TCP Reno for
+       high speed long delay links. It uses round-trip-time to
+       adjust the alpha and beta parameters to achieve a higher average
+       throughput and maintain fairness.
+
+       For further details see:
+         http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html
+
+choice
+       prompt "Default TCP congestion control"
+       default DEFAULT_CUBIC
+       help
+         Select the TCP congestion control that will be used by default
+         for all connections.
+
+       config DEFAULT_BIC
+               bool "Bic" if TCP_CONG_BIC=y
+
+       config DEFAULT_CUBIC
+               bool "Cubic" if TCP_CONG_CUBIC=y
+
+       config DEFAULT_HTCP
+               bool "Htcp" if TCP_CONG_HTCP=y
+
+       config DEFAULT_HYBLA
+               bool "Hybla" if TCP_CONG_HYBLA=y
 
-source "net/ipv4/ipvs/Kconfig"
+       config DEFAULT_VEGAS
+               bool "Vegas" if TCP_CONG_VEGAS=y
 
+       config DEFAULT_VENO
+               bool "Veno" if TCP_CONG_VENO=y
+
+       config DEFAULT_WESTWOOD
+               bool "Westwood" if TCP_CONG_WESTWOOD=y
+
+       config DEFAULT_RENO
+               bool "Reno"
+
+endchoice
+
+endif
+
+config TCP_CONG_CUBIC
+       tristate
+       depends on !TCP_CONG_ADVANCED
+       default y
+
+config DEFAULT_TCP_CONG
+       string
+       default "bic" if DEFAULT_BIC
+       default "cubic" if DEFAULT_CUBIC
+       default "htcp" if DEFAULT_HTCP
+       default "hybla" if DEFAULT_HYBLA
+       default "vegas" if DEFAULT_VEGAS
+       default "westwood" if DEFAULT_WESTWOOD
+       default "veno" if DEFAULT_VENO
+       default "reno" if DEFAULT_RENO
+       default "cubic"
+
+config TCP_MD5SIG
+       bool "TCP: MD5 Signature Option support (RFC2385) (EXPERIMENTAL)"
+       depends on EXPERIMENTAL
+       select CRYPTO
+       select CRYPTO_MD5
+       ---help---
+         RFC2385 specifies a method of giving MD5 protection to TCP sessions.
+         Its main (only?) use is to protect BGP sessions between core routers
+         on the Internet.
+
+         If unsure, say N.