From: Avi Kivity <avi@cloudius-systems.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, liuyongan@huawei.com,
qinchuanyu@huawei.com, "Zhangjie (HZ)" <zhangjie14@huawei.com>,
akong@redhat.com
Subject: Re: [Qemu-devel] [QA-virtio]:Why vring size is limited to 1024?
Date: Wed, 08 Oct 2014 15:36:18 +0300 [thread overview]
Message-ID: <54352FC2.5080505@cloudius-systems.com> (raw)
In-Reply-To: <54352E09.9050303@cloudius-systems.com>
On 10/08/2014 03:28 PM, Avi Kivity wrote:
> My old presentation from 2012 or so suggested something like this.
>> We don't need a 64 bit cookie I think - a small 16 bit one
>> should be enough.
>>
>
> A 16 bit cookie means you need an extra table to hold the real request
> pointers.
>
> With a 64-bit cookie you can store a pointer to the skbuff or bio in
> the ring itself, and avoid the extra lookup.
>
> The extra lookup isn't the end of the world, since doesn't cross core
> boundaries, but it's worth avoiding.
>
What you can do is have two types of descriptors: head and fragment
union desc {
struct head {
u16 nfrags
u16 flags
u64 cookie
}
struct frag {
u64 paddr
u16 flen
u16 flags
}
}
so now a request length is 12*(nfrags+1).
You can be evil and steal some bits from paddr/cookie, and have each
descriptor 8 bytes long.
btw, I also recommend storing things like vnet_hdr in the ring itself,
instead of out-of-line in memory. Maybe the ring should just transport
bytes and let the upper layer decide how it's formatted.
next prev parent reply other threads:[~2014-10-08 12:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 8:36 [Qemu-devel] [QA-virtio]:Why vring size is limited to 1024? Zhangjie (HZ)
2014-09-30 9:33 ` Michael S. Tsirkin
2014-10-08 7:17 ` Zhangjie (HZ)
2014-10-08 7:37 ` Michael S. Tsirkin
2014-10-08 8:07 ` Zhangjie (HZ)
2014-10-08 9:13 ` Michael S. Tsirkin
2014-10-08 7:43 ` Avi Kivity
2014-10-08 8:26 ` Zhangjie (HZ)
2014-10-08 9:15 ` Michael S. Tsirkin
2014-10-08 9:51 ` Avi Kivity
2014-10-08 10:14 ` Michael S. Tsirkin
2014-10-08 10:37 ` Avi Kivity
2014-10-08 10:55 ` Michael S. Tsirkin
2014-10-08 10:59 ` Avi Kivity
2014-10-08 12:22 ` Michael S. Tsirkin
2014-10-08 12:28 ` Avi Kivity
2014-10-08 12:36 ` Avi Kivity [this message]
2014-10-08 11:00 ` Avi Kivity
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=54352FC2.5080505@cloudius-systems.com \
--to=avi@cloudius-systems.com \
--cc=akong@redhat.com \
--cc=jasowang@redhat.com \
--cc=liuyongan@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qinchuanyu@huawei.com \
--cc=zhangjie14@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.