From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43948)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@cloudius-systems.com>) id 1XbqTn-0001vU-3u
	for qemu-devel@nongnu.org; Wed, 08 Oct 2014 08:36:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@cloudius-systems.com>) id 1XbqTf-0004Lh-8y
	for qemu-devel@nongnu.org; Wed, 08 Oct 2014 08:36:30 -0400
Received: from mail-wg0-f51.google.com ([74.125.82.51]:65407)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@cloudius-systems.com>) id 1XbqTf-0004Ld-2I
	for qemu-devel@nongnu.org; Wed, 08 Oct 2014 08:36:23 -0400
Received: by mail-wg0-f51.google.com with SMTP id b13so11435069wgh.10
	for <qemu-devel@nongnu.org>; Wed, 08 Oct 2014 05:36:22 -0700 (PDT)
Message-ID: <54352FC2.5080505@cloudius-systems.com>
Date: Wed, 08 Oct 2014 15:36:18 +0300
From: Avi Kivity <avi@cloudius-systems.com>
MIME-Version: 1.0
References: <542A6B70.7090607@huawei.com> <20140930093356.GA3673@redhat.com>
	<5434EB0B.8010800@cloudius-systems.com>
	<20141008091547.GB3872@redhat.com>
	<54350919.8050401@cloudius-systems.com>
	<20141008101443.GA4291@redhat.com>
	<543513E5.8010507@cloudius-systems.com>
	<20141008105515.GA4429@redhat.com>
	<54351901.6050706@cloudius-systems.com>
	<20141008122213.GA4679@redhat.com>
	<54352E09.9050303@cloudius-systems.com>
In-Reply-To: <54352E09.9050303@cloudius-systems.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [QA-virtio]:Why vring size is limited to 1024?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
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


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.