Re: [RFC-V2] [PATCH 0/7] Zero Copy

["Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>]

On 2/6/2011 11:21 PM, Venkateswararao Jujjuri (JV) wrote:
> In this patch series I am trying to take another stab at zero copy. 
> Please review and provide your feedback.

Something went wrong in my scripts and the subject got wrong for all
patches in the series. First patch subject is copied to other patches.
I will respond each patch with correct subject. Sorry for the inconvenience.

- JV

> 
> Goal:
> 
> 9P Linux client makes an additional copy of read/write buffer into the kernel 
> buffer.  There are some transports(especially in the virtualization 
> environment) which can avoid this additional copy by directly sending user 
> buffer to the server.
> 
> Design Goals.
> 
> - Have minimal changes to the net layer so that common code is not polluted by 
>   the transport specifics.
> - Create a common transport library which can be used by other transports.
> - Avoid additional optimizations in the initial attempt (more details below) 
>   and focus on achieving basic functionality. 
> 
> Design
> 
> Send the payload buffers separately to the transport layer if it asks for it.
> Transport layer specifies the preference through newly introduced field in the 
> transport module.  (clnt->trans_mod->pref)
> This method has few advantages.
>    - Keeps the net layer clean and lets the transport layer deal with specifics.
>    - mapping user addr into kernel pages pins the memory. Lack of flow control 
>      make the system vulnerable to denial-of-service attacks. This change gives 
>      transport layer more control to implement effective flow control.
>   - If a transport layer doesn't see the need to handle payload separately, 
>     it can set the preference accordingly so that current code works with no 
>     changes. This is very useful for transports which has no plans of 
>     converting/pinning user pages. Especially things become more complex as 
>     copy_to_user()  is not possible as reads(RREAD) are handled by the
>     transport layer in the interrupt context.
> 
> TREAD/RERROR scenario.
> This is a rather sticky issue to deal with for the !dotl protocol. This is not 
> a problem in 9P2000.L as the error is a known size (errno) but in other 
> protocols it is a string of size (ERRMAX).  To take care of TREAD/RERROR 
> scenario in !dotl we make sure that the read buffer is big enough to 
> accommodate  ERRMAX string. If the read size is small, don't send the payload 
> buffer separately to the transport layer  even if it set its preferences other 
> way (P9_TRANS_PREF_PAYLOAD_SEP).
>   
> For bigger reads, RERROR is handled by copying back user buffers into kernel 
> buffer in the case of error. As this is done only in the error path it should 
> not affect the regular performance.
> 
> Created trans_common.[ch] to house common functions so that other transport 
> layers can take advantage of them.
> 
> msize: One of the major advantage of this patch series is to have bigger msize 
> to pull off bigger read/writes from the server. Increasing the msize is not 
> really a solution as majority of other transactions are extremely small which 
> could result in waste of kernel heap.  To address this problem we need to have 
> two sizes of PDUs. 
> Given that this is an additional optimization/usecase of zero copy..and not a 
> NEED to implement zerocopy itself, I am differing it to next round of changes.
> 
> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
> 
>