Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1947734imm; Wed, 16 May 2018 05:40:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo8vbRVU63n9/yL1vsN8gnTo3vTvnMBydPs6z9lfAbz8N+rCwG8AWVm4h22IiGID6TD+lPy X-Received: by 2002:a63:955e:: with SMTP id t30-v6mr615538pgn.77.1526474430098; Wed, 16 May 2018 05:40:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526474430; cv=none; d=google.com; s=arc-20160816; b=BIdJ26txVs8K1O/6+8TuN36mjh2fL0kUfHRZ0KZ+/5Z+euL/ahsLgxfWVR0034be90 7MtGV0Q++G0yhpCIvQwPdf2rFWWpAY6+orCbBmSNtFvIfc58T3UOgCaq05fCIoRCUj0M RXTdAruZfqym4XFi/yrJhVd6NCzOgxMdeAUMX8UG07iUNDXOdvgxAEoknD0P8+XOVs3f ZWC9IhbJBPmIKgsnrUTSOxLwMtSt59b025VWSPrsXsA+qJ42lmsQ93RQ3NMJWaqpcwH7 bH2Hv9vzvC6ddvDL13yqqJk6PVZP+g8IECTRLLkGW5rN6V5tR1wz4wviIyzo4w10Ztbq tfPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=iDpspRRW4KVhPkVKx3LwmxcUfqXRBcMTXQBDhmZTbxs=; b=g/gjFdQKPtnGVTC9VI1uvbB4y63x/QgNxyDLFIlfE6YESk0ufPzA6KlpTdBC3qLb8v vFMqGBjJ7TGewZf52ShMDc1xWvMhynJ6+6OjDK4Peq7443sW0mfMoLHPB7W7EDSP0FrT hZSfR1xCEsFH5ixbaCWMDm61vIE6QdqZpJNB27eP6vc0eDqZ6F9qf3SePoAJWSFCZ2Wv bLGOed5nZ6z1BVKQGPUT+Pet+yCZkvvNfYyIzNi5GBdSvohyadTK2clyXMGD+SrJiCaM x/bAd+8NBRl6HF8iLDEqpZALxfGWS8Q7M/KsoVh4rnFYUoNF2kgSWxjTNScDd+/cd63p 6SoQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t184-v6si2583107pfb.98.2018.05.16.05.40.15; Wed, 16 May 2018 05:40:30 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752447AbeEPMiq (ORCPT + 99 others); Wed, 16 May 2018 08:38:46 -0400 Received: from mga07.intel.com ([134.134.136.100]:29601 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752215AbeEPMio (ORCPT ); Wed, 16 May 2018 08:38:44 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2018 05:38:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,390,1520924400"; d="scan'208";a="224694269" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.203]) by orsmga005.jf.intel.com with ESMTP; 16 May 2018 05:38:42 -0700 Date: Wed, 16 May 2018 20:39:09 +0800 From: Tiwei Bie To: Jason Wang Cc: mst@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, wexu@redhat.com, jfreimann@redhat.com Subject: Re: [RFC v4 3/5] virtio_ring: add packed ring support Message-ID: <20180516123909.GB986@debian> References: <20180516083737.26504-1-tiwei.bie@intel.com> <20180516083737.26504-4-tiwei.bie@intel.com> <2000f635-bc34-71ff-ff51-a711c2e9726d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2000f635-bc34-71ff-ff51-a711c2e9726d@redhat.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote: > On 2018年05月16日 16:37, Tiwei Bie wrote: [...] > > struct vring_virtqueue { > > @@ -116,6 +117,9 @@ struct vring_virtqueue { > > /* Last written value to driver->flags in > > * guest byte order. */ > > u16 event_flags_shadow; > > + > > + /* ID allocation. */ > > + struct idr buffer_id; > > I'm not sure idr is fit for the performance critical case here. Need to > measure its performance impact, especially if we have few unused slots. I'm also not sure.. But fortunately, it should be quite easy to replace it with something else without changing other code. If it will really hurt the performance, I'll change it. > > > }; > > }; [...] > > +static void detach_buf_packed(struct vring_virtqueue *vq, unsigned int head, > > + unsigned int id, void **ctx) > > +{ > > + struct vring_packed_desc *desc; > > + unsigned int i, j; > > + > > + /* Clear data ptr. */ > > + vq->desc_state[id].data = NULL; > > + > > + i = head; > > + > > + for (j = 0; j < vq->desc_state[id].num; j++) { > > + desc = &vq->vring_packed.desc[i]; > > + vring_unmap_one_packed(vq, desc); > > As mentioned in previous discussion, this probably won't work for the case > of out of order completion since it depends on the information in the > descriptor ring. We probably need to extend ctx to record such information. Above code doesn't depend on the information in the descriptor ring. The vq->desc_state[] is the extended ctx. Best regards, Tiwei Bie