Lustre Message Header
~~~~~~~~~~~~~~~~~~~~~
[[struct-lustre-msg]]

Every message has an initial header that informs the receiver about
the number of buffers and their size for the rest of the message to
follow, along with other important information about the request or
reply message.

[source,c]
----
#define LUSTRE_MSG_MAGIC_V2 0x0BD00BD3
#define MSGHDR_AT_SUPPORT               0x1
struct lustre_msg {
        __u32 lm_bufcount;
        __u32 lm_secflvr;
        __u32 lm_magic;
        __u32 lm_repsize;
        __u32 lm_cksum;
        __u32 lm_flags;
        __u32 lm_padding_2;
        __u32 lm_padding_3;
        __u32 lm_buflens[0];
};
----

The 'lm_bufcount' field holds the number of buffers that will follow
the header. The header and sequence of buffers constitutes one
message. Each of the buffers is a sequence of bytes whose contents
corresponds to one of the structures described in this section. Each
message will always have at least one buffer, and no message can have
more than thirty-one buffers.

The 'lm_secflvr' field gives an indication of whether any sort of
cyptographic encoding of the subsequent buffers will be in force. The
value is zero if there is no "crypto" and gives a code identifying the
"flavor" of crypto if it is employed. Further, if crypto is employed
there will only be one buffer following (i.e. 'lm_bufcount' = 1), and
that buffer holds an encoding of what would otherwise have been the
sequence of buffers normally following the header.  Cryptography will
be discussed in a separate chapter.

The 'lm_magic' field is a "magic" value (LUSTRE_MSG_MAGIC_V2 = 0x0BD00BD3,
'OBD' for 'object based device') that is
checked in order to positively identify that the message is intended
for the use to which it is being put. That is, we are indeed dealing
with a Lustre message, and not, for example, corrupted memory or a bad
pointer.

The 'lm_repsize' field in a request indicates the maximum available
space that has been reserved for any reply to the request. A reply
that attempts to use more than the reserved space will be discarded.

The 'lm_cksum' field contains a checksum of the 'ptlrpc_body' buffer
to allow the receiver to verify that the message is intact.  This is
used to verify that an 'early reply' has not been overwritten by the
actual reply message.  If the 'MSGHDR_CKSUM_INCOMPAT18' flag is set
in requests since Lustre 1.8
(the server will send early reply messages with the appropriate 'lm_cksum'
if it understands the flag
and is mandatory in Lustre 2.8 and later.

The 'lm_flags' field contains flags that affect the low-level RPC
protocol.  The 'MSGHDR_AT_SUPPORT' (0x1) bit indicates that the sender
understands adaptive timeouts and can receive 'early reply' messages
to extend its waiting period rather than timing out.  This flag was
introduced in Lustre 1.6.  The 'MSGHDR_CKSUM_INCOMPAT18' (0x2) bit
indicates that 'lm_cksum' is computed on the full 'ptlrpc_body'
message buffer rather than on the original 'ptlrpc_body_v2' structure
size (88 bytes).  It was introduced in Lustre 1.8 and is mandatory
for all requests in Lustre 2.8 and later.

The 'lm_padding*' fields are reserved for future use.

The array of 'lm_buflens' values has 'lm_bufcount' entries. Each
entry corresponds to, and gives the length in bytes of, one of the
buffers that will follow.  The entire header, and each of the buffers,
is required to be a multiple of eight bytes long to ensure the buffers
are properly aligned to hold __u64 values. Thus there may be an extra
four bytes of padding after the 'lm_buflens' array if that array has
an odd number of entries.