incubator-nuttx/mm/iob/Kconfig

88 lines
3.0 KiB
Plaintext
Raw Normal View History

2014-06-04 02:41:34 +08:00
#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
2014-06-04 02:41:34 +08:00
#
menu "Common I/O Buffer Support"
config MM_IOB
bool "Enable generic I/O buffer support"
2014-06-04 02:41:34 +08:00
default n
---help---
This setting will build the common I/O buffer (IOB) support
2014-06-04 02:41:34 +08:00
library.
if MM_IOB
2014-06-04 02:41:34 +08:00
config IOB_NBUFFERS
int "Number of pre-allocated I/O buffers"
default 24 if (NET_WRITE_BUFFERS && !NET_READAHEAD) || (!NET_WRITE_BUFFERS && NET_READAHEAD)
default 36 if NET_WRITE_BUFFERS && NET_READAHEAD
default 8 if !NET_WRITE_BUFFERS && !NET_READAHEAD
2014-06-04 02:41:34 +08:00
---help---
Each packet is represented by a series of small I/O buffers in a
chain. This setting determines the number of preallocated I/O
buffers available for packet data.
config IOB_BUFSIZE
int "Payload size of one I/O buffer"
default 196
2014-06-04 02:41:34 +08:00
---help---
Each packet is represented by a series of small I/O buffers in a
chain. This setting determines the data payload each preallocated
I/O buffer.
config IOB_NCHAINS
int "Number of pre-allocated I/O buffer chain heads"
default 0 if !NET_READAHEAD && !NET_UDP_READAHEAD
default 8 if NET_READAHEAD || NET_UDP_READAHEAD
---help---
These tiny nodes are used as "containers" to support queueing of
I/O buffer chains. This will limit the number of I/O transactions
that can be "in-flight" at any give time. The default value of
zero disables this features.
These generic I/O buffer chain containers are not currently used
by any logic in NuttX. That is because their other other specialized
I/O buffer chain containers that also carry a payload of usage
specific information.
config IOB_THROTTLE
int "I/O buffer throttle value"
default 0 if !NET_WRITE_BUFFERS || !NET_READAHEAD
default 8 if NET_WRITE_BUFFERS && NET_READAHEAD
---help---
TCP write buffering and read-ahead buffer use the same pool of free
I/O buffers. In order to prevent uncontrolled incoming TCP packets
from hogging all of the available, pre-allocated I/O buffers, a
throttling value is required. This throttle value assures that
I/O buffers will be denied to the read-ahead logic before TCP writes
are halted.
config IOB_NOTIFIER
bool "Support IOB notifications"
default n
depends on SCHED_HPWORK
---help---
Enable building of IOB notifier logic that will execute a worker
function on the high priority work queue when an IOB is available.
This is is a general purpose notifier, but was developed specifically to
support poll() logic where the poll must wait for an IOB to become
available.
config IOB_DEBUG
bool "Force I/O buffer debug"
default n
There can be a failure in IOB allocation to some asynchronous behavior caused by the use of sem_post(). Consider this scenario: Task A holds an IOB.  There are no further IOBs.  The value of semcount is zero. Task B calls iob_alloc().  Since there are not IOBs, it calls sem_wait().  The v alue of semcount is now -1. Task A frees the IOB.  iob_free() adds the IOB to the free list and calls sem_post() this makes Task B ready to run and sets semcount to zero NOT 1.  There is one IOB in the free list and semcount is zero.  When Task B wakes up it would increment the sem_count back to the correct value. But an interrupt or another task runs occurs before Task B executes.  The interrupt or other tak takes the IOB off of the free list and decrements the semcount.  But since semcount is then < 0, this causes the assertion because that is an invalid state in the interrupt handler. So I think that the root cause is that there the asynchrony between incrementing the semcount. This change separates the list of IOBs: Currently there is only a free list of IOBs. The problem, I believe, is because of asynchronies due sem_post() post cause the semcount and the list content to become out of sync. This change adds a new 'committed' list: When there is a task waiting for an IOB, it will go into the committed list rather than the free list before the semaphore is posted. On the waiting side, when awakened from the semaphore wait, it will expect to find its IOB in the committed list, rather than free list. In this way, the content of the free list and the value of the semaphore count always remain in sync.
2017-05-17 01:03:35 +08:00
depends on DEBUG_FEATURES && !SYSLOG_BUFFER
---help---
This option will force debug output from I/O buffer logic. This
is not normally something that would want to do but is convenient
if you are debugging the I/O buffer logic and do not want to get
overloaded with other un-related debug output.
NOTE that this selection is not available if IOBs are being used
There can be a failure in IOB allocation to some asynchronous behavior caused by the use of sem_post(). Consider this scenario: Task A holds an IOB.  There are no further IOBs.  The value of semcount is zero. Task B calls iob_alloc().  Since there are not IOBs, it calls sem_wait().  The v alue of semcount is now -1. Task A frees the IOB.  iob_free() adds the IOB to the free list and calls sem_post() this makes Task B ready to run and sets semcount to zero NOT 1.  There is one IOB in the free list and semcount is zero.  When Task B wakes up it would increment the sem_count back to the correct value. But an interrupt or another task runs occurs before Task B executes.  The interrupt or other tak takes the IOB off of the free list and decrements the semcount.  But since semcount is then < 0, this causes the assertion because that is an invalid state in the interrupt handler. So I think that the root cause is that there the asynchrony between incrementing the semcount. This change separates the list of IOBs: Currently there is only a free list of IOBs. The problem, I believe, is because of asynchronies due sem_post() post cause the semcount and the list content to become out of sync. This change adds a new 'committed' list: When there is a task waiting for an IOB, it will go into the committed list rather than the free list before the semaphore is posted. On the waiting side, when awakened from the semaphore wait, it will expect to find its IOB in the committed list, rather than free list. In this way, the content of the free list and the value of the semaphore count always remain in sync.
2017-05-17 01:03:35 +08:00
to syslog buffering logic (CONFIG_SYSLOG_BUFFER=y)!
endif # MM_IOB
endmenu # Common I/O buffer support