Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2079420imm; Wed, 16 May 2018 07:34:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoCvHyZenObBJbVxZm9Ffb5+i5R7ns+ROEnJtTd4yjAdEWPPhokCqQbQYrA2w10H1WdKz1C X-Received: by 2002:a65:52cc:: with SMTP id z12-v6mr959980pgp.126.1526481299312; Wed, 16 May 2018 07:34:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526481299; cv=none; d=google.com; s=arc-20160816; b=0vssUMh0BqqzhLGfhwpumpF/lXqaYxaoWFIkUDh4gql+fQxURwpTrVOW+1MXFNOiZV IaWZmJ9T0jsQF4cw4pbpOkkOes9E5dBrjRldGQKCkLgby0Mq2BVmWHc3TBdpPvOS3Ogn Fo2hgghK0Y1ReaWltj9lFCGb6V63XLTBgVPXrqS2D0STham0oWW8auHmGiDSwoMAlhA4 8ny1/kHvoUR2KuM87LpHomqiGIRG7A9aMswwz178ubVhmjD/iXMgJP1afIK6sCKwDE2u H6oLGiUFwFT4BdvvjlD3h5ean1n1Kt4Mp/GwfMyL745P+EorWBpCvgVqD2YZrxNuGgVg ld5A== 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=S04J47pSA3iTRizK1GwJy3KyxypkT0WjtfQOod7xgrg=; b=cHlrTPqwVtXCbpGy+Be3GDuRLF5+Odr0QtuIYlQ8a7lFw2DZbclL6UWtSweUwq+tzW 1yzes9nhP7OsWcEsPWGq0PBaezKJ3je1E8IflOEt5DuLG92BqyAq64ogtr2QuKEKWe0r BYEh2uS7Cp79YoBjcoSsz7WN5ZcxYrtFNysOmIsIcbBLVmDKoaSQqZwM7leleAW4t7oY hI+GyJeC7zXP2r8F0yw8Zz15ZvEpkvPFKWG+yoTS/KDlGzX/tf2JKPHNQLhvKP+LwwBk 0N6WTMiC5QwkTnZ+5nkN8LnU2qJ6IAs/iPk9a9EgrMmmZ93HktVXGyw4QBwCCIa3H9q7 HH8Q== 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 t5-v6si2712159plo.113.2018.05.16.07.34.44; Wed, 16 May 2018 07:34:59 -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 S1752490AbeEPOdI (ORCPT + 99 others); Wed, 16 May 2018 10:33:08 -0400 Received: from mga17.intel.com ([192.55.52.151]:37600 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbeEPOdH (ORCPT ); Wed, 16 May 2018 10:33:07 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2018 07:33:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,406,1520924400"; d="scan'208";a="55748285" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.203]) by fmsmga001.fm.intel.com with ESMTP; 16 May 2018 07:33:05 -0700 Date: Wed, 16 May 2018 22:33:32 +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: <20180516143332.GA1957@debian> References: <20180516083737.26504-1-tiwei.bie@intel.com> <20180516083737.26504-4-tiwei.bie@intel.com> <2000f635-bc34-71ff-ff51-a711c2e9726d@redhat.com> <20180516123909.GB986@debian> <20180516134550.GB4171@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 10:05:44PM +0800, Jason Wang wrote: > On 2018年05月16日 21:45, Tiwei Bie wrote: > > On Wed, May 16, 2018 at 08:51:43PM +0800, Jason Wang wrote: > > > On 2018年05月16日 20:39, Tiwei Bie wrote: > > > > On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote: > > > > > On 2018年05月16日 16:37, Tiwei Bie wrote: [...] > > > > > > +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 > > > Yes, but desc is a pointer to descriptor ring I think so > > > vring_unmap_one_packed() still depends on the content of descriptor ring? > > > > > I got your point now. I think it makes sense to reserve > > the bits of the addr field. Driver shouldn't try to get > > addrs from the descriptors when cleanup the descriptors > > no matter whether we support out-of-order or not. > > Maybe I was wrong, but I remember spec mentioned something like this. You're right. Spec mentioned this. I was just repeating the spec to emphasize that it does make sense. :) > > > > > But combining it with the out-of-order support, it will > > mean that the driver still needs to maintain a desc/ctx > > list that is very similar to the desc ring in the split > > ring. I'm not quite sure whether it's something we want. > > If it is true, I'll do it. So do you think we also want > > to maintain such a desc/ctx list for packed ring? > > To make it work for OOO backends I think we need something like this > (hardware NIC drivers are usually have something like this). Which hardware NIC drivers have this? > > Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is > much more simpler to be started with. +1 Best regards, Tiwei Bie