530403d9ba
Clean up the rxrpc_propose_ACK() function. If deferred PING ACK proposal is split out, it's only really needed for deferred DELAY ACKs. All other ACKs, bar terminal IDLE ACK are sent immediately. The deferred IDLE ACK submission can be handled by conversion of a DELAY ACK into an IDLE ACK if there's nothing to be SACK'd. Also, because there's a delay between an ACK being generated and being transmitted, it's possible that other ACKs of the same type will be generated during that interval. Apart from the ACK time and the serial number responded to, most of the ACK body, including window and SACK parameters, are not filled out till the point of transmission - so we can avoid generating a new ACK if there's one pending that will cover the SACK data we need to convey. Therefore, don't propose a new DELAY or IDLE ACK for a call if there's one already pending. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org |
||
---|---|---|
.. | ||
af_rxrpc.c | ||
ar-internal.h | ||
call_accept.c | ||
call_event.c | ||
call_object.c | ||
conn_client.c | ||
conn_event.c | ||
conn_object.c | ||
conn_service.c | ||
input.c | ||
insecure.c | ||
Kconfig | ||
key.c | ||
local_event.c | ||
local_object.c | ||
Makefile | ||
misc.c | ||
net_ns.c | ||
output.c | ||
peer_event.c | ||
peer_object.c | ||
proc.c | ||
protocol.h | ||
recvmsg.c | ||
rtt.c | ||
rxkad.c | ||
security.c | ||
sendmsg.c | ||
server_key.c | ||
skbuff.c | ||
sysctl.c | ||
txbuf.c | ||
utils.c |