fs: dlm: rework receive handling
authorAlexander Aring <aahringo@redhat.com>
Thu, 24 Sep 2020 14:31:26 +0000 (10:31 -0400)
committerDavid Teigland <teigland@redhat.com>
Tue, 29 Sep 2020 19:00:32 +0000 (14:00 -0500)
commit4798cbbfbd00c498339bdcf4cc2429f53eb374ec
tree97d35239f9ce8c5a3453234629b7a5b54732cb53
parent4e192ee68e5af301470a925b76700d788db35d96
fs: dlm: rework receive handling

This patch reworks the current receive handling of dlm. As I tried to
change the send handling to fix reorder issues I took a look into the
receive handling and simplified it, it works as the following:

Each connection has a preallocated receive buffer with a minimum length of
4096. On receive, the upper layer protocol will process all dlm message
until there is not enough data anymore. If there exists "leftover" data at
the end of the receive buffer because the dlm message wasn't fully received
it will be copied to the begin of the preallocated receive buffer. Next
receive more data will be appended to the previous "leftover" data and
processing will begin again.

This will remove a lot of code of the current mechanism. Inside the
processing functionality we will ensure with a memmove() that the dlm
message should be memory aligned. To have a dlm message always started
at the beginning of the buffer will reduce some amount of memmove()
calls because src and dest pointers are the same.

The cluster attribute "buffer_size" becomes a new meaning, it's now the
size of application layer receive buffer size. If this is changed during
runtime the receive buffer will be reallocated. It's important that the
receive buffer size has at minimum the size of the maximum possible dlm
message size otherwise the received message cannot be placed inside
the receive buffer size.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
fs/dlm/config.c
fs/dlm/config.h
fs/dlm/lowcomms.c
fs/dlm/midcomms.c
fs/dlm/midcomms.h