From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 6583B2C8 for ; Tue, 27 Jun 2017 18:09:07 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 10A7020E0D; Tue, 27 Jun 2017 12:09:07 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 27 Jun 2017 12:09:07 -0400 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:x-sasl-enc; s=mesmtp; bh=fYGJlK5tzRnlDSC Pr+nZLy/pq7Jl367VstJz4+sv5t0=; b=qmS34t5xkXrASVTtuubADhk87H2HBt7 eKbixFm9TYM/7pD8KVTnPLsQIxeE7VlQSC1zcYeQRto6NScRVi4Ci1al4IitMY9j 9AWrBOysaDKieTVG4sdH4+UPNbBEfIrS9dHr0/dIkoShZBhMQ5+Z8y1O+BAXMADY 1ePpZDFxEKp4= 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:x-sasl-enc; s= fm1; bh=fYGJlK5tzRnlDSCPr+nZLy/pq7Jl367VstJz4+sv5t0=; b=qcG93MbK zYz9Kzn2JpA/J9a3cGJEoRawiEpNNdxl3RgDrrzu2wFLLJgTK5pAypuVWZl709u1 B8xL1FSpISUDamhkDPlTvNmHoyzKpbh6V62DlNgr4ZpUskKQdWyfoJhZRlaRKCJk isysicDHTl2HwrOo5tczCmwTah4o4IHwCRgmHniGMcfk6S/Ks2HWlJLS/QCbNS92 pzOkEYxLx/LnR5z+adp8uJdkyzWbOS83uM8Zo+xTD1l7PuYHH5TQVcbDaYZ5hYzx SU9Q6U6obrqOAvwmL64uS6X8li4rT1l3ZzLoQ0T5cQtaPnON8rfm+OD3Pf+We3MY a3l1KZGSVLy3hQ== X-ME-Sender: X-Sasl-enc: 6CE0amkLsEiIxYDfF55lu4wZ9MLbDLc6EqWufd6g44Ne 1498579746 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AB84C24038; Tue, 27 Jun 2017 12:09:06 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, "De Lara Guarch, Pablo" , "Doherty, Declan" Date: Tue, 27 Jun 2017 18:09:05 +0200 Message-ID: <1580410.hOtKtBbxIg@xps> In-Reply-To: <8d33a2ad-b80c-1337-0db3-88aa5e6fcb07@intel.com> References: <1495639634-74846-1-git-send-email-pablo.de.lara.guarch@intel.com> <1703981.y8KKVdfaY4@xps> <8d33a2ad-b80c-1337-0db3-88aa5e6fcb07@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 06/12] cryptodev: move vdev functions to a separate file 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: Tue, 27 Jun 2017 16:09:07 -0000 27/06/2017 17:11, Ferruh Yigit: > On 6/27/2017 3:28 PM, Thomas Monjalon wrote: > > 27/06/2017 11:51, De Lara Guarch, Pablo: > >> From: Thomas Monjalon [mailto:thomas@monjalon.net] > >>> 23/06/2017 14:52, Declan Doherty: > >>>> On 21/06/2017 7:28 AM, Pablo de Lara wrote: > >>>>> Move all functions handling virtual devices to a separate header > >>>>> file "rte_cryptodev_vdev.h", in order to leave only generic > >>>>> functions for any device in the rest of the files. > >>>>> > >>>>> Signed-off-by: Pablo de Lara > >>>> > >>>> Acked-by: Declan Doherty > >>> > >>> This patch is moving some code from a .c to a .h. > >>> The consequence is that driver are now compiling new functions from the .h > >>> and require librte_kvargs to link with. > >>> It is a build error in shared lib mode. > >>> > >>> Please keep the code in a .c file if possible. > >> > >> Sorry about this. I just fixed it in the subtree, so pull it whenever you are ready. > >> Also, since ethdev have separated pci and vdev functions in separate .h files, > >> I preferred to be consistent and do the same. > > > > There is no reason to implement these functions in .h files. > > I prefer to keep them in a .c file and just export the proto in .h. > > This is same in the eth_dev too. > > These are helper functions, and implementing them in .h file has the > benefit of function goes into PMD library, and there is no dependency > from PMDs to librte_ether for these functions (there are dependencies > for other functions ..). > > It looks acceptable for me for helper functions to be implemented in > header file. But if we decide to move them into .c file, .map file > should be updated to export them, and I suppose ethdev also should be > updated to be compatible. Yes we should avoid adding code in .h. It is accepted only for performance reasons. ethdev can be reworked later. cryptodev can be improved now and avoid adding rte_devargs deps on PMDs.