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 1356BA04B1; Wed, 26 Aug 2020 23:20:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AF8E94C89; Wed, 26 Aug 2020 23:20:40 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 74BAA2986 for ; Wed, 26 Aug 2020 23:20:39 +0200 (CEST) IronPort-SDR: r2F1PyX+IReTbY0uWBd79h08NBS2NDz0Vy4Ex7iRdoOoR2lTN1fHioere13fCwwxNyG4MzGVa1 R1uS1AKX7BMA== X-IronPort-AV: E=McAfee;i="6000,8403,9725"; a="153805950" X-IronPort-AV: E=Sophos;i="5.76,357,1592895600"; d="scan'208";a="153805950" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2020 14:20:38 -0700 IronPort-SDR: UhjN4aMKagPrRYkD1NL+YbOTTQYWUPwKZSCLM7RyrrhlFDD1zKspCYB7nRbcvnaqN2wMHfhuqJ f6YarcPUXnlA== X-IronPort-AV: E=Sophos;i="5.76,357,1592895600"; d="scan'208";a="474923214" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.201.139]) ([10.213.201.139]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Aug 2020 14:20:36 -0700 To: Hemant Agrawal , "dev@dpdk.org" References: <20200811123001.30045-1-hemant.agrawal@nxp.com> <20200813180121.19480-1-hemant.agrawal@nxp.com> <92c65f69-49a8-85df-8d77-3379d09af2c9@intel.com> <17fb2ce1-73ff-a30f-2d92-668ea09fb15d@intel.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJsBBMBCgBWAhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEABQkKqZZ8FiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl6ha3sXGHZrczovL2tl eXMub3BlbnBncC5vcmcACgkQ+TPrQ98TYR8uLA//QwltuFliUWe60xwmu9sY38c1DXvX67wk UryQ1WijVdIoj4H8cf/s2KtyIBjc89R254KMEfJDao/LrXqJ69KyGKXFhFPlF3VmFLsN4XiT PSfxkx8s6kHVaB3O183p4xAqnnl/ql8nJ5ph9HuwdL8CyO5/7dC/MjZ/mc4NGq5O9zk3YRGO lvdZAp5HW9VKW4iynvy7rl3tKyEqaAE62MbGyfJDH3C/nV/4+mPc8Av5rRH2hV+DBQourwuC ci6noiDP6GCNQqTh1FHYvXaN4GPMHD9DX6LtT8Fc5mL/V9i9kEVikPohlI0WJqhE+vQHFzR2 1q5nznE+pweYsBi3LXIMYpmha9oJh03dJOdKAEhkfBr6n8BWkWQMMiwfdzg20JX0o7a/iF8H 4dshBs+dXdIKzPfJhMjHxLDFNPNH8zRQkB02JceY9ESEah3wAbzTwz+e/9qQ5OyDTQjKkVOo cxC2U7CqeNt0JZi0tmuzIWrfxjAUulVhBmnceqyMOzGpSCQIkvalb6+eXsC9V1DZ4zsHZ2Mx Hi+7pCksdraXUhKdg5bOVCt8XFmx1MX4AoV3GWy6mZ4eMMvJN2hjXcrreQgG25BdCdcxKgqp e9cMbCtF+RZax8U6LkAWueJJ1QXrav1Jk5SnG8/5xANQoBQKGz+yFiWcgEs9Tpxth15o2v59 gXK5Ag0EV9ZMvgEQAKc0Db17xNqtSwEvmfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ES YpV8QWj0xK4YM0dLxnDU2IYxjEshSB1TqAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4Ai bPtrHuIXWQOBECcVZTTOdZYGAzaYzxiAONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxD UQljeNvKYt1lZE/gAUUxNLWsYyTT+22/vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/ 3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35piVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVj sM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQI3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdc q9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYHfVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH7 1PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZqw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFB VOQOxCvwRG2QCgcJ/UTn5vlivul+cThi6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI 8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJlRr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYC GwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNhHwUCXqFrngUJCKxSYAAKCRD5M+tD3xNhH3YWD/9b cUiWaHJasX+OpiuZ1Li5GG3m9aw4lR/k2lET0UPRer2Jy1JsL+uqzdkxGvPqzFTBXgx/6Byz EMa2mt6R9BCyR286s3lxVS5Bgr5JGB3EkpPcoJT3A7QOYMV95jBiiJTy78Qdzi5LrIu4tW6H o0MWUjpjdbR01cnj6EagKrDx9kAsqQTfvz4ff5JIFyKSKEHQMaz1YGHyCWhsTwqONhs0G7V2 0taQS1bGiaWND0dIBJ/u0pU998XZhmMzn765H+/MqXsyDXwoHv1rcaX/kcZIcN3sLUVcbdxA WHXOktGTQemQfEpCNuf2jeeJlp8sHmAQmV3dLS1R49h0q7hH4qOPEIvXjQebJGs5W7s2vxbA 5u5nLujmMkkfg1XHsds0u7Zdp2n200VC4GQf8vsUp6CSMgjedHeF9zKv1W4lYXpHp576ZV7T GgsEsvveAE1xvHnpV9d7ZehPuZfYlP4qgo2iutA1c0AXZLn5LPcDBgZ+KQZTzm05RU1gkx7n gL9CdTzVrYFy7Y5R+TrE9HFUnsaXaGsJwOB/emByGPQEKrupz8CZFi9pkqPuAPwjN6Wonokv ChAewHXPUadcJmCTj78Oeg9uXR6yjpxyFjx3vdijQIYgi5TEGpeTQBymLANOYxYWYOjXk+ae dYuOYKR9nbPv+2zK9pwwQ2NXbUBystaGyQ== Message-ID: <21c30604-35eb-d116-deb3-5e1e59ee797e@intel.com> Date: Wed, 26 Aug 2020 22:20:32 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5 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" On 8/26/2020 6:06 PM, Hemant Agrawal wrote: > HI Ferruh, > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Wednesday, August 26, 2020 8:22 PM >> To: Hemant Agrawal ; dev@dpdk.org >> Subject: Re: [PATCH v5 1/8] net/dpaa: add support for fmlib in dpdk >> >> On 8/26/2020 2:54 PM, Ferruh Yigit wrote: >>> On 8/13/2020 7:01 PM, Hemant Agrawal wrote: >>>> DPAA platorm MAC interface is known as FMAN i.e. Frame Manager. >>>> There are two ways to control it. >>>> 1. Statically configure the queues and classification rules before >>>> the start of the application using FMC tool. >>>> 2. Dynamically configure it within application by making API calls of >>>> fmlib. >>>> >>>> The fmlib or Frame Manager library provides an API on top of the >>>> Frame Manager driver ioctl calls, that provides a user space >>>> application with a simple way to configure driver parameters and PCD >>>> (parse - classify - distribute) rules. >> >> >> Hi Hemant, >> >> This patch is missing some serious documentation, fmlib support depends on >> some kernel module(s) which doesn't mention anywhere as dependency, >> and what are those modules, where can we find them, what is the licensing >> of them etc all missing. > > [Hemant] ok >> >> Also there is some code in the patchset that assumes there is a generated >> binary in "/tmp/fmc.bin", the documentation of how this binary generated, >> where can we find tool to generate binary is missing. >> Should we rely on a binary should exist in a tmp folder is something else.. >> >> There is some licensing concerns, some code is GPL-2 dual licensed, can't >> they licensed as BSD-3? >> > [Hemant] We can change the licensing of this code as we are anyway changing the files. > OK > >> Last thing is there is still some clutter in the code from linux, and there are >> still formatting/syntax issues... > > [Hemant] ok >> >>>> >>>> This patch integrates the base fmlib so that various queue config, >>>> RSS and classification related features can be supported on DPAA >> platform. >>>> >>>> Signed-off-by: Sachin Saxena >>>> Signed-off-by: Hemant Agrawal >>>> --- >>>> v4: adapting to DPDK style >>>> v5: removing shared compilation issue and spelling errors >>>> >>>> drivers/net/dpaa/Makefile | 4 +- >>> >>> For this release, v20.11, all Makefile changes can be dropped, since >>> make build system will be removed soon. >>> >>> <...> >>> >>>> + >>>> +/* #define FM_LIB_DBG */ >>> >>> What about adding this as a config option, to enable & disable the >>> debug, instead of having as a commented code? >>> And overall why not use this as runtime configurable logging, instead >>> of compile time? >>> >>>> + >>>> +#if defined(FM_LIB_DBG) >>>> + #define _fml_dbg(format, arg...) \ >>>> + printf("fmlib [%s:%u] - " format, \ >>>> + __func__, __LINE__, ##arg) >>> >>> Please use DPDK logging, instead of 'printf'. >>> > [Hemant] ok > >>> Btw, this file has dual license, we have dual license for the code >>> that is shared between kernel and DPDK, if this is shared with kernel >>> how can have the 'printf'? >>> Should debug related macros moved to some other header? >>> >>> <...> >>> >>>> + >>>> +uint32_t fm_pcd_disable(t_handle h_fm_pcd) { >>>> + t_device *p_dev = (t_device *)h_fm_pcd; >>> >>> >>> Since this is not shared but DPDK only code (that was the outcome of >>> the techboard discussion), can you pleae follow the DPDK coding >>> convention to the file. There are multiple samples doesn't match the >>> convention, I won't comment on other instances. > [Hemant] We have changed the Hungarian notation to all small case. > Will you please help me with one example here. How you want to see it? > My comment was on tab between type (t_device) and variable name (p_dev), this exists in many places. Also there is an issue on how the function definition syntax should be, return type in above line etc ... A reminder of the DPDK coding sytle: https://doc.dpdk.org/guides/contributing/coding_style.html > >>> >>> <...> >>> >>>> +#if defined(CONFIG_COMPAT) >>>> +#define FM_PCD_IOC_PRS_LOAD_SW_COMPAT \ >>>> + _IOW(FM_IOC_TYPE_BASE, FM_PCD_IOC_NUM(3), \ >>>> + ioc_compat_fm_pcd_prs_sw_params_t) >>>> +#endif >>> >>> 'CONFIG_COMPAT' is for Linux, do we need it for the DPDK copy? >>> > [Hemant] We were trying to avoid changes in common files with Linux. > For example for the Intel common code, there are #ifdefs that are parsed and output generated based on project you are upstreaming. So both Linux and DPDK (and others) code generated from same common source, can something similar be done here? We know that 'CONFIG_COMPAT' is not something exists in DPDK, doesn't sound right to have that piece of code in DPDK.