Whamcloud - gitweb
LU-6284 ptlrpc: comment for FLD_QUERY RPC reply swab 09/22309/3
authorFan Yong <fan.yong@intel.com>
Sat, 2 Jul 2016 06:30:08 +0000 (14:30 +0800)
committerOleg Drokin <oleg.drokin@intel.com>
Sat, 10 Sep 2016 03:23:57 +0000 (03:23 +0000)
commit8d8a153e12437900a876293dedc3cc657810ee83
tree6919f316f295b230b574e8cfffef33d4f2bbc22e
parentf2d4419227806850cee36c54c0028dc43ee02b1f
LU-6284 ptlrpc: comment for FLD_QUERY RPC reply swab

The 'fld_read_server' uses 'RMF_GENERIC_DATA' to hold the 'FLD_QUERY'
RPC reply that is composed of 'struct lu_seq_range_array'. But there
is not registered swabber function for 'RMF_GENERIC_DATA'. So the RPC
peers need to handle the RPC reply with fixed little-endian format.

In theory, we can define new structure with some swabber registered
to handle the 'FLD_QUERY' RPC reply result automatically. But from
the implementation view, it is not easy to be done within current
'struct req_msg_field' framework. Because the sequence range array
in the RPC reply is not fixed length, instead, its length depends
on 'lu_seq_range' count, that is unknown when prepare the RPC buffer.
Generally, for such flexible length RPC usage, there will be a field
in the RPC layout to indicate the data length. But for the 'FLD_READ'
RPC, we have no way to do that unless we add new length filed that
will broken the on-wire RPC protocol and cause interoperability
trouble with old peer.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I466a7e229e4ecbb062e6d0f8eea3c6f053ef5e75
Reviewed-on: http://review.whamcloud.com/22309
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
lustre/ptlrpc/layout.c