On Tue, Apr 17, 2018 at 9:41 AM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > 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? The numbers we presented was on real hardware. If you have any more questions regarding the setup please ask. >> 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
