nuttx/net/tcp/Kconfig

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#

menu "TCP/IP Networking"

config NET_TCP
	bool "TCP/IP Networking"
	default n
	---help---
		Enable or disable TCP networking support.

config NET_TCP_NO_STACK
	bool "Disable TCP/IP Stack"
	default n
	select NET_TCP
	---help---
		Build without TCP/IP stack even if TCP networking support enabled.

if NET_TCP && !NET_TCP_NO_STACK

config NET_TCP_KEEPALIVE
	bool "TCP/IP Keep-alive support"
	default n
	select NET_TCPPROTO_OPTIONS
	---help---
		Enable support for the SO_KEEPALIVE socket option

config NET_TCPURGDATA
	bool "Urgent data"
	default n
	---help---
		Determines if support for TCP urgent data notification should be
		compiled in. Urgent data (out-of-band data) is a rarely used TCP feature
		that is very seldom would be required.

config NET_TCP_CONNS
	int "Number of TCP/IP connections"
	default 8
	---help---
		Maximum number of TCP/IP connections (all tasks)

config NET_MAX_LISTENPORTS
	int "Number of listening ports"
	default 20
	---help---
		Maximum number of listening TCP/IP ports (all tasks).  Default: 20

config TCP_NOTIFIER
	bool "Support TCP notifications"
	default n
	depends on SCHED_LPWORK
	select WQUEUE_NOTIFIER
	---help---
		Enable building of TCP notifier logic that will execute a worker
		function on the low priority work queue when read-ahead data
		is available or when a TCP connection is lost.  This is is a general
		purpose notifier, but was developed specifically to support poll()
		logic where the poll must wait for these events.

config NET_TCP_READAHEAD
	bool "Enable TCP/IP read-ahead buffering"
	default y
	select NET_READAHEAD
	select MM_IOB
	---help---
		Read-ahead buffers allows buffering of TCP/IP packets when there is no
		receive in place to catch the TCP packet.  In that case, the packet
		will be retained in the NuttX read-ahead buffers.

		You might want to disable TCP/IP read-ahead buffering on a highly
		memory constrained system that does not have any TCP/IP packet rate
		issues.  But, if disabled, there will probably be more packet
		retransmissions or even packet loss.

		Make sure that you check the setting in the I/O Buffering menu.
		These settings are critical to the reasonable operation of read-
		ahead buffering.

config NET_TCP_WRITE_BUFFERS
	bool "Enable TCP/IP write buffering"
	default n
	select NET_WRITE_BUFFERS
	select MM_IOB
	---help---
		Write buffers allows buffering of ongoing TCP/IP packets, providing
		for higher performance, streamed output.

		You might want to disable TCP/IP write buffering on a highly memory
		memory constrained system where there are no performance issues.

if NET_TCP_WRITE_BUFFERS

config NET_TCP_NWRBCHAINS
	int "Number of pre-allocated I/O buffer chain heads"
	default 8
	---help---
		These tiny nodes are used as "containers" to support queuing of
		TCP write buffers.  This setting will limit the number of TCP write
		operations that can be "in-flight" at any give time.  So a good
		choice for this value would be the same as the maximum number of
		TCP connections.

config NET_TCP_WRBUFFER_DEBUG
	bool "Force write buffer debug"
	default n
	depends on DEBUG_FEATURES
	select IOB_DEBUG
	---help---
		This option will force debug output from TCP write buffer logic,
		even without network debug output.  This is not normally something
		that would want to do but is convenient if you are debugging the
		write buffer logic and do not want to get overloaded with other
		network-related debug output.

config NET_TCP_WRBUFFER_DUMP
	bool "Force write buffer dump"
	default n
	depends on DEBUG_NET || NET_TCP_WRBUFFER_DEBUG
	select IOB_DEBUG
	---help---
		Dump the contents of the write buffers.  You do not want to do this
		unless you really want to analyze the write buffer transfers in
		detail.

endif # NET_TCP_WRITE_BUFFERS

config NET_TCP_RECVDELAY
	int "TCP Rx delay"
	default 0
	---help---
		If NET_TCP_READAHEAD_BUFFERS is undefined, then there will be no buffering
		of TCP/IP packets:  Any TCP/IP packet received will be ACKed, but its contents
		will be dropped in the bit-bucket.

		One low-performance option is delay for a short period of time after a
		TCP/IP packet is received to see if another comes right behind it. Then
		the packet data from both can be combined.  This option only makes since
		if performance is not an issue and you need to handle short bursts of
		small, back-to-back packets.  The delay is in units of deciseconds.

config NET_TCPBACKLOG
	bool "TCP/IP backlog support"
	default n
	---help---
		Incoming connections pend in a backlog until accept() is called.
		The size of the backlog is selected when listen() is called.

config NET_TCP_SPLIT
	bool "Enable packet splitting"
	default n
	depends on !NET_TCP_WRITE_BUFFERS
	---help---
		send() will not return until the transfer has been ACKed by the
		recipient.  But under RFC 1122, the host need not ACK each packet
		immediately; the host may wait for 500 MS before ACKing.  This
		combination can cause very slow performance with small transfers are
		made to an RFC 1122 client.  However, the RFC 1122 must ACK at least
		every second (odd) packet.

		This option enables logic to trick the RFC 1122 host be exploiting
		this last RFC 1122 requirement:  If an odd number of packets were to
		be sent, then send() will split the last even packet to guarantee
		that an even number of packets will be sent and the RFC 1122 host
		will ACK the final packet immediately.

if NET_TCP_SPLIT

config NET_TCP_SPLIT_SIZE
	int "Split size threshold"
	default 40
	---help---
		Packets of this size or smaller than this will not be split.

endif # NET_TCP_SPLIT

config NET_SENDFILE
	bool "Optimized network sendfile()"
	default n
	---help---
		Support larger, higher performance sendfile() for transferring
		files out a TCP connection.

endif # NET_TCP && !NET_TCP_NO_STACK
endmenu # TCP/IP Networking