Re: [RFC]: Support for zero-copy TCP transmit of user space data

Jens Axboe
2008-12-19T19:07:49Z

On Fri, Dec 19 2008, Vladislav Bolkhovitin wrote:
> David M. Lloyd, on 12/18/2008 09:43 PM wrote:
> >On 12/18/2008 12:35 PM, Vladislav Bolkhovitin wrote:
> >>An iSCSI target driver iSCSI-SCST was a part of the patchset
> >>(http://lkml.org/lkml/2008/12/10/293). For it a nice optimization to
> >>have TCP zero-copy transmit of user space data was implemented. Patch,
> >>implementing this optimization was also sent in the patchset, see
> >>http://lkml.org/lkml/2008/12/10/296.
> >
> >I'm probably ignorant of about 90% of the context here, but isn't this the
> >sort of problem that was supposed to have been solved by vmsplice(2)?
>
> No, vmsplice can't help here. ISCSI-SCST is a kernel space driver. But,
> even if it was a user space driver, vmsplice wouldn't change anything
> much. It doesn't have a possibility for a user to know, when
> transmission of the data finished. So, it is intended to be used as:
> vmsplice() buffer -> munmap() the buffer -> mmap() new buffer ->
> vmsplice() it. But on the mmap() stage kernel has to zero all the newly
> mapped pages and zeroing memory isn't much faster, than copying it.
> Hence, there would be no considerable performance increase.

vmsplice() isn't the right choice, but splice() very well could be. You
could easily use splice internally as well. The vmsplice() part sort-of
applies in the sense that you want to fill pages into a pipe, which is
essentially what vmsplice() does. You'd need some helper to do that. And
the ack-on-xmit-done bits is something that splice-to-socket needs
anyway, so I think it'd be quite a suitable choice for this.

--
Jens Axboe