https://bugs.kde.org/show_bug.cgi?id=291835
--- Comment #43 from oli...@openbrackets.net <oli...@openbrackets.net> --- @Mark one more thought... if 1. above is OK, ie smbclient / smbc_read|write can support and FD streaming approach, then, eventhough we are getting rid of the problem of determining buffer size, is that going to solve the throughput issue? I don't understand the problem in great detail yet, but it seems to me that because of the way the SMB protocol works, the way the libsmbclient API needs to be called and fed data, is quite critical, ref https://bugs.kde.org/show_bug.cgi?id=291835#c26 where wireshark forensics show that smbclient/cifs use clever strategy of pre-fetching "one block ahead" to get max throughput... How can sendfile / splice ever understand these semantics? Would we be getting rid of the "deciding what size buffer to use" problem, while failing to address the actual problem of achieving highly optimised throughput...? -- You are receiving this mail because: You are watching all bug changes.
