From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id B60F22661 for ; Sat, 30 Sep 2017 13:49:58 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 47BB311D2; Sat, 30 Sep 2017 07:49:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 30 Sep 2017 07:49:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=Kg5LiwLtI0Nufk8jhR1uan3G7zp6WZ+v0NsOhzZUO 2E=; b=pOgc8pB214kYp+ci9hyNwXo7KrQCQXrcvGml2rO9dr0MqN1uRQ6wPagc5 yiLsqdIl30LuY67Pb3wEJNO3DxQhbL70uEIgG5/v+SAiJmSDIUuCAdHTcMo/ARc2 4TbPx8UulsQyxRSTruLocLQHMG3ku6SUC0A9jCcC86tVVnA2r3EqBMe9HovRPSrW ju3U9SYrNBXcq8hCqeaQ+9Wur7WJUx4WIvmwnUCUdUJ72a0wOAp+Lrqjqdqo7w2W FBF0iFytmRCeUKdGsOrSBGQQotnmOrD+7qg9g49L6zvjnFL4LiNmM7yMvfAhpKtR FrGR32ip19evszjOeuQ6kZcQhIcuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Kg5LiwLtI0Nufk8jhR 1uan3G7zp6WZ+v0NsOhzZUO2E=; b=mUUHq6AYbR2qJDtHlUwZQW3RBYRxJvw67I ma3U1M1bHlVbHAV6LcMTZeJddfStnSicPUnCzSIiTiI6EBedHMHILUBryDywJ3gZ h75SrKWrbTyP48LVtKKcq7RetqpNocNkpA5osn2ugQqBEH/lBQinRSo12wX3c2eQ L8sa6qDrip7OsIwF7nEkB2WR4Fwc0AV62DEoqoVCEU95bGOv/bheFjYr4RMMOjlO V5YtVSmeHRTT+FsO7iAeOxE+DxeD0wWYcEmpOue2V1q+JUMMp83zQr2Lihyj0o96 PmiJKG2UFImcJB1qEEkWzWTdQESSwFg1iUaMCR7i2Y8JO53xEBTQ== X-ME-Sender: X-Sasl-enc: 7F6gpZO+lzrbRY6F2SGor5n0dUnLvlW8CqMuy3dmAVkB 1506772197 Received: from yliu-home (unknown [222.64.168.88]) by mail.messagingengine.com (Postfix) with ESMTPA id D9217241BE; Sat, 30 Sep 2017 07:49:56 -0400 (EDT) Date: Sat, 30 Sep 2017 19:49:53 +0800 From: Yuanhan Liu To: "Tan, Jianfeng" Cc: dev@dpdk.org, bruce.richardson@intel.com, konstantin.ananyev@intel.com, pablo.de.lara.guarch@intel.com, thomas@monjalon.net, maxime.coquelin@redhat.com, mtetsuyah@gmail.com, ferruh.yigit@intel.com Message-ID: <20170930114953.GG6251@yliu-home> References: <1503654052-84730-1-git-send-email-jianfeng.tan@intel.com> <1506606959-76230-1-git-send-email-jianfeng.tan@intel.com> <1506606959-76230-13-git-send-email-jianfeng.tan@intel.com> <20170929082817.GN2251@yliu-home> <7d8d48ce-85a2-80a0-744c-48cbeee8ab3c@intel.com> <20170930075554.GB6251@yliu-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170930075554.GB6251@yliu-home> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [PATCH v2 12/12] net/vhost: support to run in the secondary process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 11:50:00 -0000 On Sat, Sep 30, 2017 at 12:06:44PM 0000, Jianfeng Tan wrote: > >>>> + /* share callfd and kickfd */ > >>>> + params->type = VHOST_MSG_TYPE_SET_FDS; > >>>> + vring_num = rte_vhost_get_vring_num(vid); > >>>> + for (i = 0; i < vring_num; i++) { > >>>> + if (rte_vhost_get_vhost_vring(vid, i, &vring) < 0) { > >>> If you save the fds here, you don't have to get it every time when there > >>> is a new secondary process attached. Then as I have suggested firstly, > >>> you don't have to introduce callfd_pri in the vhost lib. > >> If we don't introduce callfd_pri, when we do virtqueue cleanup (or similar > >> operations) in vhost lib, it will wrongly close fds belonging to secondary > >> process. > >> > >> You remind me that, instead of introduce callfd_pri, we can introduce > >> callfd_effective, to reduce the modification lines. > > It's not about how many lines are modified. You were adding "effective" > > fds, which is a semantic change. It makes the logic a bit more complex. > > What's worse, it even doesn't resolve the issue completely. > > Yes, it still has limitation. Just wonder if possible to move event fd > write out of vhost lib. It could be another solution: we have the valid fd and vring_avail outside the vhost lib. It's just that the callfd write is inside the vhost lib. If you just take it out (remove it), it breaks some users who rely on it: it's an API behaviour change. --yliu