On Tue, Apr 17, 2018 at 09:22:01AM -0400, Olga Kornievskaia wrote: > On Tue, Apr 17, 2018 at 2:52 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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. Christoph said: "I'd like to see numbers for actual, real use cases." Yes, I'd love to see that too. Is it possible to get testing on real hardware that we'd expect people to use, with sufficient details about the setup that someone else could reproduce the results? > 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. > > 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)? I could live with that. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
