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 F0E23A0C43; Thu, 7 Oct 2021 20:58:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BA13941217; Thu, 7 Oct 2021 20:58:44 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id A8716411E0 for ; Thu, 7 Oct 2021 20:58:42 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10130"; a="226288177" X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="226288177" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2021 11:58:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,355,1624345200"; d="scan'208";a="458899035" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga002.jf.intel.com with ESMTP; 07 Oct 2021 11:58:36 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX605.amr.corp.intel.com (10.22.229.18) 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 11:58:36 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) 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 11:58:36 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.175) 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 11:58:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c4XkgRJ9w956pPsrCTYKQr3JVKDs3MnzSWOhXiqHQ1JU9ykHuuAJAgc2Dm395ytWb76NPioQq905NbWYChgC556SY0032+pxC1ym1TI92hEs5f5P4HhGDh50fvvkwmPojMT/L/6cIeAttAVTLc6dls3T4nzzw7OarL1K3grWtcixaEs+4nxtFd9ZR/C5+PGRihKjWMudx01ZPrkMPTjJO1W1/4JILtUX+yRdMLsbYAHkIt/qupvIFrv1nZNTdqvq+Q8IxCpy85wUwuurWyztllYqgWi2EtrLvaWwu/Ngbn8Bh8tCUsaBCqtBzt+qbO+El2TuU1v1mLCM1szleClVyQ== 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=AUfMUpBOh3T1+g4loO0WQoKabgBBugkvpeGsncs/On8=; b=LPmHrXOMjE51sSeW4ElNoP5yV8W+t5wrY/xMzp8m0/fcanDcTbhWO+cXhFEGqNWhKUcB5wJmArIlFj/s1oU0RvVRhraKj9nHbsXeBN/HwwU1kpvD/9VjupdNgFSjOGBwWf1QObe4xGwnkWoz+91I8l+MOIHXC0ElKBxhRHaIc4VAaR3ZE6KbeRekmZgTai628xUGeHcf5fVqRTG7+qSkvzFokI+2hnnJYiHf2OIv/NBFJWavOmZbIK5M/WElNHtfhlHTVV3/6BwZBOm2q6a5R5q5adD+Caof/hIIjNSmFxebH5mxJkL4n3akzqXMlB2Pso//SY5QGrKJFHwL8ot3KQ== 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=AUfMUpBOh3T1+g4loO0WQoKabgBBugkvpeGsncs/On8=; b=Akz4TbQXcMy2KCKMAVcRr73uc0T05h+tECnlO4aFyw3iZNt8E6n3erOpCC+2rTqdFibkTkT+/aZsELmicbTrjYpxFnl2M6QednvMUDNDwcdJ+LwvFxi/Huqqe1/oNQHOB1+ifV+kv/0pWW8Tc4WJjahhLfob+Zf7XwO9AfWrtXE= Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by BYAPR11MB2965.namprd11.prod.outlook.com (2603:10b6:a03:82::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Thu, 7 Oct 2021 18:58:35 +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 18:58:35 +0000 From: "Chautru, Nicolas" To: Nipun Gupta , 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: AQHXuvT7fi9oDHAlG0y1SYcilMQUzavHhFYAgAAjZGCAABjvAIAAIY/Q Date: Thu, 7 Oct 2021 18:58:34 +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: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f167feaf-1d3e-4f8b-3e51-08d989c476ee x-ms-traffictypediagnostic: BYAPR11MB2965: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2150; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0NhgEtHa6KwL/wQguWw0pdBiqXXy58MlnX9Q3foMBEJtzBLqbl7yfhDFSf5DRba/dBUPhhJeV5jxAdyQ/zuDViiOWU81lbaM4oEnQcpkbHflq7/MYnTSqZG5wsuXmpFNCtul3QdEcQD9iyB7L1Ixt9iDHArUk4XreIxAeA+mHhpnIWLmwB8lxUzVD5JCfElFcPdbD3vB7pvhE42GqikBgcldpl2iE3Tmdpyhq/SnOwh1Vm96EJGM27XLKBNPumDqw5Ds1gxJbK+1KeUSOha/wBSD2rljqvFaQqCRC/5MEX4XQMSvcVNB2kQFaS0q4eMG1lL4oK1qMIGwM4o3Fqu9o+GwKnLD3lb4g5E9bphMCtPaL3AaxWIA+SYP1BfEQ2Vui4E6fqJwbG7FiI7sN1cM9ZFeBuVi2c6hk6xOdVZrM4qpbshlIunm/JcP7fr8IFhDasdoZyo7OHLuc0v4EfN15datV+txBT8y/M+xqrUnKtD+5Gh65Kjxb7jk7Fj1ksOT6lPgQZJst7yTnZxR6a1bAvkH0nwR+qNnwPdR3duje20ryrljGMg17MftHFkJ0tkjspiTP9LZmexXLP26L8omZjbD4NS80O/AFx55CW4gClk02Ps9AoLa2fs7b7A2Mnm7WKfnpZhsGskjxDsWZdiu9uPwhIt4qh7uQbY6VRiJO5nK3K8P9QNo2aN6DnRXn0DtjkCzb9WnRM5LkE2+y2cA5A== 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)(76116006)(66446008)(64756008)(66556008)(66476007)(5660300002)(4326008)(38100700002)(2906002)(186003)(8936002)(26005)(38070700005)(66946007)(83380400001)(7696005)(71200400001)(110136005)(54906003)(122000001)(55016002)(53546011)(52536014)(8676002)(508600001)(33656002)(86362001)(6506007)(316002)(30864003)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?USBxd6z2gZJ6Oho0kr2kcXD8NHJTP/sFVqesPCNzStdnA8qlCV0nZasZ/7X9?= =?us-ascii?Q?fseXqOWofNzVxUXhKenrcQOCE90cTAwhJCd39UzR2oZlqJC+sLOv16eSLLz8?= =?us-ascii?Q?Nd9Am83d/FD/Twh5wIvJ70qtJ8KSograQ454tvM/xnvkepCOqOFqTAoxzjgO?= =?us-ascii?Q?7N3tNgXg9Y0GSJudZUktz3UPIRZeEUZjPhbfZaSGdU5lW/+OCojj5bt16YUQ?= =?us-ascii?Q?WCzURkb/pgpDzsbwbGInLh359RWLZ2gZUwApZpJp3aDkMYME1kEj/tQAAJKu?= =?us-ascii?Q?nDZXX4gSUXiGrX4vGIf895rT9yHsd4FbJomDxqgD1mlercMv8bDHmWyBimgk?= =?us-ascii?Q?p5VzaLQkRQtvM6YCNQFtitLeBUtXqODGbwHJx8lPHHFxgOAn6H1O8mWm8WEO?= =?us-ascii?Q?al5CqQoXpVw32n4AUF0npTLeL5OKacDsyvAj6Io32cjfUC15V/NBi9cRTCPZ?= =?us-ascii?Q?1FRIRhojDSRm1sL2/ASSy/LSWamOfQ69igneDIBK/vphoSX3vRfhaEndqphm?= =?us-ascii?Q?hVQCsPgyX44y9kZpqz0Gqk31KalkvX4gYDGMHdRVDIMldsP/7fThJo2D1g9S?= =?us-ascii?Q?ziFBB9S4MxrQwXMV8dZf9ejWNSa1FOl7FFKMQqrv9LYVAIEWPJMhkpQ/D8xI?= =?us-ascii?Q?0Pey+7LgWPd6/88PLZ4DB6qoYj26icz3KazyRPazeGKi51qDql6p4mQ5bDIq?= =?us-ascii?Q?8LGtWHmDHJAPRk9vhDgdcvr5zwao8EJRgt4VmKDOElBUTgJ85Orob9lJEFZU?= =?us-ascii?Q?SmabN+Ocrq1RSNcV1h3jcDY+keHwl+lcJtv/1QzUIfasVS5fyuxsFeCYV8US?= =?us-ascii?Q?wkcXpDZbaVbzPZhlq2EW/sU7vKx1ZQTBZFLUkSE5PcnMyASvjxV8K2ZJ/CVi?= =?us-ascii?Q?Jhdf9fTLHRW6uZxKF9xLH2Jvu4wAZziWIlzwTxWRuP5Rlno0R6WpQEhJkdKK?= =?us-ascii?Q?sQTXgxje0G1H5aVzOn8bF7MC2xx5KZOZ6gK97Id+axUF6ihkUjXbWfa166SX?= =?us-ascii?Q?Gv0L3YLHQ2kannbEyPX2oObauE0dHHje8P8JvkyBqDnekmiK3QKF46fk90Rh?= =?us-ascii?Q?FTJg3mT6PP6ECEMRQ1dmLn7gKo8+qVO9yrGujfAZ8igrswebBZ6/5Jy2fvud?= =?us-ascii?Q?XgjBtRVvr7SWGHLDnUuuqb/2uCeCEuKFuoXWHsXoYedzK+RhRXkDFCB8/Yie?= =?us-ascii?Q?LOnOwfuvu0A1sAmvCrDTNDlhM/YzgVtfDMSBeVWHDmkalIH0/6ibHwZYrjja?= =?us-ascii?Q?ZWOzM7Vlv8VJxegBtjAuhzd1Mazyw7icKTSTxycmQq5If9GsixrxiW8B+nxv?= =?us-ascii?Q?+qlHHDHtDe5r9LhNeOe0H5pI?= 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: f167feaf-1d3e-4f8b-3e51-08d989c476ee X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 18:58:35.0376 (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: NynvAPynSIbM6HebUSu+fsiyOP1RmXLedk9Aibg1v9fQN2mNqAkPE1rA80u1GGa7eX5zhPvKvpN4m4TyRstCPqtNmT2zNbH1XOF/9s1qaC0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2965 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 Nipun,=20 > -----Original Message----- > From: Nipun Gupta > Sent: Thursday, October 7, 2021 9:49 AM > 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 > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data > endianness assumption >=20 >=20 >=20 > > -----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 > > endianness assumption > > > > Hi Akhil, > > > > > > > -----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 > > > > OK > > > > > > > > > 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. > > > > > > It is not clear from the description or the release notes, what the > > > application 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/output 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 the existing ecosystem. > > I cannot comment on why they would want to do that for the la12xx > > specifically, I could only speculate but here trying to help to find > > the best way for the new PMD to be supported. > > 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 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 assume 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 > > believe this is what you wanted to do. Unsure of the reason, feel free > > to share more details or not. >=20 > Akhil/Nicolas, >=20 > As Hemant mentioned on v4 (previously asked by Dave) >=20 > "--- > If we go back to the data providing source i.e. FAPI interface, it is > implementation specific, as per SCF222. >=20 > Our customers do use BE data in network and at FAPI interface. >=20 > In LA12xx, at present, we use u8 Big-endian data for processing to FECA > engine. We do see that other drivers in DPDK are using Little Endian *(w= ith > u32 data)* but standards is open for both. > "--- >=20 > 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. >=20 > 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. I want clarify that this would impact the application in case user wanted t= o switch between 2 such hw accelator.=20 Ie. you cannot switch the 2 solutions, they are incompatible except if you = explicitly do the byteswap in the application (as is done in bbdev-test). Not necessarily a problem in case they address 2 different ecosystems but c= apturing the implication to be explicit. Ie each device expose the assumpti= ons expected by the application and it is up to the application the bbdev a= pi to satisfy the relared assumptions.=20 >=20 > BTW Nicolos, my name is Nipun :) My bad!=20 I am marking this patch as obsolete since you have included it in your seri= e.=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 > > specific 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 > PMD. >=20 > Please see previous comment for endianness support. > I agree with the RTE_ prefix we can add it as it is for the application i= nterface. >=20 > > > > > > > > > + > > > > /** > > > > * Get the total number of devices that have been successfully > initialised. > > > > * > > > > @@ -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 > 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. > > I will let Nipin/Hemant comment back. >=20 > Again endianness is implementation specific and not standard for 5G > processing, unlike it is for network packet. >=20 > 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