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

Vladislav Bolkhovitin
2008-12-18T18:33:13Z

Hello linux-mm,

Recently I submitted a new SCSI target framework (SCST) and 4 target
drivers for it for the first iteration of review and comments. See
http://lkml.org/lkml/2008/12/10/245 for details.

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 would like to ask, if the approach used in this patch can be
acceptable from your point of view? I understand, that extending struct
page is a very much undesirable, but, from other side:

- This approach is very simple and straightforward. The patch is only
309 lines long, including comments. All other alternative
implementations would be at least an order of magnitude more complicated.

- Related kernel config option
TCP_ZERO_COPY_TRANSFER_COMPLETION_NOTIFICATION should be disabled by
default in general distro kernels, so the would be no harm at all from
this patch. ISCSI-SCST can work without this patch or with
TCP_ZERO_COPY_TRANSFER_COMPLETION_NOTIFICATION option disabled, although
with user space device handlers it will work considerably worse. Only
few distro kernels users need an iSCSI target and only few among such
users need to use user space device handlers. People who need both iSCSI
target *and* fast working user space device handlers would simply enable
that option and rebuild the kernel. Rejecting this patch provides much
worse alternative: those people would also have to *patch* the kernel at
first, only then enable that option, then rebuild the kernel.

- Although usage of struct page to keep network related pointer might
look as a layering violation, it isn't. I wrote in
http://lkml.org/lkml/2008/12/15/190 why.