All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.