From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 42A66A052B; Wed, 29 Jul 2020 14:07:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE56110A3; Wed, 29 Jul 2020 14:07:05 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 1029A1023; Wed, 29 Jul 2020 14:07:04 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6CFA55C012C; Wed, 29 Jul 2020 08:07:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 29 Jul 2020 08:07:03 -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=fm1; bh= uiLQp3XFTFPLQl2kM3T+nSBzGccbbpuQ46+ek699zqQ=; b=E8K3i1i3n9KtlRWs 1PuSaYsHdLpq4GYwEue+NztGW51DlItQIOnfBLByWuuybHcwPqGflF81/wACAgjf Yx+QaPwmrOuWHK94HW1HF5K+JNrk09qhC4UL3CgyWNuBUQIFYyWDsJECSmXdfbGm YdipNZ5pgkPHVsgGSS6XK7MBslhey7PLutvdKb1mg/bk/JLM6XOc2RGEAIepOWKM cmUOgvECsbUiEgCXuDjJkF12GOpqaslT5g+XA1Em82iQyk8f6XI4SN6o7WLBbyQy dfZSDfKKFkajx5kJW0XdAivK5FIRU+zHetvd/t+G4MQ6EfUWbM6Kxu+8blo/R3a/ D0zdLw== 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=fm3; bh=uiLQp3XFTFPLQl2kM3T+nSBzGccbbpuQ46+ek699z qQ=; b=ETMdYBn+uBcrev6CaflWH/6jd8qVoK9SCuisc4sX5fBxI7aAKsdQjCjT3 dnDoHkvBU5lD655LVtqUJimPpwZnHOUMXl2l+lfrqyruF/BDeJarvZSE9ajek3HH Qabxk1QH04Qdg4JaduevHmDD21Z2JaqChWyKSlEYcrPzB+MvQIJIa+WeTiMpfgxs mDnFfMSpQkhrAAI6sBhX9JqCO1r0/EjnKU3gvAB06xY6L6a//QGxYhI+iIFkuXoS n9oCL2BQXl1wThwN7bB6XTU1QJv82khiQm+vkkj+4iMX3eHMVCjCQlhPNUbDUaq2 KsL++/geowxujv8dnduhnJlwfdpwA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeeujedvveeiueefhfffudeggedtgeevgeetffdtuefhtedtkedttdej tdeltdfgteenucffohhmrghinhepohhuthhlohhokhdrtghomhdpgedtnhigphdrtghomh enucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 56EDD30600A3; Wed, 29 Jul 2020 08:07:02 -0400 (EDT) From: Thomas Monjalon To: David Marchand , Hemant Agrawal Cc: Sachin Saxena , "dev@dpdk.org" , Ferruh Yigit , "techboard@dpdk.org" Date: Wed, 29 Jul 2020 14:07:01 +0200 Message-ID: <2853737.aX8IBrFUQA@thomas> In-Reply-To: References: <20200710171946.23246-1-hemant.agrawal@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 1/8] net/dpaa: add support for fmlib in dpdk 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 29/07/2020 08:39, Hemant Agrawal: > Hi David >=20 > From: David Marchand > >=20 > > Hello Hemant, > >=20 > > On Mon, Jul 20, 2020 at 6:50 AM Hemant Agrawal > > wrote: > > > >Why dropping this codebase in DPDK instead of pulling it as a > > dependency? > > > [Hemant] >I don't like seeing DPDK becoming a pile of code duplicated > > from somewhere else. > > > [Hemant] We are not using the library as it is and making some serious > > changes in the generic library to suit the DPDK use-case. > > > So, it is not possible for us to use the *original* code of fmlib, wh= ich is > > public. > >=20 > > Looking at > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hu > > b.com%2Fqoriq-open- > > source%2Ffmlib&data=3D02%7C01%7Chemant.agrawal%40nxp.com%7Ce > > b9167f8bbd64a6234dd08d832fc01cb%7C686ea1d3bc2b4c6fa92cd99c5c301635 > > %7C0%7C0%7C637315405224811211&sdata=3D%2B65hKHyXFlWgXYq7yzZb > > lEYlI%2FyKb8OINXRuGqX8dOM%3D&reserved=3D0 which I think is the > > original code for this library (?). > >=20 > > Some symbols from the original code were dropped in the dpdk copy of the > > file. > > Part of the API changed, with a param pointer now being passed. >=20 > [Hemant] In DPAA1 is NXP's legacy architecture. > =20 > In the DPDK on ARM-DPAA1 (MAC is called FMAN) platforms, we have been su= pporting static FMAN configuration utility (fmc) to pre-configure the queue= s, RSS and classification rules before starting the application. This confi= g has several limitations, e.g. max DPAA_NUM_RX_QUEUES via env variable, et= c. In last few years, several customers are using it in production.=20 >=20 > The legacy Fmlib supports dynamic FMAN configuration and it removes curre= nt limitation in DPAA PMD. In order to support both modes where we can supp= ort new dynamic configuration with fmlib and static fmc mode (with parsing = facility to avoid env variables). We have done this modification in fmlib s= tructures to support both fmc parser and flow API on fmlib mode. > This param change is part of that.=20 >=20 >=20 > > The VSP symbols are in the fm_lib.c file from the original code while t= hey > > have been separated in a fm_vsp.c file in the dpdk copy. > > Some logs / comments have changed. > >=20 > [Hemant] Yes, there is code structuring and removal of code, which we don= 't need for DPDK and ARM platforms. There are several small changes in VSP = as well as PCD (Parse Classify Distribute) configuration.=20 >=20 > > For the sake of understanding: > > - can you point at the problems with reusing this externally maintained > > library? >=20 > [Hemant] The original library was designed to work with our legacy Usersp= ace offering (USDPAA) and Bare metal offerings on PowerPC. We did tested it= initially on ARM but now largely it is only for supporting legacy custome= rs. This library is in maintenance mode. Given this quite old legacy library is in maintenance mode, we can assume the number of fixes in future will be low. That's why I think the DPDK fork could be reformatted to DPDK code style. > NXP don=E2=80=99t want to add any new feature in this legacy standalone l= ibrary - as it is difficult to test them on PowerPC and they can break the= legacy customers code.=20 > On ARM, we are now only offering DPDK as the Userspace solution. So, we h= ave done a branch out of the code for DPDK. > Some changes you are already seeing and there are more in development to = support DPDK style flow classification.=20 > Since DPDK is only consumer for this new base code, there is no reason fo= r creating external dependency for the DPAA PMD.=20 >=20 > > - this library is tightly linked to the fm kmod drivers I guess, how is= maintained > > the compatibility? >=20 > [Hemant] kernel module is already inbuilt in NXP Linux kernel for this pl= atform.=20 Is the kernel module upstream?