Received: by 10.192.165.148 with SMTP id m20csp1403783imm; Fri, 27 Apr 2018 19:47:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpWWq2a6cnO4bPAb3+LbBRBvQV7mfqs4yi/bdN1msitiYztdWjWoXifjfus2lL83bEvyf+O X-Received: by 2002:a63:a704:: with SMTP id d4-v6mr4016611pgf.324.1524883640688; Fri, 27 Apr 2018 19:47:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524883640; cv=none; d=google.com; s=arc-20160816; b=vxIanOlGvWT3rQ2w21cmBb1ueu3ilkaXaRnFiHibufz3JedGoYk0ymAkz9N85toEOJ zRibmkTJPwq5Q976KG2LU+TX/XZ5jbEaiOu74zScRfxQWdnXjxDTSTuq3tZcqjgHtLVR 29by8lK9gT+s2PcarqT2IwB0E3uOUoeMYCzP+ffpuzQBMpWnT//j6a/DrjpFQUnBm9QM WRwQca73LS/tSfqBkNgOUK3E+lUPSnGaLIo9k6yusVhgAd83WG0+XsZkZytP223t4EPG 5Qb/St47LsKHO/qtafgIaVcNpMMWENeEggF1Plkh5PZsQEOKKbPpL9GwtLRBNSZv+j13 w/AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=MCpuyhyVq8Davm6xKYFcUApnTOu7+1l3Gm+1YIEHYxg=; b=EW+3ytfHWUP/zeSHZErbuQ1XcYUwr5JxlBYZmmYy835DeqlJIlMUAgJetktKe3HBvX pTe5sHKHOcucylf4WmQhxzflJwRcNtbbHJZ5r3DO2cml2Mi/prm6D2K1wTwGpCyV6uB8 Au69Wipbk8ReFUGEc62F6lUzy5pGSMr0Y0QaYunpECf5KjiVJsSJ/tXTJvheXwuCAUp3 DmrNDoxCpSpKiP32YNyzkiiy8PI8+rqdwPXO33b0dfHSYId/TpKZrnn171a/xyAspZEp WJMs9o5LNWdXdodLa0XOgoIfSWjO8w6p4ZZkD0WI2heKU5iOnYygqTaaHxI1o7NZ2uWX BahQ== 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 i65si2646260pfb.343.2018.04.27.19.47.05; Fri, 27 Apr 2018 19:47:20 -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 S1759525AbeD1CqA (ORCPT + 99 others); Fri, 27 Apr 2018 22:46:00 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759215AbeD1Cp7 (ORCPT ); Fri, 27 Apr 2018 22:45:59 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8C5F98182D2E; Sat, 28 Apr 2018 02:45:58 +0000 (UTC) Received: from [10.72.12.171] (ovpn-12-171.pek2.redhat.com [10.72.12.171]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5424A2026985; Sat, 28 Apr 2018 02:45:54 +0000 (UTC) Subject: Re: [RFC v3 0/5] virtio: support packed ring To: Tiwei Bie Cc: "Michael S. Tsirkin" , virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, wexu@redhat.com, jfreimann@redhat.com References: <20180425051550.24342-1-tiwei.bie@intel.com> <5ad1ca01-1e5c-7105-f303-7e8d42f6a068@redhat.com> <20180427071725-mutt-send-email-mst@kernel.org> <5c712aa2-f00e-b472-cdfc-48175aea790d@redhat.com> <20180427091234.n6vr3wcnbnqxd3so@debian> From: Jason Wang Message-ID: Date: Sat, 28 Apr 2018 10:45:52 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180427091234.n6vr3wcnbnqxd3so@debian> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Sat, 28 Apr 2018 02:45:58 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Sat, 28 Apr 2018 02:45:58 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jasowang@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018年04月27日 17:12, Tiwei Bie wrote: > On Fri, Apr 27, 2018 at 02:17:51PM +0800, Jason Wang wrote: >> On 2018年04月27日 12:18, Michael S. Tsirkin wrote: >>> On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote: >>>> On 2018年04月25日 13:15, Tiwei Bie wrote: >>>>> Hello everyone, >>>>> >>>>> This RFC implements packed ring support in virtio driver. >>>>> >>>>> Some simple functional tests have been done with Jason's >>>>> packed ring implementation in vhost: >>>>> >>>>> https://lkml.org/lkml/2018/4/23/12 >>>>> >>>>> Both of ping and netperf worked as expected (with EVENT_IDX >>>>> disabled). But there are below known issues: >>>>> >>>>> 1. Reloading the guest driver will break the Tx/Rx; >>>> Will have a look at this issue. >>>> >>>>> 2. Zeroing the flags when detaching a used desc will >>>>> break the guest -> host path. >>>> I still think zeroing flags is unnecessary or even a bug. At host, I track >>>> last observed avail wrap counter and detect avail like (what is suggested in >>>> the example code in the spec): >>>> >>>> static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags) >>>> { >>>>        bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL); >>>> >>>>        return avail == vq->avail_wrap_counter; >>>> } >>>> >>>> So zeroing wrap can not work with this obviously. >>>> >>>> Thanks >>> I agree. I think what one should do is flip the available bit. >>> >> But is this flipping a must? >> >> Thanks > Yeah, that's my question too. It seems to be a requirement > for driver that, the only change to the desc status that a > driver can do during running is to mark the desc as avail, > and any other changes to the desc status are not allowed. > Similarly, the device can only mark the desc as used, and > any other changes to the desc status are also not allowed. > So the question is, are there such requirements? Looks not, but I think we need clarify this in the spec. Thanks > > Based on below contents in the spec: > > """ > 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 > """ > > It seems that, it's necessary for devices to check whether > the AVAIL bit and USED bit are different. > > Best regards, > Tiwei Bie