794adc5814
Fragmentation of network data will intensify iob consumption, if the device receives a message storm of fragmented packets, the iob cache will not be effectively used, this is not allowed on iot devices since the resources of such devices are limited. Of course, this also takes some disadvantages: data needs to be copied. This option will brings some balance on resource-constrained devices, enable this config to reduce the consumption of iob, the received iob buffers will be merged into the contiguous iob chain. Signed-off-by: chao an <anchao@xiaomi.com>
237 lines
7.4 KiB
Plaintext
237 lines
7.4 KiB
Plaintext
#
|
|
# 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
|
|
select NET_READAHEAD if !NET_TCP_NO_STACK
|
|
---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_DELAYED_ACK
|
|
bool "TCP/IP Delayed ACK"
|
|
default n
|
|
---help---
|
|
RFC 1122: A host that is receiving a stream of TCP data segments
|
|
can increase efficiency in both the Internet and the hosts
|
|
by sending fewer than one ACK (acknowledgment) segment per data
|
|
segment received; this is known as a "delayed ACK".
|
|
|
|
TCP should implement a delayed ACK, but an ACK should not be
|
|
excessively delayed; in particular, the delay MUST be less than
|
|
0.5 seconds, and in a stream of full-sized segments there should
|
|
be an ACK for at least every second segments.
|
|
|
|
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_TCP_NPOLLWAITERS
|
|
int "Number of TCP poll waiters"
|
|
default 1
|
|
|
|
config NET_TCP_RTO
|
|
int "RTO of TCP/IP connections"
|
|
default 3
|
|
---help---
|
|
RTO of TCP/IP connections (all tasks)
|
|
|
|
config NET_TCP_MAXRTX
|
|
int "Maximum retransmitted number of TCP/IP data packet"
|
|
default 8
|
|
|
|
config NET_TCP_MAXSYNRTX
|
|
int "Maximum retransmitted number of TCP/IP SYN packet"
|
|
default 5
|
|
|
|
config NET_TCP_WAIT_TIMEOUT
|
|
int "TIME_WAIT Length of TCP/IP connections"
|
|
default 120
|
|
---help---
|
|
TIME_WAIT Length of TCP/IP connections (all tasks). In units
|
|
of seconds.
|
|
|
|
config NET_MAX_LISTENPORTS
|
|
int "Number of listening ports"
|
|
default 20
|
|
---help---
|
|
Maximum number of listening TCP/IP ports (all tasks). Default: 20
|
|
|
|
config NET_TCP_FAST_RETRANSMIT
|
|
bool "Enable the Fast Retransmit algorithm"
|
|
default y
|
|
---help---
|
|
RFC2001:
|
|
3. Fast Retransmit
|
|
Modifications to the congestion avoidance algorithm were proposed in
|
|
1990 [3]. Before describing the change, realize that TCP may
|
|
generate an immediate acknowledgment (a duplicate ACK) when an out-
|
|
of-order segment is received (Section 4.2.2.21 of [1], with a note
|
|
that one reason for doing so was for the experimental fast-
|
|
retransmit algorithm). This duplicate ACK should not be delayed.
|
|
The purpose of this duplicate ACK is to let the other end know that a
|
|
segment was received out of order, and to tell it what sequence
|
|
number is expected.
|
|
|
|
Since TCP does not know whether a duplicate ACK is caused by a lost
|
|
segment or just a reordering of segments, it waits for a small number
|
|
of duplicate ACKs to be received. It is assumed that if there is
|
|
just a reordering of the segments, there will be only one or two
|
|
duplicate ACKs before the reordered segment is processed, which will
|
|
then generate a new ACK. If three or more duplicate ACKs are
|
|
received in a row, it is a strong indication that a segment has been
|
|
lost. TCP then performs a retransmission of what appears to be the
|
|
missing segment, without waiting for a retransmission timer to
|
|
expire.
|
|
|
|
config NET_TCP_WINDOW_SCALE
|
|
bool "Enable TCP/IP Window Scale Option"
|
|
default n
|
|
---help---
|
|
RFC1323:
|
|
2. TCP WINDOW SCALE OPTION
|
|
The window scale extension expands the definition of the TCP
|
|
window to 32 bits and then uses a scale factor to carry this 32-
|
|
bit value in the 16-bit Window field of the TCP header (SEG.WND in
|
|
RFC-793).
|
|
|
|
if NET_TCP_WINDOW_SCALE
|
|
|
|
config NET_TCP_WINDOW_SCALE_FACTOR
|
|
int "TCP/IP Window Scale Factor"
|
|
default 0
|
|
---help---
|
|
This is the default value for window scale factor.
|
|
|
|
endif # NET_TCP_WINDOW_SCALE
|
|
|
|
config NET_TCP_NOTIFIER
|
|
bool "Support TCP notifications"
|
|
default n
|
|
depends on SCHED_WORKQUEUE
|
|
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_WRITE_BUFFERS
|
|
bool "Enable TCP/IP write buffering"
|
|
default n
|
|
select NET_WRITE_BUFFERS
|
|
---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_RECV_CONTIG
|
|
bool "Enable TCP/IP receive data in a continuous poll"
|
|
default y
|
|
---help---
|
|
This option will enable TCP/IP receive data into a continuous iob chain.
|
|
Fragmentation of network data will intensify iob consumption, if
|
|
the device receives a message storm of fragmented packets, the iob
|
|
cache will not be effectively used, this is not allowed on iot devices
|
|
since the resources of such devices are limited. Of course, this
|
|
also takes some disadvantages: data needs to be copied.
|
|
This option will brings some balance on resource-constrained devices,
|
|
enable this config to reduce the consumption of iob, the received iob
|
|
buffers will be merged into the contiguous iob chain.
|
|
|
|
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.
|
|
|
|
if NET_TCPBACKLOG
|
|
|
|
config NET_TCPBACKLOG_CONNS
|
|
int "TCP backlog conns threshold"
|
|
default 8
|
|
---help---
|
|
Maximum number of TCP backlog connections (all tasks).
|
|
|
|
endif # NET_TCPBACKLOG
|
|
|
|
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
|