On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <[email protected]> wrote:
> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <[email protected]> wrote:
>>
>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
>>>
>>> Hi-
>>>
>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
>>> the Linux kernel. So far we've built and run functional tests to determine
>>> what is working and what is broken.
>>>
>>> [snip]
>
>
>>>
>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
>>> All HCAs support this mode.
>>
>>
>> Not safe is an understatement. It exposes all of client physical
>> memory to the peer, for both read and write. A simple pointer error
>> on the server will silently corrupt the client. This mode was
>> intended only for testing, and in experimental deployments.
(sorry, resend .. previous reply bounced back due to gmail html format)
Please keep "ALLPHYSICAL" for now - as our embedded system needs it.
Thanks,
Wendy
Hi Wendy-
On Feb 28, 2014, at 5:26 PM, Wendy Cheng <[email protected]> wrote:
> On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <[email protected]> wrote:
>> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <[email protected]> wrote:
>>>
>>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
>>>>
>>>> Hi-
>>>>
>>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
>>>> the Linux kernel. So far we've built and run functional tests to determine
>>>> what is working and what is broken.
>>>>
>>>> [snip]
>>
>>
>>>>
>>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
>>>> All HCAs support this mode.
>>>
>>>
>>> Not safe is an understatement. It exposes all of client physical
>>> memory to the peer, for both read and write. A simple pointer error
>>> on the server will silently corrupt the client. This mode was
>>> intended only for testing, and in experimental deployments.
>
> (sorry, resend .. previous reply bounced back due to gmail html format)
>
> Please keep "ALLPHYSICAL" for now - as our embedded system needs it.
This is just the client side. Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
Do you have plans to move to a mode that is less risky? If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code? Do you have any bug fixes you?d like to merge upstream?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Hi Chuck,
I have a patch for the server side that simplifies the memory registration
and fixes a bug where the server ignores the FRMR hardware limits. This
bug is actually upstream now.
I have been sitting on it because it's a big patch and will require a lot
of testing/review to get it upstream. This is Just an FYI in case there is
someone on your team who has the bandwidth to take this work and finish it up.
Thanks,
Tom
On 2/28/14 8:59 PM, Chuck Lever wrote:
> Hi Wendy-
>
> On Feb 28, 2014, at 5:26 PM, Wendy Cheng <[email protected]> wrote:
>
>> On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <[email protected]> wrote:
>>> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <[email protected]> wrote:
>>>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
>>>>> Hi-
>>>>>
>>>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
>>>>> the Linux kernel. So far we've built and run functional tests to determine
>>>>> what is working and what is broken.
>>>>>
>>>>> [snip]
>>>
>>>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
>>>>> All HCAs support this mode.
>>>>
>>>> Not safe is an understatement. It exposes all of client physical
>>>> memory to the peer, for both read and write. A simple pointer error
>>>> on the server will silently corrupt the client. This mode was
>>>> intended only for testing, and in experimental deployments.
>> (sorry, resend .. previous reply bounced back due to gmail html format)
>>
>> Please keep "ALLPHYSICAL" for now - as our embedded system needs it.
> This is just the client side. Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
>
> Do you have plans to move to a mode that is less risky? If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code? Do you have any bug fixes you?d like to merge upstream?
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mar 1, 2014, at 4:29 PM, Tom Tucker <[email protected]> wrote:
> Hi Chuck,
>
> I have a patch for the server side that simplifies the memory registration and fixes a bug where the server ignores the FRMR hardware limits. This bug is actually upstream now.
>
> I have been sitting on it because it's a big patch and will require a lot of testing/review to get it upstream. This is Just an FYI in case there is someone on your team who has the bandwidth to take this work and finish it up.
Why not post what you have, and then we can see what can be done.
>
> Thanks,
> Tom
>
> On 2/28/14 8:59 PM, Chuck Lever wrote:
>> Hi Wendy-
>>
>> On Feb 28, 2014, at 5:26 PM, Wendy Cheng <[email protected]> wrote:
>>
>>> On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <[email protected]> wrote:
>>>> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <[email protected]> wrote:
>>>>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
>>>>>> Hi-
>>>>>>
>>>>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
>>>>>> the Linux kernel. So far we've built and run functional tests to determine
>>>>>> what is working and what is broken.
>>>>>>
>>>>>> [snip]
>>>>
>>>>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
>>>>>> All HCAs support this mode.
>>>>>
>>>>> Not safe is an understatement. It exposes all of client physical
>>>>> memory to the peer, for both read and write. A simple pointer error
>>>>> on the server will silently corrupt the client. This mode was
>>>>> intended only for testing, and in experimental deployments.
>>> (sorry, resend .. previous reply bounced back due to gmail html format)
>>>
>>> Please keep "ALLPHYSICAL" for now - as our embedded system needs it.
>> This is just the client side. Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
>>
>> Do you have plans to move to a mode that is less risky? If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code? Do you have any bug fixes you?d like to merge upstream?
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Fri, 28 Feb 2014 21:59:00 -0500
Chuck Lever <[email protected]> wrote:
> Hi Wendy-
>
> On Feb 28, 2014, at 5:26 PM, Wendy Cheng <[email protected]> wrote:
>
> > On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <[email protected]> wrote:
> >> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <[email protected]> wrote:
> >>>
> >>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
> >>>>
> >>>> Hi-
> >>>>
> >>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
> >>>> the Linux kernel. So far we've built and run functional tests to determine
> >>>> what is working and what is broken.
> >>>>
> >>>> [snip]
> >>
> >>
> >>>>
> >>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
> >>>> All HCAs support this mode.
> >>>
> >>>
> >>> Not safe is an understatement. It exposes all of client physical
> >>> memory to the peer, for both read and write. A simple pointer error
> >>> on the server will silently corrupt the client. This mode was
> >>> intended only for testing, and in experimental deployments.
> >
> > (sorry, resend .. previous reply bounced back due to gmail html format)
> >
> > Please keep "ALLPHYSICAL" for now - as our embedded system needs it.
>
> This is just the client side. Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
>
> Do you have plans to move to a mode that is less risky? If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code? Do you have any bug fixes you?d like to merge upstream?
>
Also, given that ALLPHYSICAL isn't considered safe, we should at the
very least require some sort of explicit opt-in before allowing it to be
used. Perhaps either a Kconfig option, or maybe a runtime switch like a
module parm?
Wendy, would that be acceptable?
--
Jeff Layton <[email protected]>