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 36256A0C47; Thu, 7 Oct 2021 18:49:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0858411DB; Thu, 7 Oct 2021 18:49:29 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150040.outbound.protection.outlook.com [40.107.15.40]) by mails.dpdk.org (Postfix) with ESMTP id D82D6411C9 for ; Thu, 7 Oct 2021 18:49:28 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mdZ5tVJcs1jwhd2iN8qMeimWWHsKD3l7nDZHQsNIrI2DfHjtzsWjUSAH7X9MaELscWG+ilrptnsI3ZyzWgyE9tbYjmodE2fGNf9KGGFjnVdfrY0Za5lNxWv0Je8mHZY3vgekVq+KNnBP9UGRml5GR7ofi7woGu9I/dE1apaa5QrlGKxDX7czkXKpDtlSkfYFfRkAIrEUMwDo4iUYmupOkB4/u6Kt1udEgH4IMtLKOvnw6+ATGW80xN4j+9jhQJsrtiUgZqTB4Pe5BClx5E6kIXtgeZzxQ8nrkguptY5TvH8LE6/tBWLJjYmCm0bEU02b3Zwfe0QnHKdfT4FRL0b6DA== 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=Lfm/gJAmYa2MtqmWMUJQaTgwntDH/FjYctiFwfO+iBI=; b=E38MmOWaAVJX8kOL4IFHLPLc4ZaowjKFxtnkl+3wIBMr61YG4A9DdngJOkfVmHfQroDBDe7Z7F7IkWqBBy24quKIWdzLbTuSo/1XOZJjC1WWWZ6H3Ytg4KOsi7LJ3/U6hK0YwPJXpS5RTWi8kk6A6XKvMzBtL9eY4vlMlmAZq5mBbcN6Pkn7i4YcFsfpz6bHudTYfJ8RODB0vSCeO+92UWxPiqLe8tnxnU9eoLqF3taoEW1u8pB8mK1mD1Izwl45QYuhjK+u2jLGqy9xTFcU5yUZOgh4nGf5HybkD1dngalgoRY4N+ipbNfsxZ2qZS2Vt8qQ30R1nniT3ukVgeCLvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lfm/gJAmYa2MtqmWMUJQaTgwntDH/FjYctiFwfO+iBI=; b=LnCH5m5B/83Qpyp/Zsb1QrECooHLZ/2DaC6Yaq8npcYH6yzKLERdpSfkBoQbBuy6nJPCsHe7qYuVS3IkfxZjER4YuegQBRhcnyJToTb9w2X6GnSrTuFTadsfk/Mn0WvPqsI5sUvWqM1tXXLfFuCMdygtBC908rTeew7R4I87p8E= Received: from DB9PR04MB8429.eurprd04.prod.outlook.com (2603:10a6:10:24e::23) by DB6PR0401MB2504.eurprd04.prod.outlook.com (2603:10a6:4:36::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.19; Thu, 7 Oct 2021 16:49:27 +0000 Received: from DB9PR04MB8429.eurprd04.prod.outlook.com ([fe80::dcda:93c2:47e7:19b4]) by DB9PR04MB8429.eurprd04.prod.outlook.com ([fe80::dcda:93c2:47e7:19b4%9]) with mapi id 15.20.4587.019; Thu, 7 Oct 2021 16:49:27 +0000 From: Nipun Gupta To: "Chautru, Nicolas" , Akhil Goyal , "dev@dpdk.org" , "trix@redhat.com" CC: "thomas@monjalon.net" , "Zhang, Mingshan" , "Joshi, Arun" , Hemant Agrawal , "david.marchand@redhat.com" Thread-Topic: [EXT] [PATCH v9] bbdev: add device info related to data endianness assumption Thread-Index: AQHXuvT6uqqx3EsLQki3Nmb9BGzXhKvGdAGAgAEQVQCAAClhAIAADZlw Date: Thu, 7 Oct 2021 16:49:26 +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: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nxp.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a589af75-ec57-4ea6-2c82-08d989b26cbb x-ms-traffictypediagnostic: DB6PR0401MB2504: 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: aD6fONL23wzsllTMO1H4H9p37qKejjulKntPg2Hl8uhodpe8VkuGtqJbUXBOqU+s8mlFQwjVwDDPRkhQzOrHXnrYemDcD2BEKod7UpBEhgvPTuvZunueoY6awT7okqx3rU02B8emVl0u2/6iPdoMo3iTdDj0XyXLnSEiPxp98wOEFKDZsilgL+6NptTiTIFg326eX/WjS0r9bfiw1fPBXIsPEJTJ5yMjL2BeYax5TlxuwUiYpWI2tvRdBBa34nIJMkob/PWMBPGFqe0Uo1rU97dlF7ZassQz72/BxJG0FLGlFBuRZUwOM4ZW7YSTeryT+9CxGfXjC2J1N6pWC5XmkkGIIug70/8vi6gSpiTWIt0mqiL3xmcFlWZGuPMbi0y1kXgOqGA98+Z2y+aU7BybPDxtnjO19O8t0sPn+QaLedMRtryg6ItjHYtNbVElQe07tc9TGuvjS3V1aZo//uwncynR/v60P0SgeGjrQuo0/WAPNjGNT1YTwc9vwy7E20VED8qR9JcE+214dhHHDwdkykX7vzmE8ko85zXyGglZ9/7VsFLLBXdeQBpgrytYnYdSYOFPvcxg4ViAfzSH3P8e+nir6tiKW8aMTJN+/2zEAFSmEt8QEFXJ0me888Dbf6pO1HY8uOF/aA+zT6zJoKTVztDW6fcOCvOr5rStmUN5xZgYc/EObodSRFjVmoRjCDCTbLmy79BAum9Ug+MTf9QV1w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR04MB8429.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(38100700002)(316002)(55016002)(5660300002)(8936002)(44832011)(508600001)(66476007)(66446008)(122000001)(33656002)(66556008)(8676002)(26005)(9686003)(83380400001)(66946007)(76116006)(2906002)(7696005)(64756008)(86362001)(53546011)(38070700005)(4326008)(54906003)(71200400001)(110136005)(6506007)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GTxnsCdGoeWxpxquR+653bod8NaD7dQFvd21PeqRrnqemgAOZRNmB6LJd5Hq?= =?us-ascii?Q?UZIpNOziz0BZPMmFuztO/1DXufF0nLnTId8cGO1XVSUvYezpQRMcbPNLcAnB?= =?us-ascii?Q?j5kclMJZ/q70k9/z2cGz4ZOfw1+OopEop0rtShKnYKoOmbTqETObTmXrgJuy?= =?us-ascii?Q?2sMfhx+3eHJBFO30ivDGUutQFI8+psK+ea224aaOg9f5NRyS6imofIp4AVEX?= =?us-ascii?Q?E+/KYNUqxibKu+kmSqQ9VlgUPa8FWoLt2SBH/LmZZgSIWl/cLNTNf4XAxGU5?= =?us-ascii?Q?jbbWb9fEOlV/K6rEG9X7Huqm/RinqAZjE1QSyyDoMKecXZd/uf9rkyWAr13F?= =?us-ascii?Q?QYi2RQQkvqa77L+LgZ3wffDirYe61l58jQ9yjrZ+2UaiZcGtLpeSskwxw2le?= =?us-ascii?Q?6mwPzEP5VSfw14C7CWbOw5kxYR/hdiQn5shaRuHbK+OZPBA52PKo9hYQXRwF?= =?us-ascii?Q?F6mLQGe2vYGafnrPtLrA0z75riqnDYJMDkE8qIhoQ+3/V2i/bGjSfdTTNILu?= =?us-ascii?Q?GgvCWyvJmpuEvhWiW3EZpm7m9iLl0gRevf0P9e1BU76hZzNf+qQTn4p7Cuep?= =?us-ascii?Q?BxsvcFVG9G29jgbDfunZxys49aqwHh/BTeP7+zBAQ3c12sVN3XHqnFZATpw7?= =?us-ascii?Q?zcme7OGCmb7SouTQ1yZf4bu2d8nx+w+lJxHCqmMS7cosFZyKhAir5vlxEqoF?= =?us-ascii?Q?LTJrmU+M8mz3KHzMvObGjc+qzKLslra8nr+0JJHOomN7yD/1xW4gmkRVlht/?= =?us-ascii?Q?fMyrkxE2itixWuzIhDLnm2F2e91P+9bj2JxnNGrCv1avsYs2QASjsPytjLFr?= =?us-ascii?Q?zKSc9U12+PA3GNjMiLN9T+tcH/gd4uN22ZoNO6ITkV1+JwGv9/aPRgsqLW6D?= =?us-ascii?Q?UkutxZ4mhRVfrv/GzpeGYcrJoBsgEHB7cqsIFBr1iidoNNjts8Illzj9JBdS?= =?us-ascii?Q?l7aGf6Vp9JTopHxJNDOy0L410fy7aeGC41f4QLSWZN9xJ1krlFA+LAz/UED4?= =?us-ascii?Q?8+DXDchVQeLKSFAAIuNZbr0TSAcL2obpOlFmlpCCX6CUuqhVf9lVpuLplwt/?= =?us-ascii?Q?fBgxTm82Cl49CpyKL6/hqrR0wsI7O2W0LKCYl/VW8JqCbrUmzxQGyLhef1SL?= =?us-ascii?Q?Q7DbCL5pHf/QVnULkaWtBTqU2kUH6kzEVyytmHaVlkkmoHsUzd8Ae1PX0cNQ?= =?us-ascii?Q?dFTl/UIVw6lsGiUFlUPAAJ+lg+dj8TjXMGrzHVNDln5a8tl3kkwXSeuHveOf?= =?us-ascii?Q?0FmbCvWpz0olpXM4gNTUBfmWc25EhPQRbktdrsZvKRP9BDVCLq7PUAF6CK2s?= =?us-ascii?Q?oeE=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR04MB8429.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a589af75-ec57-4ea6-2c82-08d989b26cbb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 16:49:27.0289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NaGtO/A7PhEyxkeADKIzEYMyfhg48ClszHBocoO5IeS1k/wH+wJz/n2YSfM+8QehhoBhCiXN3y4Qi/WO8J/RYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0401MB2504 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" > -----Original Message----- > From: Chautru, Nicolas > Sent: Thursday, October 7, 2021 9:12 PM > To: Akhil Goyal ; dev@dpdk.org; Nipun Gupta > ; trix@redhat.com > Cc: thomas@monjalon.net; Zhang, Mingshan ; > Joshi, Arun ; Hemant Agrawal > ; david.marchand@redhat.com > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data endi= anness > assumption >=20 > Hi Akhil, >=20 >=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 > > > > > Subject: [EXT] [PATCH v9] bbdev: add device info related to data > > > endianness assumption > > > > > Title is too long. > > bbdev: add dev info for data endianness >=20 > 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 processin= g > > > assumption. > > > > It is not clear from the description or the release notes, what the app= lication > > is supposed to do based on the new dev_info field set and how the drive= r > > determine what value to set? > > Isn't there a standard from the application stand point that the input/= output > > data Should be in BE or in LE like in case of IP packets which are alwa= ys 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? >=20 > This is really to allow Nipin to add his own NXP la12xx PMD, which appear= s to > have different assumption on endianness. > All existing processing is done in LE by default by the existing PMDs and= the > existing ecosystem. > I cannot comment on why they would want to do that for the la12xx specifi= cally, > I could only speculate but here trying to help to find the best way for t= he new > PMD to be supported. > So here this suggested change is purely about exposing different assumpti= on for > the PMDs, so that this new PMD can still be supported under this API even > though this is in effect incompatible with existing ecosystem. > In case the application has different assumption that what the PMD does, = then > byte swapping would have to be done in the application, more likely I ass= ume > that la12xx has its own ecosystem with different endianness required for = other > reasons. > The option you are suggesting would be to put the burden on the PMD but I > doubt there is an actual usecase for that. I assume they assume different > endianness for other specific reason, not necessary to be compatible with > existing ecosystem. > Niping, Hemant, feel free to comment back, from previous discussion I bel= ieve > this is what you wanted to do. Unsure of the reason, feel free to share m= ore > details or not. Akhil/Nicolas, As Hemant mentioned on v4 (previously asked by Dave) "--- If we go back to the data providing source i.e. FAPI interface, it is=20 implementation specific, as per SCF222. Our customers do use BE data in network and at FAPI interface. In LA12xx, at present, we use u8 Big-endian data for processing to FECA=20 engine. We do see that other drivers in DPDK are using Little Endian=20 *(with u32 data)* but standards is open for both. "--- Standard is not specific to endianness and is open for implementation. So it does not makes a reason to have one endianness as default and other managed in the PMD, and the current change seems right. Yes endianness assumption is taken in the test vector input/output data, but this should be acceptable as it does not impact the PMD's and end user applications in general. BTW Nicolos, my name is Nipun :) >=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. >=20 > See separate comment on my reply to Tom: > I considered this but the usage is different, these are build time #defin= e, and > really would bring confusion here. > Note that there are not really the endianness of the system itself but sp= ecific to > the bbdev data output going through signal processing. > I thought it was more explicit and less confusing this way, feel free to = comment > back. > NXP would know best why a different endianness would be required in the P= MD. Please see previous comment for endianness support. I agree with the RTE_ prefix we can add it as it is for the application int= erface. >=20 > > > > > + > > > /** > > > * Get the total number of devices that have been successfully initi= alised. > > > * > > > @@ -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; > > > > We should define how the input and output data are expected from the ap= p. > > If need be, we can define a simple ``bool swap`` instead of an enum. >=20 > This could be done as well. Default no swap, and swap required for the ne= w > PMD. > I will let Nipin/Hemant comment back. Again endianness is implementation specific and not standard for 5G process= ing, unlike it is for network packet. Regards, Nipun >=20 > > > > > /** Default queue configuration used if none is supplied */ > > > struct rte_bbdev_queue_conf default_queue_conf; > > > /** Device operation capabilities */ > > > -- > > > 1.8.3.1