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 B41B51B3EA for ; Tue, 23 Oct 2018 11:03:14 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 536A421FFF; Tue, 23 Oct 2018 05:03:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 23 Oct 2018 05:03:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=3EdiZgQ0voDEbPvR8EhVzviFsWoLg2FOgYv5/bAF3EA=; b=rztd4SyU2tnp 4kI/H8Q8r+m3XKj9X1hvFPsI/9871Trvxw/fEH1+YZma2P0F05/7Jw84LI7QJGnd gMzb8jYsAlAwkkQqHOKDs+k7334Z/aQd4axYGLC7FdXalFPNuQs1og4apyQg2Hg8 m2EkpzHBliAc6IPOHAOQr/6LoffJxuY= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3EdiZgQ0voDEbPvR8EhVzviFsWoLg2FOgYv5/bAF3 EA=; b=ABRHpPd4t54TXUuxUvPjJAL8C7XDt4MWi8zQf7wssiEeLAgOCPCai9oXm xDWzHPmZRmfnxs8WG31hyGrflxSMYHVzZZ3UKqNQKrdsieOHouB7Vrv7Bb8EbcwY 6II0dKTtTWEiPt3jVouYpLZWNHYJ/s+cOKG9lRc9htsuYHmToyxCoraXXXpjYL5X qxxc3t214FaoqLr6vXp4crrnBrb/353xwu4mMzWnrx1Q9Atq/RUSew/oaAI+Cn9i 79ZLvQqj/CLJHy6QgaekVb23sjUCHCzPJ0wivIyUEkPPN20SlAT2ECxfMy2xVj9n 5n1/AcxTGTla2x2nP5R+yauq2ynMA== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 42B54102EC; Tue, 23 Oct 2018 05:03:12 -0400 (EDT) From: Thomas Monjalon To: "Joseph, Anoob" Cc: "Trahe, Fiona" , "dev@dpdk.org" , Akhil Goyal , "De Lara Guarch, Pablo" , "Murthy, Nidadavolu" , "Jacob, Jerin" , "Athreya, Narayana Prasad" , "Dwivedi, Ankur" , "Dabilpuram, Nithin" , "Jayaraman, Ragothaman" , "Srinivasan, Srisivasubramanian" , "Tejasree, Kondoj" Date: Tue, 23 Oct 2018 11:03:14 +0200 Message-ID: <4791369.uWb8itST2X@xps> In-Reply-To: References: <1528476325-15585-1-git-send-email-anoob.joseph@caviumnetworks.com> <3230031.dhaMjhjEo9@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities 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, 23 Oct 2018 09:03:15 -0000 23/10/2018 10:48, Joseph, Anoob: > From: Thomas Monjalon > > 22/10/2018 05:49, Joseph, Anoob: > > > Hi Fiona, > > > > > > I do agree that your solution seems to be a neat way for organizing > > capabilities. But Akhil & Thomas were against that idea and we had to come up > > with one array with all capabilities. This would not scale well when we start > > supporting devices with varying capabilities. > > > > > > If your plan is to follow the same approach for asym support, maybe we will > > also follow suit and submit the required patches. > > > > > > @Akhil, Thomas, thoughts? > > > > Generally speaking, macros are bad. > > > > Why cannot you just write functions? > > I don't understand your issue. > > I had replaced macro with functions when I revised the patch. But when more devices (with varying capabilities) need to be supported, this can get complicated. Macro approach would be simpler in that case. Right now QAT has macros and we would like to stick to what is being followed in the community. > > Following would be the use case for macros, > > #define QAT_BASE_GEN1_SYM_CAPABILITIES, \ > { CAPABILITES, \ > ... \ > } > > #define QAT_EXTRA_GEN2_SYM_CAPABILITIES \ > { CAPABILITES, \ > ... \ > } > > static const struct rte_cryptodev_capabilities qat_gen1_sym_capabilities[] = { > QAT_BASE_GEN1_SYM_CAPABILITIES, > RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() > }; > > static const struct rte_cryptodev_capabilities qat_gen2_sym_capabilities[] = { > QAT_BASE_GEN1_SYM_CAPABILITIES, > QAT_EXTRA_GEN2_SYM_CAPABILITIES, > RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() > }; > > Without the macros, we will be required to populate the array there itself and would mean repetition of GEN1 capabilities. Either approach is fine for us, but this could complicate things when we add support for ASYM. Since QAT is already doing this, is it fine to move to that approach as we add support for ASYM? Or if QAT is to follow any other scheme, I'm fine with adopting that as well. Whatever is simple and uniform would work. You can use simple assignments in functions and avoid repetition. There is a warning in checkpatch about macros. I think we should be more strict with this warning.