Received: by 10.192.165.148 with SMTP id m20csp4050977imm; Mon, 23 Apr 2018 18:06:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx485G6wkuTk3JwOUbkzVefdIjhEKU6Uj/Absq7LrJJ7KZ572d120+LSZcvXjR2OGMfUy6WxS X-Received: by 2002:a17:902:b2c7:: with SMTP id x7-v6mr23065227plw.124.1524532007478; Mon, 23 Apr 2018 18:06:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524532007; cv=none; d=google.com; s=arc-20160816; b=aaWl9ogXE/eKfdxESvlT7R6HTrH2DYuZBzhUTn1bdKzNFoMNMtPDR1/rdCnj/7UIzK 5747Pn20OuQPb8yBiO+cC/+SfxLdWjZI88mPWvf3Bqwt8yl3ozinOTFl7X8HJH3ByznH wl2yo0fXn9EERBGvgdCUnTPzSqW22YgH4l55jIns4InolFlNIHf1XlzYSan3INKUGaRX kaxkgzitH2lu+a/h4fm/rsQGVjzgjjfoqDhyB/86pm9ir2ZyrfNF5UWDSCNSo+xGAuoP 43md4Gdv8RrsN7uCxMvLKnGKSeNg1iANIxtuYnrC1ZcA1FycDAll2dlV2KRIVwCNMstO Vmxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=7E9sANP+q2us/cUR6OfF/QKsTfQy9nV32HaKeKZMY74=; b=JBmTQjJxB0pdE21QWEL11UYBktozCUaxzpkNpXTqnjSCjelHRnkcm9lCrwz3q5qtVc kZoLw3w8IISDcF1ibvbCDH9Lb2qDBP+v/oZGiyNyzbfFTKaqexE+U/EW77osX8f9ydRs 0vyLvqvi37WD7WyrslJhy1HFw3na3lSeaPiANMSaGhrBTExONxoX8a5wGbT/JkU1XuJz ISgs/oEIcPeztMBQnpzCAhGvNZCICMj5buH3ccP95uh8AyWH/HbIcIM4uBdGWSsilbv3 UlW/S5PXU7p4CY/ID1uqJiPPzLbSmXj4cDvIgwv/Ssf/20rkE2YxXDD/euWhZPIw5bOk 4TAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e5si11912289pfi.67.2018.04.23.18.06.32; Mon, 23 Apr 2018 18:06:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932737AbeDXBFO (ORCPT + 99 others); Mon, 23 Apr 2018 21:05:14 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:47074 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932652AbeDXBFL (ORCPT ); Mon, 23 Apr 2018 21:05:11 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ADC0F4075A82; Tue, 24 Apr 2018 01:05:10 +0000 (UTC) Received: from redhat.com (ovpn-123-116.rdu2.redhat.com [10.10.123.116]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5E0441C703; Tue, 24 Apr 2018 01:05:07 +0000 (UTC) Date: Tue, 24 Apr 2018 04:05:07 +0300 From: "Michael S. Tsirkin" To: Jason Wang Cc: Tiwei Bie , wexu@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, jfreimann@redhat.com Subject: Re: [RFC v2] virtio: support packed ring Message-ID: <20180424040258-mutt-send-email-mst@kernel.org> References: <20180401141216.8969-1-tiwei.bie@intel.com> <515e635b-bc80-9b8d-72f9-b390ae5103ec@redhat.com> <20180423092908.77rii3gi7dcaf7o6@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 24 Apr 2018 01:05:10 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 24 Apr 2018 01:05:10 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 24, 2018 at 08:54:52AM +0800, Jason Wang wrote: > > > On 2018年04月23日 17:29, Tiwei Bie wrote: > > On Mon, Apr 23, 2018 at 01:42:14PM +0800, Jason Wang wrote: > > > On 2018年04月01日 22:12, Tiwei Bie wrote: > > > > Hello everyone, > > > > > > > > This RFC implements packed ring support for virtio driver. > > > > > > > > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented > > > > by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html > > > > Minor changes are needed for the vhost code, e.g. to kick the guest. > > > > > > > > TODO: > > > > - Refinements and bug fixes; > > > > - Split into small patches; > > > > - Test indirect descriptor support; > > > > - Test/fix event suppression support; > > > > - Test devices other than net; > > > > > > > > RFC v1 -> RFC v2: > > > > - Add indirect descriptor support - compile test only; > > > > - Add event suppression supprt - compile test only; > > > > - Move vring_packed_init() out of uapi (Jason, MST); > > > > - Merge two loops into one in virtqueue_add_packed() (Jason); > > > > - Split vring_unmap_one() for packed ring and split ring (Jason); > > > > - Avoid using '%' operator (Jason); > > > > - Rename free_head -> next_avail_idx (Jason); > > > > - Add comments for virtio_wmb() in virtqueue_add_packed() (Jason); > > > > - Some other refinements and bug fixes; > > > > > > > > Thanks! > > > > > > > > Signed-off-by: Tiwei Bie > > > > --- > > > > drivers/virtio/virtio_ring.c | 1094 +++++++++++++++++++++++++++++------- > > > > include/linux/virtio_ring.h | 8 +- > > > > include/uapi/linux/virtio_config.h | 12 +- > > > > include/uapi/linux/virtio_ring.h | 61 ++ > > > > 4 files changed, 980 insertions(+), 195 deletions(-) > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > index 71458f493cf8..0515dca34d77 100644 > > > > --- a/drivers/virtio/virtio_ring.c > > > > +++ b/drivers/virtio/virtio_ring.c > > > > @@ -58,14 +58,15 @@ > > > [...] > > > > > > > + > > > > + if (vq->indirect) { > > > > + u32 len; > > > > + > > > > + desc = vq->desc_state[head].indir_desc; > > > > + /* Free the indirect table, if any, now that it's unmapped. */ > > > > + if (!desc) > > > > + goto out; > > > > + > > > > + len = virtio32_to_cpu(vq->vq.vdev, > > > > + vq->vring_packed.desc[head].len); > > > > + > > > > + BUG_ON(!(vq->vring_packed.desc[head].flags & > > > > + cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_INDIRECT))); > > > It looks to me spec does not force to keep VRING_DESC_F_INDIRECT here. So we > > > can safely remove this BUG_ON() here. > > > > > > > + BUG_ON(len == 0 || len % sizeof(struct vring_packed_desc)); > > > Len could be ignored for used descriptor according to the spec, so we need > > > remove this BUG_ON() too. > > Yeah, you're right! The BUG_ON() isn't right. I'll remove it. > > And I think something related to this in the spec isn't very > > clear currently. > > > > In the spec, there are below words: > > > > https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L272 > > """ > > In descriptors with VIRTQ_DESC_F_INDIRECT set VIRTQ_DESC_F_WRITE > > is reserved and is ignored by the device. > > """ > > > > So when device writes back an used descriptor in this case, > > device may not set the VIRTQ_DESC_F_WRITE flag as the flag > > is reserved and should be ignored. > > > > https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L170 > > """ > > Element Length is reserved for used descriptors without the > > VIRTQ_DESC_F_WRITE flag, and is ignored by drivers. > > """ > > > > And this is the way how driver ignores the `len` in an used > > descriptor. > > > > https://github.com/oasis-tcs/virtio-spec/blob/d4fec517dfcf/packed-ring.tex#L241 > > """ > > To increase ring capacity the driver can store a (read-only > > by the device) table of indirect descriptors anywhere in memory, > > and insert a descriptor in the main virtqueue (with \field{Flags} > > bit VIRTQ_DESC_F_INDIRECT on) that refers to a buffer element > > containing this indirect descriptor table; > > """ > > > > So the indirect descriptors in the table are read-only by > > the device. And the only descriptor which is writeable by > > the device is the descriptor in the main virtqueue (with > > Flags bit VIRTQ_DESC_F_INDIRECT on). So if we ignore the > > `len` in this descriptor, we won't be able to get the > > length of the data written by the device. > > > > So I think the `len` in this descriptor will carry the > > length of the data written by the device (if the buffers > > are writable to the device) even if the VIRTQ_DESC_F_WRITE > > isn't set by the device. How do you think? > > Yes I think so. But we'd better need clarification from Michael. I think if you use a descriptor, and you want to supply len to guest, you set VIRTQ_DESC_F_WRITE in the used descriptor. Spec also says you must not set VIRTQ_DESC_F_INDIRECT then. If that's a problem we could look at relaxing that last requirement - does driver want INDIRECT in used descriptor to match the value in the avail descriptor for some reason? > > > > > > > The reason is we don't touch descriptor ring in the case of split, so > > > BUG_ON()s may help there. > > > > > > > + > > > > + for (j = 0; j < len / sizeof(struct vring_packed_desc); j++) > > > > + vring_unmap_one_packed(vq, &desc[j]); > > > > + > > > > + kfree(desc); > > > > + vq->desc_state[head].indir_desc = NULL; > > > > + } else if (ctx) { > > > > + *ctx = vq->desc_state[head].indir_desc; > > > > + } > > > > + > > > > +out: > > > > + return vq->desc_state[head].num; > > > > +} > > > > + > > > > +static inline bool more_used_split(const struct vring_virtqueue *vq) > > > > { > > > > return vq->last_used_idx != virtio16_to_cpu(vq->vq.vdev, vq->vring.used->idx); > > > > } > > > > +static inline bool more_used_packed(const struct vring_virtqueue *vq) > > > > +{ > > > > + u16 last_used, flags; > > > > + bool avail, used; > > > > + > > > > + if (vq->vq.num_free == vq->vring_packed.num) > > > > + return false; > > > > + > > > > + last_used = vq->last_used_idx; > > > > + flags = virtio16_to_cpu(vq->vq.vdev, > > > > + vq->vring_packed.desc[last_used].flags); > > > > + avail = flags & VRING_DESC_F_AVAIL(1); > > > > + used = flags & VRING_DESC_F_USED(1); > > > > + > > > > + return avail == used; > > > > +} > > > This looks interesting, spec said: > > > > > > " > > > Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different for an > > > available descriptor and > > > equal for a used descriptor. > > > Note that this observation is mostly useful for sanity-checking as these are > > > necessary but not sufficient > > > conditions - for example, all descriptors are zero-initialized. To detect > > > used and available descriptors it is > > > possible for drivers and devices to keep track of the last observed value of > > > VIRTQ_DESC_F_USED/VIRTQ_- > > > DESC_F_AVAIL. Other techniques to detect > > > VIRTQ_DESC_F_AVAIL/VIRTQ_DESC_F_USED bit changes > > > might also be possible. > > > " > > > > > > So it looks to me it was not sufficient, looking at the example codes in > > > spec, do we need to track last seen used_wrap_counter here? > > I don't think we have to track used_wrap_counter in > > driver. There was a discussion on this: > > > > https://lists.oasis-open.org/archives/virtio-dev/201802/msg00177.html > > > > And after that, below sentence was added (it's also > > in the above words you quoted): > > > > """ > > Other techniques to detect > > VIRTQ_DESC_F_AVAIL/VIRTQ_DESC_F_USED bit changes > > might also be possible. > > """ > > > > Best regards, > > Tiwei Bie > > I see, the extra condition "if (vq->vq.num_free == vq->vring_packed.num)" > help in this case. > > Thanks I still think tracking a wrap counter is better. > > > > > Thanks