linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: v9fs-developer@lists.sourceforge.net
Cc: linux-fsdevel@vger.kernel.org,
	Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
Subject: [RFC-V3] [net/9p] [PATCH 0/7] Zero Copy
Date: Thu, 10 Feb 2011 17:25:04 -0800	[thread overview]
Message-ID: <1297387511-2697-1-git-send-email-jvrao@linux.vnet.ibm.com> (raw)

Changes from V2
---------------
o Format and variable corrections/changes
o Logic to determine nr_pages
o Added logic to avoid additional malloc to place mapped sglist.
o Don't attempt zero copy for small IO (<1024)
o Rearranged code.

In this patch series I am trying to take another stab at zero copy.
Please review and provide your feedback.

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>



             reply	other threads:[~2011-02-11  0:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11  1:25 Venkateswararao Jujjuri (JV) [this message]
2011-02-11  1:25 ` [RFC-V3 1/7] [net/9p] Additional elements to p9_fcall to acoomodate zero copy Venkateswararao Jujjuri (JV)
2011-02-11  1:25 ` [RFC-V3 2/7] [net/9p] Adds supporting functions for " Venkateswararao Jujjuri (JV)
2011-02-11  1:25 ` [RFC-V3 3/7] [net/9p] Assign type of transaction to tc->pdu->id which is otherwise unsed Venkateswararao Jujjuri (JV)
2011-02-11  6:59   ` Aneesh Kumar K. V
2011-02-11  1:25 ` [RFC-V3 4/7] [net/9p] Add gup/zero_copy support to VirtIO transport layer Venkateswararao Jujjuri (JV)
2011-02-11  7:07   ` Aneesh Kumar K. V
2011-02-11 16:08     ` Venkateswararao Jujjuri (JV)
2011-02-11 17:58   ` Aneesh Kumar K. V
2011-02-11 18:42     ` Venkateswararao Jujjuri (JV)
2011-02-11  1:25 ` [RFC-V3 5/7] [net/9p] Add preferences to " Venkateswararao Jujjuri (JV)
2011-02-11  1:25 ` [RFC-V3 6/7] [net/9p] Read and Write side zerocopy changes for 9P2000.L protocol Venkateswararao Jujjuri (JV)
2011-02-11 19:35   ` Aneesh Kumar K. V
2011-02-11 21:03     ` Venkateswararao Jujjuri (JV)
2011-02-11  1:25 ` [RFC-V3 7/7] [net/9p] Handle TREAD/RERROR case in !dotl case Venkateswararao Jujjuri (JV)
2011-02-11 18:10   ` Aneesh Kumar K. V
2011-02-11 18:46     ` Venkateswararao Jujjuri (JV)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1297387511-2697-1-git-send-email-jvrao@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).