On Mon, Nov 19, 2018 at 12:59 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > 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. Agreed. Can you also help me understand the proposal (as I'm still trying to figure why it is useful). You are proposing to modify the RDMA segments's RDMA offset field (I see top 6bits are indeed always 0). I don't see how adding that helps an RDMA read/write message which does not have an "offset" field in it be matched to a particular RPC. I don't believe we have (had) any issues matching the initial RC Send only that contains the RDMA_MSG to the RPC. > > > -- > Chuck Lever > > >
