From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id B903D2BCD for ; Thu, 1 Mar 2018 15:14:06 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 54D0320B2E; Thu, 1 Mar 2018 09:14:05 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 01 Mar 2018 09:14:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=c090W3osEWFw83ufyc8cRmSJms FTYql4Fs7Z3OC8Kbg=; b=JyY23a16m3YON8ZCAA32IMSiiqdO+/gnFTQhiOasmw 91TrgrYb2uY4p+cwghxztwQ2A32lmQ9O28T1YwD6zvlCCGAE2m1p6RC+k0m4E+u3 ntgbyYH/J3xYP7F1KnMdxDPotRft4xDWjDlkkbrS9d1VYGp5KQodolEMTaPz4TVa A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=c090W3 osEWFw83ufyc8cRmSJmsFTYql4Fs7Z3OC8Kbg=; b=ZFaVk/kjstnhljwIDth0GJ LZ1NPZ6aivssEE6CQQ9mQas8A25vHf9AGVm0CCf8a2TJzrXFIUg709Y8Zwh2Nd/d KI4l/aIyLzLRNSHgHbYhQ4d3qU3IhbTSeSqVGn5gOOAcrHdncznPuRJrMygrl509 Sob0fRE13xz04Mrl9a57ngF/ZT96fayxy+t+wtrknl9cfux1hbOjNdLsHcIg2zWH CSm0Bqnp2sWdVkZherhHXPIYXNTP7SqAxERy+9NmeZJfDpbUzbQvD5mJ6zFqfa6G B8asYCPsjAgWLfV2NTWAIZejmkmi8dfxlzD+AgMdAYhH51PbesJufadPmXvY9vaA == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 1F68C7E26F; Thu, 1 Mar 2018 09:14:04 -0500 (EST) From: Thomas Monjalon To: "Tan, Jianfeng" Cc: Maxime Coquelin , "Yang, Zhiyong" , "dev@dpdk.org" , "yliu@fridaylinux.org" , "Bie, Tiwei" , "Wang, Zhihong" , "Wang, Dong1" Date: Thu, 01 Mar 2018 15:13:46 +0100 Message-ID: <3334571.8h0X0LI7U9@xps> In-Reply-To: References: <20180214145330.4679-1-zhiyong.yang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 1/4] vhost: move fdset functions from fd_man.c to fd_man.h 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: Thu, 01 Mar 2018 14:14:07 -0000 01/03/2018 07:02, Tan, Jianfeng: > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > > On 02/28/2018 02:36 AM, Yang, Zhiyong wrote: > > > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > > >> On 02/14/2018 03:53 PM, Zhiyong Yang wrote: > > >>> lib/librte_vhost/Makefile | 3 +- > > >>> lib/librte_vhost/fd_man.c | 274 ---------------------------------------------- > > >>> lib/librte_vhost/fd_man.h | 258 > > >> +++++++++++++++++++++++++++++++++++++++++-- > > >>> 3 files changed, 253 insertions(+), 282 deletions(-) > > >>> delete mode 100644 lib/librte_vhost/fd_man.c > > >> > > >> I disagree with the patch. > > >> It is a good thing to reuse the code, but to do it, you need to extend the > > >> vhost lib API. > > >> > > >> New API need to be prefixed with rte_vhost_, and be declared in > > >> rte_vhost.h. > > >> > > >> And no need to move the functions from the .c to the .h file, as it > > moreover > > >> makes you inline them, which is not necessary here. > > > > > > Thanks for your reviewing the series firstly, Maxime. :) > > > > > > I considered to do it as you said. However I still preferred this one at last. > > > Here are my reasons. > > > 1) As far as I know, this set of functions are used privately in librte_vhost > > before this feature. > > > No strong request from the perspective of DPDK application. If I > > understand well, It is enough to expose the functions to all PMDs > > > And it is better to keep internal use in DPDK. > > > > But what the patch is doing is adding fd_man.h to the API, without doing > > it properly. fd_man.h will be installed with other header files, and any > > external application can use it. > > > > > > > > 2) These functions help to implement vhost user, but they are not strongly > > related to other APIs of vhost user which have already exposed. > > > if we want to expose them as APIs at lib layer, many functions and related > > data structure has to be exposed in rte_vhost.h. it looks messy. > > > Your opinion? > > > > Yes, it is not really vhost-related, it could be part of a more generic > > library. It is maybe better to duplicate these lines, or to move this > > code in a existing or new library. > > I vote to move it to generic library, maybe eal. Poll() has better compatibility even though poll() is not as performant as epoll(). > > Thomas, how do you think? I don't see why it should be exported outside of DPDK, except for PMDs. I would tend to keep it internal but I understand that it would mean duplicating some code, which is not ideal. Please could you show what would be the content of the .h in EAL?