[AF_RXRPC]: Sort out MTU handling.
authorDavid Howells <dhowells@redhat.com>
Fri, 4 May 2007 19:41:11 +0000 (12:41 -0700)
committerDavid S. Miller <davem@davemloft.net>
Fri, 4 May 2007 19:41:11 +0000 (12:41 -0700)
commit224711df5c00f7540b89f32a8225866031977f17
tree7b515b1e0fff3b5c8ffc01400486beb300395f9e
parentda99f0565477899f08b76ffcb32afbf6fa95d64a
[AF_RXRPC]: Sort out MTU handling.

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>
net/rxrpc/ar-ack.c
net/rxrpc/ar-error.c
net/rxrpc/ar-output.c
net/rxrpc/ar-peer.c