Re: [PATCH v8 0/9] NFSD support for async COPY

[Steve Dickson <SteveD@RedHat.com>]

On 04/17/2018 09:22 AM, Olga Kornievskaia wrote:
> On Tue, Apr 17, 2018 at 2:52 AM, Christoph Hellwig <hch@infradead.org> wrote:
>> On Mon, Apr 16, 2018 at 05:45:22PM -0400, J. Bruce Fields wrote:
>>> On Sat, Apr 14, 2018 at 12:22:02AM -0700, Christoph Hellwig wrote:
>>>> What is the use case for adding all these crazy complications?
>>>
>>> Is there anything specific that you think is too complicated?
>>
>> It is a lot of complexity for little gain.
>>
>>> I know you don't think server-to-server copy offload is worth the
>>> trouble, but I haven't seen you actually explain why (beyond just that
>>> it's more complicated).
>>
>> I'd like to see numbers for actual, real use cases.  Note that this
>> series doesn't seem to include inter-server support, so this is locally
>> only, and I'd like to see why we want to support this over the simpler
>> and better performing CLONE op.
>>
>> Also even if we have a good reason to add it I absolutely want a config
>> option for the feature - it is a lot code adding potential attack
>> vectors, so we should not just enabled it by default.
>>
>>> Is there some reason you think it won't actually be useful?
>>
>> Lets start with explaining why it would actually be useful and benefit
>> Linux users.
> 
> This is performance improvement feature. Why do you keep asking about
> benefits? Besides my employer I had other companies chime in on this
> mailing list that they are interested in the copy offload feature
> therefore this work is being done.
+1 I guess I don't see why people would object to a performance
improvement... Do you?

> 
> Yes this series only introduced asynchronous copy offload because the
> concern was that doing "inter"+asynchronous was too much to review and
> therefore it is being done in parts.
Which is a solid plan... IMHO... But the bottom line is this... 

A decision needs to be made... Either accept these patches/concept or don't!
This discussion has been going on quite a while now... If this
performance improvement is not something the community wants
so be bit.. Make the call... so we can move on... 
 
> 
> I have no objections to having a configuration option for this
> feature. It would be up to the Linux distributions to "make is a
> default". Bruce/Anna/Trond, do you want this code to be ifdef-ed under
> a config option(s) (one for the client and one for the server)?
Way is this needed? Why wouldn't users want a performance gain on
by default??

steved.