From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B4579A0C47; Thu, 7 Oct 2021 17:41:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 82DE6411E0; Thu, 7 Oct 2021 17:41:54 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id B6752411DC for ; Thu, 7 Oct 2021 17:41:52 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="207094480" X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="207094480" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2021 08:41:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="439576489" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by orsmga006.jf.intel.com with ESMTP; 07 Oct 2021 08:41:42 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 7 Oct 2021 08:41:42 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Thu, 7 Oct 2021 08:41:42 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.170) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Thu, 7 Oct 2021 08:41:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RcD/gVRc06xYAOe/BTZDo8BfSsYtAGYu6QDftjdamGSyx9MVe+ajra17vZ2fzA/ZZ+R4v3fyL0z2HhvL7Dc2CiHBEBjx8ftqeyjICrCK7Nx9WQdyDqLQHD4zVqewRm0CWyZ3svn/tGk3mEszkKz+/tRrQkdrUWv44gyobYD4hUPNvtfPEWAmOxEM+iPEf7dzAB9kW8mZLWNHwOGMyhZTTjmTWSLtUgo9lKLsPvbkcE5H3SdkQ0f1HZbz82fgc3dyY9wgkmVteZH/Rs/9HRivmhrZcKnnwT07Z8fKHJjasRVEsStaoNwGpigjWDhcyqUSAbDOR2N9q1L+rQZ/rhyZSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QUlyT98M3Th1dPE3BmHnLeXgC1a5gBaM1rEk++6Zw6I=; b=dTfc6XMAJ4cX7HXaoxQanS+dJKg2mZ6t5DiuIwU45CwTdCu/tw3NkncHJfyLMcZgKrB3nz51hmdhPTox3vORIBcF3ISD9S/jOaHk+v66TOP5G3o1mdiMNGJaCtjjKKrO+sGMSn5RRtx5acg9rrFSw9ayedIZ0/sqRbPyZH21t9fNpQwxj+oiWnpsoT1xVWE/byS510xsRWsxC+/D5NtQE5ufjwdWdgRCY15FYFKYd7qOuCUoPbGY9HuHa6Kh2q5aoL/mS+9cpyTBPPR/bR3Cl6afcaqRL6MhE5VL4xnrT2HilwV+0v0WEr/8LyqhKfvHMxgMYDPBFAcR2ZqT5JikwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QUlyT98M3Th1dPE3BmHnLeXgC1a5gBaM1rEk++6Zw6I=; b=ukym1PILzlghebmw0c6rdThw3mjEFrtDHuSJfkQdNThU0LJD/cChDNfTSBOSsbgOU0CZmXrSWaGZ57izeH4OAS6az5TBPb8V/gZW+YcwbvYuIK6qd8hH6fqW0BEsQQWLg4ZBNJfxV6PUoJP4ylINg3zs8HOzfUUEzNEe59jIEko= Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by BYAPR11MB2614.namprd11.prod.outlook.com (2603:10b6:a02:cc::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Thu, 7 Oct 2021 15:41:38 +0000 Received: from BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::d2d:4882:88be:85bd]) by BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::d2d:4882:88be:85bd%7]) with mapi id 15.20.4566.022; Thu, 7 Oct 2021 15:41:38 +0000 From: "Chautru, Nicolas" To: Akhil Goyal , "dev@dpdk.org" , "nipun.gupta@nxp.com" , "trix@redhat.com" CC: "thomas@monjalon.net" , "Zhang, Mingshan" , "Joshi, Arun" , "hemant.agrawal@nxp.com" , "david.marchand@redhat.com" Thread-Topic: [EXT] [PATCH v9] bbdev: add device info related to data endianness assumption Thread-Index: AQHXuvT7fi9oDHAlG0y1SYcilMQUzavHhFYAgAAjZGA= Date: Thu, 7 Oct 2021 15:41:38 +0000 Message-ID: References: <1633553929-58670-1-git-send-email-nicolas.chautru@intel.com> <1633553929-58670-2-git-send-email-nicolas.chautru@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f8c8fdd-21f4-4305-ef78-08d989a8f37c x-ms-traffictypediagnostic: BYAPR11MB2614: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qwN6rDDv7zrcdtsjH7MF730z3gGIWOfYEn+QdFaOtyF6398wl6rlZuvg98PiyoU1exycLrqRbdbsfHL6dmaYuCptJZPc7ssxEYb6eZx1ZUt9Mk0vUPu2Nryk5Ix0ajQvZiyltyPOR3SfwnrmUvX1hTkrJGrrnpWOHuWlloC64w11ksNjygtIUGQg8V6RdDzLd/ULaXIgA2loiCAPJm2C0l5QArjyQna1/ZbOjY0773U0pIPzJqJ36W39aqxSI2CLrT0iXxAz/wDfoxBVk/gr3baG9P5en1uWaxKy0v1EPNXyyjIox/beMNJorlHSqgR1Mt+b5ZtOA1p9osSDsmekoa/r/1Im9hRh8NGXH6gHk0Pmx0A5tJw5rXkwDuM52v7PFV1b3F7GjFbEPeaM+TJbIn2xzGM3RLRzp0fQe0+etJJMh+bRnzeVtiuyWGI7bg55LjEKr//HZU+kjG7EAe8M8/pqnogV9hGuZM3kIXHHXVo0cZMp50825umMlwSFzaqm9G/d/4D9tNqg4/ti6cNp8qva5KPlzE325hnf1a13JlRRIV9Oj3EOkQvlMkB0RzhuELkmmFJ0Cq3sWr6BCkX0/4rwrwi1M+j8u88/HXetr0A/LSVv23dVLUZbVRd6cdqzPaixr2bVafXFQ/2Zv0BYhPPsH0v/myxS5HEsOoa47NYTBtx20zvuEb4x3+dcEJ7/tziwXIjmzKPk09ZncVohlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4451.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(7696005)(8676002)(316002)(83380400001)(4326008)(66476007)(54906003)(86362001)(66446008)(66946007)(52536014)(66556008)(64756008)(186003)(110136005)(2906002)(53546011)(26005)(5660300002)(9686003)(76116006)(508600001)(122000001)(38100700002)(6506007)(71200400001)(55016002)(33656002)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HqVIzFU2MaMvmxLhmCSPDRCdJsVM7Cxx+4vmkxvAtW7jpzqUP0OKnxOcQJCK?= =?us-ascii?Q?989mNWcezVC/nqucixpopDhHEd0+SuXK6K9iN9x1wI3LIEeIVMI0ZdFQcPSA?= =?us-ascii?Q?H+2TGO140ckGAG9OgoY2dQ8dvjVjbc8AeJ+rbQRY5tO8/iYoNKUqJtYVw0Wm?= =?us-ascii?Q?w/Aye5E3QFVwe2/hKpe4BEKQZIRC9MckHFT4kf5Ga6B7kMNC4TJORJJ6haUh?= =?us-ascii?Q?aQ4gc4MxllVmQzWESMEakDd6kzFxh0Ug7OUdmcMD5UjeeQu2yqMvBai76JZ4?= =?us-ascii?Q?Luqfagz6SgMWcMkFQlxG6vt5o7Of2Z/RVC2bA/x5papunrFrNsS6CAq9gmrZ?= =?us-ascii?Q?E0DR+JP8RtB5d1BNq3OTUioih8+Se73zg3AC8vxar6udH/xb72ZWPFRMdWv9?= =?us-ascii?Q?ODHg2RwMBlQsvcwIg4cpo2GsqahXf8fco2dqvTOLYRDyhM3TJuk3lRd80UQo?= =?us-ascii?Q?32lUXEvylM/06nqxpt961amSx9U9yxX8Fo7uRmeavflA7qV3NEWXZypaymKD?= =?us-ascii?Q?Rm/6my8w/vg44D54vZ+gNKdtU45Nm+F1CJ8lYdw7X0UKU4sGg4bB3VMPIOkM?= =?us-ascii?Q?lvHx5pxCqbgwv+rTH32gRw9y+zzf6GDSJJpjmT0V0BnAjUD2LB3Q2f1Z16LN?= =?us-ascii?Q?uyxH3WAtvXlaDIb8Aj/d8wMrkADnlA2bTIl01XLjzp4pXhu0yDlAXCsfRkFD?= =?us-ascii?Q?Tau7tR/foxtLZwVIV1vEGMw0vZ+j9/KCFLh3b+QHOz4IF40/+8s8gEitypKF?= =?us-ascii?Q?5PWvWo1IIxG+6/Vz7DBHqxnHr+Oy5LsWz8n1eK2BMh7gKOu9A762JQvnNh7a?= =?us-ascii?Q?QcXh5DUSH+dRhgrc8ShDZqdfKXDUeFE0iqeTVUSxjP7WAFfMsW42MtAYwLIP?= =?us-ascii?Q?yX2pmkTy+5kfrdMVxZ2yg68O1dPniIns8wWDlXwb9BwOf05BUYITv0FB5DzY?= =?us-ascii?Q?dYUDy4aymmUlvUl0BZYvBkJhKMHsCkmQ8hm/LuJt/MxaltDi1w0ddJcS8MbV?= =?us-ascii?Q?v//401h3CVIOSg9qNLxU0l9W3TU1U9o4pwM+4Y0VnMlLNOaO7/34T7wkLojz?= =?us-ascii?Q?kv4sLAR1J6MPnr5PJb9fJiGM99w/b/e+zdLV7PRpw8V6xlwdHIWXbl1JNcKS?= =?us-ascii?Q?Z+XKXXYmRr1nFB00E6ue4dmGtN0Bbb9T8KGEhVP3nUCbgPmu6n0/5DA60RyS?= =?us-ascii?Q?aJJJp2vUzUNls/TvuIWi+NLelRmtdcIDsPMX/vz4WH5P4/3htcD1SE6Yx+Ms?= =?us-ascii?Q?94pxEng2+vQJte05WoDwqC0s+ErssOVffCD1JiBZ11fo0UflDJYiyHRY57FY?= =?us-ascii?Q?tsGw5wU2FMMzrYY6av56Pzm2?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4451.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f8c8fdd-21f4-4305-ef78-08d989a8f37c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 15:41:38.1308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Oed9c0G548L5ywj25KXhtXBrOcz3cShLR6f2TwYIbBJc0ZepTQct6m4a/nEupkSm8OXaPghcgfn04A5IUNIfghKHp9qHZ95MIh6YPPVuAs0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2614 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [EXT] [PATCH v9] bbdev: add device info related to data endianness assumption X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Hi Akhil,=20 > -----Original Message----- > From: Akhil Goyal > Sent: Thursday, October 7, 2021 6:14 AM > To: Chautru, Nicolas ; dev@dpdk.org; > nipun.gupta@nxp.com; trix@redhat.com > Cc: thomas@monjalon.net; Zhang, Mingshan ; > Joshi, Arun ; hemant.agrawal@nxp.com; > david.marchand@redhat.com > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data > endianness assumption >=20 > > Subject: [EXT] [PATCH v9] bbdev: add device info related to data > > endianness assumption > > > Title is too long. > bbdev: add dev info for data endianness OK >=20 > > Adding device information to capture explicitly the assumption of the > > input/output data byte endianness being processed. > > > > Signed-off-by: Nicolas Chautru > > --- > > doc/guides/rel_notes/release_21_11.rst | 1 + > > drivers/baseband/acc100/rte_acc100_pmd.c | 1 + > > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 + > > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 + > > drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 + > > lib/bbdev/rte_bbdev.h | 8 ++++++++ > > 6 files changed, 13 insertions(+) > > > > diff --git a/doc/guides/rel_notes/release_21_11.rst > > b/doc/guides/rel_notes/release_21_11.rst > > index a8900a3..f0b3006 100644 > > --- a/doc/guides/rel_notes/release_21_11.rst > > +++ b/doc/guides/rel_notes/release_21_11.rst > > @@ -191,6 +191,7 @@ API Changes > > > > * bbdev: Added capability related to more comprehensive CRC options. > > > > +* bbdev: Added device info related to data byte endianness processing > > assumption. >=20 > It is not clear from the description or the release notes, what the appli= cation > is supposed to do based on the new dev_info field set and how the driver > determine what value to set? > Isn't there a standard from the application stand point that the input/ou= tput > data Should be in BE or in LE like in case of IP packets which are always= in BE? > I mean why is it dependent on the PMD which is processing it? > Whatever application understands, PMD should comply with that and do > internal Swapping if it does not support it. > Am I missing something? This is really to allow Nipin to add his own NXP la12xx PMD, which appears = to have different assumption on endianness. All existing processing is done in LE by default by the existing PMDs and t= he existing ecosystem.=20 I cannot comment on why they would want to do that for the la12xx specifica= lly, I could only speculate but here trying to help to find the best way fo= r the new PMD to be supported.=20 So here this suggested change is purely about exposing different assumption= for the PMDs, so that this new PMD can still be supported under this API e= ven though this is in effect incompatible with existing ecosystem. In case the application has different assumption that what the PMD does, th= en byte swapping would have to be done in the application, more likely I as= sume that la12xx has its own ecosystem with different endianness required f= or other reasons.=20 The option you are suggesting would be to put the burden on the PMD but I d= oubt there is an actual usecase for that. I assume they assume different en= dianness for other specific reason, not necessary to be compatible with exi= sting ecosystem.=20 Niping, Hemant, feel free to comment back, from previous discussion I belie= ve this is what you wanted to do. Unsure of the reason, feel free to share = more details or not.=20 >=20 > > > > ABI Changes > > ----------- > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c > > b/drivers/baseband/acc100/rte_acc100_pmd.c > > index 4e2feef..eb2c6c1 100644 > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c > > @@ -1089,6 +1089,7 @@ > > #else > > dev_info->harq_buffer_size =3D 0; > > #endif > > + dev_info->data_endianness =3D RTE_BBDEV_LITTLE_ENDIAN; > > acc100_check_ir(d); > > } > > > > diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c > > b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c > > index 6485cc8..c7f15c0 100644 > > --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c > > +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c > > @@ -372,6 +372,7 @@ > > dev_info->default_queue_conf =3D default_queue_conf; > > dev_info->capabilities =3D bbdev_capabilities; > > dev_info->cpu_flag_reqs =3D NULL; > > + dev_info->data_endianness =3D RTE_BBDEV_LITTLE_ENDIAN; > > > > /* Calculates number of queues assigned to device */ > > dev_info->max_num_queues =3D 0; > > diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c > > b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c > > index 350c424..72e213e 100644 > > --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c > > +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c > > @@ -644,6 +644,7 @@ struct __rte_cache_aligned fpga_queue { > > dev_info->default_queue_conf =3D default_queue_conf; > > dev_info->capabilities =3D bbdev_capabilities; > > dev_info->cpu_flag_reqs =3D NULL; > > + dev_info->data_endianness =3D RTE_BBDEV_LITTLE_ENDIAN; > > > > /* Calculates number of queues assigned to device */ > > dev_info->max_num_queues =3D 0; > > diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c > > b/drivers/baseband/turbo_sw/bbdev_turbo_software.c > > index e1db2bf..0cab91a 100644 > > --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c > > +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c > > @@ -253,6 +253,7 @@ struct turbo_sw_queue { > > dev_info->capabilities =3D bbdev_capabilities; > > dev_info->min_alignment =3D 64; > > dev_info->harq_buffer_size =3D 0; > > + dev_info->data_endianness =3D RTE_BBDEV_LITTLE_ENDIAN; > > > > rte_bbdev_log_debug("got device info from %u\n", dev->data- > > >dev_id); > > } > > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index > > 3ebf62e..b3f3000 100644 > > --- a/lib/bbdev/rte_bbdev.h > > +++ b/lib/bbdev/rte_bbdev.h > > @@ -49,6 +49,12 @@ enum rte_bbdev_state { > > RTE_BBDEV_INITIALIZED > > }; > > > > +/** Definitions of device data byte endianness types */ enum > > +rte_bbdev_endianness { > > + RTE_BBDEV_BIG_ENDIAN, /**< Data with byte-endianness BE */ > > + RTE_BBDEV_LITTLE_ENDIAN, /**< Data with byte-endianness LE */ }; > If at all be need this dev_info field, > as Tom suggested we should use RTE_BIG/LITTLE_ENDIAN. See separate comment on my reply to Tom: I considered this but the usage is different, these are build time #define,= and really would bring confusion here. Note that there are not really the endianness of the system itself but spec= ific to the bbdev data output going through signal processing. I thought it was more explicit and less confusing this way, feel free to co= mment back. NXP would know best why a different endianness would be required in the PMD= .=20 >=20 > > + > > /** > > * Get the total number of devices that have been successfully initial= ised. > > * > > @@ -309,6 +315,8 @@ struct rte_bbdev_driver_info { > > uint16_t min_alignment; > > /** HARQ memory available in kB */ > > uint32_t harq_buffer_size; > > + /** Byte endianness assumption for input/output data */ > > + enum rte_bbdev_endianness data_endianness; >=20 > We should define how the input and output data are expected from the app. > If need be, we can define a simple ``bool swap`` instead of an enum. This could be done as well. Default no swap, and swap required for the new = PMD.=20 I will let Nipin/Hemant comment back. >=20 > > /** Default queue configuration used if none is supplied */ > > struct rte_bbdev_queue_conf default_queue_conf; > > /** Device operation capabilities */ > > -- > > 1.8.3.1