224711df5c
Sort out the MTU determination and handling in AF_RXRPC:
(1) If it's present, parse the additional information supplied by the peer at
the end of the ACK packet (struct ackinfo) to determine the MTU sizes
that peer is willing to support.
(2) Initialise the MTU size to that peer from the kernel's routing records.
(3) Send ACKs rather than ACKALLs as the former carry the additional info,
and the latter do not.
(4) Declare the interface MTU size in outgoing ACKs as a maximum amount of
data that can be stuffed into an RxRPC packet without it having to be
fragmented to come in this computer's NIC.
(5) If sendmsg() is given MSG_MORE then it should allocate an skb of the
maximum size rather than one just big enough for the data it's got left
to process on the theory that there is more data to come that it can
append to that packet.
This means, for example, that if AFS does a large StoreData op, all the
packets barring the last will be filled to the maximum unfragmented size.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||
|---|---|---|
| .. | ||
| af_rxrpc.c | ||
| ar-accept.c | ||
| ar-ack.c | ||
| ar-call.c | ||
| ar-connection.c | ||
| ar-connevent.c | ||
| ar-error.c | ||
| ar-input.c | ||
| ar-internal.h | ||
| ar-key.c | ||
| ar-local.c | ||
| ar-output.c | ||
| ar-peer.c | ||
| ar-proc.c | ||
| ar-recvmsg.c | ||
| ar-security.c | ||
| ar-skbuff.c | ||
| ar-transport.c | ||
| Kconfig | ||
| Makefile | ||
| rxkad.c | ||