DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C24C020870
Subject: Re: [PATCH v1 4/4] xprtrdma: Plant XID in on-the-wire RDMA offset
 (FRWR)
To:     Jason Gunthorpe <jgg@ziepe.ca>
Cc:     "Mora, Jorge" <Jorge.Mora@netapp.com>,
        Chuck Lever <chuck.lever@oracle.com>,
        Olga Kornievskaia <aglo@umich.edu>,
        linux-rdma <linux-rdma@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
References: <4A94F1A9-96A4-4A2F-8617-AF0E2380D0C1@oracle.com>
 <CAN-5tyGU85PJe4Uoocw5NkT8YiYSF8wTWTgg4HycAgKpyHSfiw@mail.gmail.com>
 <9BD3F7C9-96BF-4555-A901-5E82E2CF9E28@oracle.com>
 <CAN-5tyELSi-Vtf1W3CSFzynbgVW7rcyJnfHmcb6Ehs0NEUiy4A@mail.gmail.com>
 <4EE34B64-0BEB-439A-B2A2-D77673D4CF70@oracle.com>
 <5EA42399-05C2-40D3-A5CA-7B40971AEC33@netapp.com>
 <20181119224615.GM4890@ziepe.ca>
 <d6e65bdf-6cdd-1a23-36de-71aeb57a22e0@talpey.com>
 <20181120030916.GQ4890@ziepe.ca>
 <8fd325fa-290a-6381-80d8-e6ac20acffe8@talpey.com>
 <20181120033218.GS4890@ziepe.ca>
From:   Tom Talpey <tom@talpey.com>
Message-ID: <107378fb-669d-80b7-efb2-84694367ce9c@talpey.com>
Date:   Mon, 19 Nov 2018 22:38:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181120033218.GS4890@ziepe.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On 11/19/2018 10:32 PM, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 10:25:37PM -0500, Tom Talpey wrote:
> 
>> Absolutely, but if the offset walks into the high-order invariant bits,
>> they won't be invariant any longer. It would still work, but it would
>> defeat the wireshark trick that Chuck wants to play.
> 
> Sure, OK, if you care about the bits being invarient, and not simply
> randomized :)

Well, that was Chuck's proposal, to use the XID. SMB Direct originally
used a formula, then changed to randomized, and in future will likely
change it again. The point is, it's the RDMA consumer's choice, not a
verb, or adapter, or protocol, requirement.


>>> For many adaptors that means PAGE_SIZE or huge
>>> page size level alignment..
>>
>> I'm not sure I understand this. The FRWR hides the native page size, by
>> providing the page frames in the local work request. Their size isn't
>> known to the protocol.
> 
> Ah, some HW has limitations in how it can construct a VA. In many
> implementation the low order bits of the VA must match the offset into
> the page. If the page is 4K that is 12 bits, if it is 2M that is 21
> bits..
> 
> So there should be restrictions on what start VA can be assigned to a
> FRWR.

I think only the FBO (First Byte Offset) is really restricted. But
indeed yes, the number of possible FBO bits is a function of the page 
size. So, if so, we agree - ok.

Tom.