summaryrefslogtreecommitdiffstats
path: root/include/uapi/linux/prctl.h
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2014-02-07 18:58:45 +0000
committerDavid Howells <dhowells@redhat.com>2014-02-26 17:25:07 +0000
commit9823f39a1719dce0da8a47cdd5c66ff8831f03f2 (patch)
treec84e0d13c5e9764ab8287a0251af3c17bccc22dc /include/uapi/linux/prctl.h
parent5873c0834f8896aa9da338b941035a2f8b29e99b (diff)
downloadop-kernel-dev-9823f39a1719dce0da8a47cdd5c66ff8831f03f2.zip
op-kernel-dev-9823f39a1719dce0da8a47cdd5c66ff8831f03f2.tar.gz
af_rxrpc: Improve ACK production
Improve ACK production by the following means: (1) Don't send an ACK_REQUESTED ack immediately even if the RXRPC_MORE_PACKETS flag isn't set on a data packet that has also has RXRPC_REQUEST_ACK set. MORE_PACKETS just means that the sender just emptied its Tx data buffer. More data will be forthcoming unless RXRPC_LAST_PACKET is also flagged. It is possible to see runs of DATA packets with MORE_PACKETS unset that aren't waiting for an ACK. It is therefore better to wait a small instant to see if we can combine an ACK for several packets. (2) Don't send an ACK_IDLE ack immediately unless we're responding to the terminal data packet of a call. Whilst sending an ACK_IDLE mid-call serves to let the other side know that we won't be asking it to resend certain Tx buffers and that it can discard them, spamming it with loads of acks just because we've temporarily run out of data just distracts it. (3) Put the ACK_IDLE ack generation timeout up to half a second rather than a single jiffy. Just because we haven't been given more data immediately doesn't mean that more isn't forthcoming. The other side may be busily finding the data to send to us. Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'include/uapi/linux/prctl.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud