Re: [PATCH v1 4/4] xprtrdma: Plant XID in on-the-wire RDMA offset (FRWR)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>
>
>



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux