From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Xin, Xiaohui" <xiaohui.xin@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>,
"davem@davemloft.net" <davem@davemloft.net>,
"herbert@gondor.hengli.com.au" <herbert@gondor.hengli.com.au>,
"jdike@linux.intel.com" <jdike@linux.intel.com>
Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
Date: Tue, 21 Sep 2010 15:14:22 +0200 [thread overview]
Message-ID: <20100921131421.GA10439@redhat.com> (raw)
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D792B8CAA0F6A@shsmsx502.ccr.corp.intel.com>
On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >Sent: Monday, September 20, 2010 7:37 PM
> >To: Xin, Xiaohui
> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
> >jdike@linux.intel.com
> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
> >
> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
> >> From: Xin Xiaohui <xiaohui.xin@intel.com>
> >>
> >> ---
> >> Michael,
> >> I have move the ioctl to configure the locked memory to vhost
> >
> >It's ok to move this to vhost but vhost does not
> >know how much memory is needed by the backend.
>
> I think the backend here you mean is mp device.
> Actually, the memory needed is related to vq->num to run zero-copy
> smoothly.
> That means mp device did not know it but vhost did.
Well, this might be so if you insist on locking
all posted buffers immediately. However, let's assume I have a
very large ring and prepost a ton of RX buffers:
there's no need to lock all of them directly:
if we have buffers A and B, we can lock A, pass it
to hardware, and when A is consumed unlock A, lock B
and pass it to hardware.
It's not really critical. But note we can always have userspace
tell MP device all it wants to know, after all.
> And the rlimt stuff is per process, we use current pointer to set
> and check the rlimit, the operations should be in the same process.
Well no, the ring is handled from the kernel thread: we switch the mm to
point to the owner task so copy from/to user and friends work, but you
can't access the rlimit etc.
> Now the check operations are in vhost process, as mp_recvmsg() or
> mp_sendmsg() are called by vhost.
Hmm, what do you mean by the check operations?
send/recv are data path operations, they shouldn't
do any checks, should they?
> So set operations should be in
> vhost process too, it's natural.
>
> >So I think we'll need another ioctl in the backend
> >to tell userspace how much memory is needed?
> >
> Except vhost tells it to mp device, mp did not know
> how much memory is needed to run zero-copy smoothly.
> Is userspace interested about the memory mp is needed?
Couldn't parse this last question.
I think userspace generally does want control over
how much memory we'll lock. We should not just lock
as much as we can.
--
MST
next prev parent reply other threads:[~2010-09-21 13:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 9:23 [RFC PATCH v9 00/16] Provide a zero-copy method on KVM virtio-net xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 01/16] Add a new structure for skb buffer from external xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 02/16] Add a new struct for device to manipulate external buffer xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 03/16] Add a ndo_mp_port_prep func to net_device_ops xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 04/16] Add a function make external buffer owner to query capability xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 05/16] Add a function to indicate if device use external buffer xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 06/16] Use callback to deal with skb_release_data() specially xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 07/16] Modify netdev_alloc_page() to get external buffer xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 08/16] Modify netdev_free_page() to release " xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 09/16] Don't do skb recycle, if device use " xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 10/16] Add a hook to intercept external buffers from NIC driver xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 11/16] Add header file for mp device xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 13/16] Add a kconfig entry and make entry " xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 12/16] Add mp(mediate passthru) device xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 14/16] Provides multiple submits and asynchronous notifications xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 15/16] An example how to modifiy NIC driver to use napi_gro_frags() interface xiaohui.xin
2010-08-06 9:23 ` [RFC PATCH v9 16/16] An example how to alloc user buffer based on " xiaohui.xin
2010-09-06 11:11 ` [RFC PATCH v9 12/16] Add mp(mediate passthru) device Michael S. Tsirkin
2010-09-10 13:40 ` Xin, Xiaohui
2010-09-11 7:41 ` Xin, Xiaohui
2010-09-12 13:37 ` Michael S. Tsirkin
2010-09-15 3:13 ` Xin, Xiaohui
2010-09-15 11:28 ` Michael S. Tsirkin
2010-09-17 3:16 ` Xin, Xiaohui
2010-09-20 8:08 ` xiaohui.xin
2010-09-20 11:36 ` Michael S. Tsirkin
2010-09-21 1:39 ` Xin, Xiaohui
2010-09-21 13:14 ` Michael S. Tsirkin [this message]
2010-09-22 11:41 ` Xin, Xiaohui
2010-09-22 11:55 ` Michael S. Tsirkin
2010-09-23 12:56 ` Xin, Xiaohui
2010-09-26 11:50 ` Michael S. Tsirkin
2010-09-27 0:42 ` Xin, Xiaohui
2010-09-11 9:42 ` Xin, Xiaohui
2010-08-11 1:23 ` [RFC PATCH v9 00/16] Provide a zero-copy method on KVM virtio-net Shirley Ma
2010-08-11 1:43 ` Shirley Ma
2010-08-11 6:01 ` Shirley Ma
2010-08-11 6:55 ` Shirley Ma
2010-09-03 10:52 ` Michael S. Tsirkin
2010-09-13 18:48 ` Shirley Ma
2010-09-13 21:35 ` Shirley Ma
2010-09-03 10:14 ` Michael S. Tsirkin
2010-09-03 20:29 ` Sridhar Samudrala
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=20100921131421.GA10439@redhat.com \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.hengli.com.au \
--cc=jdike@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=xiaohui.xin@intel.com \
/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).