@@ -669,6 +669,7 @@ static int rxrpc_send_data(struct kiocb *iocb,
/* add the packet to the send queue if it's now full */
if (sp->remain <= 0 || (segment == 0 && !more)) {
struct rxrpc_connection *conn = call->conn;
+ uint32_t seq;
size_t pad;
/* pad out if we're using security */
@@ -681,11 +682,12 @@ static int rxrpc_send_data(struct kiocb *iocb,
memset(skb_put(skb, pad), 0, pad);
}
+ seq = atomic_inc_return(&call->sequence);
+
sp->hdr.epoch = conn->epoch;
sp->hdr.cid = call->cid;
sp->hdr.callNumber = call->call_id;
- sp->hdr.seq =
- htonl(atomic_inc_return(&call->sequence));
+ sp->hdr.seq = htonl(seq);
sp->hdr.serial =
htonl(atomic_inc_return(&conn->serial));
sp->hdr.type = RXRPC_PACKET_TYPE_DATA;
@@ -700,6 +702,8 @@ static int rxrpc_send_data(struct kiocb *iocb,
else if (CIRC_SPACE(call->acks_head, call->acks_tail,
call->acks_winsz) > 1)
sp->hdr.flags |= RXRPC_MORE_PACKETS;
+ if (more && seq & 1)
+ sp->hdr.flags |= RXRPC_REQUEST_ACK;
ret = rxrpc_secure_packet(
call, skb, skb->mark,
Set the RxRPC header flag to request an ACK packet for every odd-numbered DATA packet unless it's the last one (which implicitly requests an ACK anyway). This is similar to how librx appears to work. If we don't do this, we'll send out a full window of packets and then just sit there until the other side gets bored and sends an ACK to indicate that it's been idle for a while and has received no new packets. Requesting a lot of ACKs shouldn't be a problem as ACKs should be merged when possible. As AF_RXRPC currently works, it will schedule an ACK to be generated upon receipt of a DATA packet with the ACK-request packet set - and in the time taken to schedule this in a work queue, several other packets are likely to arrive and then all get ACK'd together. Signed-off-by: David Howells <dhowells@redhat.com> --- net/rxrpc/ar-output.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html