2014-06-18 19:45:55 +02:00
|
|
|
#
|
|
|
|
# For a description of the syntax of this configuration file,
|
|
|
|
# see misc/tools/kconfig-language.txt.
|
|
|
|
#
|
|
|
|
|
|
|
|
menu "TCP/IP Networking"
|
|
|
|
|
|
|
|
config NET_TCP
|
|
|
|
bool "TCP/IP Networking"
|
|
|
|
default n
|
|
|
|
---help---
|
|
|
|
TCP support on or off
|
|
|
|
|
|
|
|
if NET_TCP
|
|
|
|
|
|
|
|
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 NET_TCP_READAHEAD
|
|
|
|
bool "Enable TCP/IP read-ahead buffering"
|
|
|
|
default y
|
|
|
|
---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.
|
|
|
|
|
|
|
|
if NET_TCP_READAHEAD
|
|
|
|
|
|
|
|
config NET_TCP_READAHEAD_BUFSIZE
|
|
|
|
int "TCP/IP read-ahead buffer size"
|
|
|
|
default 1220 if !NET_SLIP && NET_IPv6
|
|
|
|
default 536 if !NET_SLIP && !NET_IPv6
|
|
|
|
default 256 if NET_SLIP && !NET_IPv6
|
|
|
|
---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.
|
|
|
|
|
|
|
|
This setting specifies the size of one TCP/IP read-ahead buffer.
|
|
|
|
This should best be a equal to the maximum packet payload size (MSS).
|
|
|
|
|
|
|
|
Optimally, the size of the read-ahead buffer will should the maximum
|
|
|
|
size of an incoming TCP packet payload (MSS). This MSS value is
|
|
|
|
determined by NET_BUFSIZE minus the size of TCP, IP, and Ethernet
|
|
|
|
headers (assuming you are using the Ethernet transport). IPv4 hosts
|
|
|
|
are required to be able to handle an MSS of 536 octets and IPv6 hosts
|
|
|
|
are required to be able to handle an MSS of 1220 octets.
|
|
|
|
|
|
|
|
config NET_NTCP_READAHEAD_BUFFERS
|
|
|
|
int "Number of TCP/IP read-ahead buffers"
|
|
|
|
default 8
|
|
|
|
---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.
|
|
|
|
|
|
|
|
This setting specifies the number of TCP/IP read-ahead buffers.
|
|
|
|
|
|
|
|
endif # NET_TCP_READAHEAD
|
|
|
|
|
|
|
|
config NET_TCP_WRITE_BUFFERS
|
|
|
|
bool "Enable TCP/IP write buffering"
|
|
|
|
default n
|
2014-06-22 19:27:57 +02:00
|
|
|
select NET_IOB
|
2014-06-18 19:45:55 +02:00
|
|
|
---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
|
|
|
|
|
2014-06-22 19:27:57 +02:00
|
|
|
config NET_TCP_NWRBCHAINS
|
|
|
|
int "Number of pre-allocated I/O buffer chain heads"
|
2014-06-18 19:45:55 +02:00
|
|
|
default 8
|
|
|
|
---help---
|
2014-06-22 19:27:57 +02:00
|
|
|
These tiny nodes are used as "containers" to support queueing 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.
|
2014-06-18 19:45:55 +02:00
|
|
|
|
|
|
|
config NET_TCP_WRBUFFER_DEBUG
|
|
|
|
bool "Force write buffer debug"
|
|
|
|
default n
|
|
|
|
depends on DEBUG
|
2014-06-23 00:25:26 +02:00
|
|
|
select NET_IOB_DEBUG
|
2014-06-18 19:45:55 +02:00
|
|
|
---help---
|
|
|
|
This option will force debug output from TCP write buffer logic,
|
2014-06-23 00:25:26 +02:00
|
|
|
even without network debug output. This is not normally something
|
2014-06-18 19:45:55 +02:00
|
|
|
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.
|
|
|
|
|
2014-06-23 02:53:18 +02:00
|
|
|
config NET_TCP_WRBUFFER_DUMP
|
|
|
|
bool "Force write buffer dump"
|
|
|
|
default n
|
|
|
|
depends on DEBUG_NET || NET_TCP_WRBUFFER_DEBUG
|
|
|
|
select NET_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.
|
|
|
|
|
2014-06-18 19:45:55 +02:00
|
|
|
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
|
|
|
|
endmenu # TCP/IP Networking
|