> On Nov 19, 2018, at 12:47 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Mon, Nov 19, 2018 at 10:46 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> Place the associated RPC transaction's XID in the upper 32 bits of >> each RDMA segment's rdma_offset field. These bits are currently >> always zero. >> >> There are two reasons to do this: >> >> - The R_key only has 8 bits that are different from registration to >> registration. The XID adds more uniqueness to each RDMA segment to >> reduce the likelihood of a software bug on the server reading from >> or writing into memory it's not supposed to. >> >> - On-the-wire RDMA Read and Write operations do not otherwise carry >> any identifier that matches them up to an RPC. The XID in the >> upper 32 bits will act as an eye-catcher in network captures. > > Is this just an "eye-catcher" or do you have plans to use it in > wireshark? If the latter, then can we really do that? while a linux > implementation may do that, other (or even possibly future linux) > implementation might not do this. Can we justify changing the > wireshark logic for it? No plans to change the wireshark RPC-over-RDMA dissector. That would only be a valid thing to do if adding the XID were made part of the RPC-over-RDMA protocol via an RFC. -- Chuck Lever
