struct_lustre_msg.txt

   1 Lustre Message Header
   2 ~~~~~~~~~~~~~~~~~~~~~
   3 [[struct-lustre-msg]]
   4
   5 Every RPC has a header that informs the receiver about the number and
   6 sizes of the buffers to follow. It also holds a few generic pieces of
   7 information about the message.
   8
   9 [source,c]
  10 ----
  11 #define LUSTRE_MSG_MAGIC_V2 0x0BD00BD3
  12 #define MSGHDR_AT_SUPPORT               0x1
  13 struct lustre_msg {
  14         __u32 lm_bufcount;
  15         __u32 lm_secflvr;
  16         __u32 lm_magic;
  17         __u32 lm_repsize;
  18         __u32 lm_cksum;
  19         __u32 lm_flags;
  20         __u32 lm_padding_2;
  21         __u32 lm_padding_3;
  22         __u32 lm_buflens[0];
  23 };
  24 ----
  25
  26 The 'lm_bufcount' field holds the number of buffers that will follow
  27 the header. The header and sequence of buffers constitutes one
  28 message. Each message will always have at least one buffer, and no
  29 message can have more than thirty-one buffers.
  30
  31 The 'lm_secflvr' field gives an indication of whether any sort of
  32 cyptographic encoding of the subsequent buffers will be in force. The
  33 value is zero if there is no "crypto". Otherwise, the value gives a
  34 code identifying the "flavor" of crypto. Further, if crypto is
  35 employed there will only be one buffer following (i.e. 'lm_bufcount' =
  36 1), and that buffer holds an encoding of what would otherwise have
  37 been the sequence of buffers normally following the header.
  38 Cryptography will be discussed in a separate chapter. See
  39 <<security>>.
  40
  41 The 'lm_magic' field is a "magic" value (LUSTRE_MSG_MAGIC_V2 =
  42 0x0BD00BD3, 'OBD' for 'object based device') that is checked in order
  43 to positively identify that the message is intended for the use to
  44 which it is being put. That is, we are indeed dealing with a Lustre
  45 message, and not, for example, corrupted memory or a bad pointer.
  46
  47 The 'lm_repsize' field in a request indicates the maximum available
  48 space that has been reserved for any reply to the request. A reply
  49 that attempts to use more than the reserved space will be discarded.
  50
  51 The 'lm_cksum' field contains a checksum of the 'ptlrpc_body' buffer
  52 to allow the receiver to verify that the message is intact.  This is
  53 used to verify that an 'early reply' has not been overwritten by the
  54 actual reply message.  If the 'MSGHDR_CKSUM_INCOMPAT18' flag is set
  55 (in requests since Lustre 1.8) and the server understands the flag,
  56 then the server will send early reply messages with the appropriate
  57 'lm_cksum'. The 'lm_cksum' is mandatory in Lustre 2.8 and later.
  58
  59 The 'lm_flags' field contains flags that affect the protocol.  The
  60 'MSGHDR_AT_SUPPORT' (0x1) bit indicates that the sender understands
  61 adaptive timeouts and can receive 'early reply' messages.  This flag
  62 was introduced in Lustre 1.6.  The 'MSGHDR_CKSUM_INCOMPAT18' (0x2) bit
  63 indicates that 'lm_cksum' is computed on the full 'ptlrpc_body'
  64 message buffer rather than on the original 'ptlrpc_body_v2' structure
  65 size (88 bytes).  It was introduced in Lustre 1.8 and is mandatory for
  66 all requests in Lustre 2.8 and later.
  67
  68 The 'lm_padding*' fields are reserved for future use.
  69
  70 The array of 'lm_buflens' values has 'lm_bufcount' entries. Each
  71 entry corresponds to, and gives the length in bytes of, one of the
  72 buffers that will follow.  The entire header, and each of the buffers,
  73 is required to be a multiple of eight bytes long to ensure the buffers
  74 are properly aligned to hold __u64 values. Thus there may be an extra
  75 four bytes of padding after the 'lm_buflens' array if that array has
  76 an odd number of entries.
  77