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 D5967A0C43; Fri, 8 Oct 2021 06:34:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 53C024067E; Fri, 8 Oct 2021 06:34:49 +0200 (CEST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2081.outbound.protection.outlook.com [40.107.20.81]) by mails.dpdk.org (Postfix) with ESMTP id D0C024003C for ; Fri, 8 Oct 2021 06:34:47 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d419kTq9eaLcrFB0Cpp0Jy2+0Da+wdCEF9cYuLUXVmZzOlUclik2XmuZ2bmYCdV9BiLK/F590m+j7Dl8a6CU2qCCNuIR4tSEOCf7bhE1Z5mTaEXdA0CL3gdhpA6cqjJqD4ooGqMUddcdCRKGf5iCb9ggQFY6cE/X1/CcfoBNlvSZkwNW/jzPLt6/8dl4J0VgvnPCpyQ4f4xj5s5OcPgnqHby+A1L+MHDuG1JfIa/VJgiTm7SosOcVPwEZ6Lxir9nxuHVX9alfOa63hsC/lYZE3IhX6fGn88dazcshlw8xtpufBZyXBaj+OcsMbaOrpqKanR5XQ3BaKwEo/5fooMgTg== 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=xszbRmQp+uuWFO9EelI83fqAFVIC3HqWgccwLnsN3m8=; b=gTW56T2qkgpbsdNHvJf7hmU8JI49yhEgQyniZPqq5ZVw9AQBzrT4P+S5gmxyrK4tEHGKRq1ep/uS1oLlNxVSIQwy17fheOI1UEhm4sY8DkSAkNhiXjoL6sprnj+cxgMDatQQhOMVnkAMDdUIMRtziAxwFlrWjSFt9osbTw4HTtNVDKMbHAy8HpGrFpvdMXr5NLIs3v4JV8ckLJD1Y4ksLU69gN9Av0ee3GNiTmuTg6+U5aQ6cirt6J6SnfYnla1jMLsDOLWcjSdaAydRGX9hTgQN8Nz5AmTIU/W48J8vTyH/ftybJsGcyEaxLguTnEbY+SGGuit0EqRo+4HymcLbHw== 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=xszbRmQp+uuWFO9EelI83fqAFVIC3HqWgccwLnsN3m8=; b=UyQJTXmOe+8C1qtc9PW9EeA28QuEbmMXoYlPTpvcahbESrZhfV6dGCjl0Gl+Q5lK/BMiK8lmvT5x0LsX765flBR7rm6r27Gss0Yk+mhAEhem1esutvR+mW2VsHcvHDVbtM9VD+NYS/QPgC2Vl1PddVfWFXs5ARnd+PcuV4w/RCY= Received: from DB9PR04MB8429.eurprd04.prod.outlook.com (2603:10a6:10:24e::23) by DB6PR0401MB2503.eurprd04.prod.outlook.com (2603:10a6:4:35::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.21; Fri, 8 Oct 2021 04:34:46 +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.022; Fri, 8 Oct 2021 04:34:46 +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: AQHXuvT6uqqx3EsLQki3Nmb9BGzXhKvGdAGAgAEQVQCAAClhAIAADZlwgAApbQCAAJwwEA== Date: Fri, 8 Oct 2021 04:34:45 +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: d05b0a18-bdd9-4627-1660-08d98a14f4d6 x-ms-traffictypediagnostic: DB6PR0401MB2503: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2449; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jVlCgHieAYmmTPG/cPjA1vBtPbr3PDA2JywPCAY3SEnAf8G8IKN4rGKUO42GG7Tzww2xCYqLRWsZPq1UgC2nxEMMjbVgBzaepUkYlWpcpg2Yq24qg1l5zAsAg+LfkeBHjfe6yn1xm94Y4xwUTMUB4NCFCX0O9O1OBeddNLfNCB4GrTBzf2yepmj9p/ir6if3iqzIQBVdn8Lk1zj9fXTcvkJM+HUpa8AYm6hcByxORcQtLpWK/YDL4mqcWxjoJHLuNJZWu144G50oSDNAbNbv6TxuAbAUkLMI72wUPbCe9hON4EpB2G4rRT6tjXeiwSvSLBfD9cUWdbxRAE74efh06lp9GzozhkoPYN/NstUBSUjLadpXBH/XmaHbQciKOwk4I4UXgOF5lLikE1/i4rR5fBy0aJiQedr7o9BSDtAH4HbT4EF9E2AFqeWLWK2ZfMBEPqwc9Rd4i/oJwoXgm29YLmUjiKNDgQZzkXXXd8HJOy5S5u0N2RY0gYR+RkliLZta3/yJdOCoow6EZy0FsqdgpXm5kvyWzbKkVSLdaUSYcw+84ZXvL4t5DECLhMQi/8LA4/nocJrLUHKxcRULPUClbO1w4BTVmAvD2egb5VtdemmmwQWIWodxLs1jmFtl4+kg3kf3VszL7Mzi74Yxgi+5bkPyPJq/znqmBRuIitKbk5I0pBhIqAYLKL1hKYfD0u/03Z/5xvpRqdPLYRQ/SC6MFg== 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)(76116006)(52536014)(55236004)(55016002)(66446008)(54906003)(6506007)(64756008)(66476007)(66556008)(66946007)(53546011)(44832011)(9686003)(26005)(8676002)(7696005)(30864003)(86362001)(186003)(2906002)(38070700005)(4326008)(38100700002)(8936002)(33656002)(316002)(83380400001)(122000001)(5660300002)(508600001)(110136005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?YapGvR3qxZEq2nqke71nXM0yK414UAc2BAsZzEdgdGmbeAPrudn15pjKbuvH?= =?us-ascii?Q?EDdbz3IHiQQPYE0XaKqgLG2OkEVpO3WOmaS+grHtNYuBwa3qRQ5SBRh0L3HI?= =?us-ascii?Q?xKBzTXFDa257o/5UnxeAo/gs2MD0vLIJdadefa4o8wGZ1NQWMuQ/VBqJojqg?= =?us-ascii?Q?nwIoafgI8QzwPfRBl4K8BJJ+dEoNB5sIchdhE5eFfDHPnY2DwBX+NiqTvVMQ?= =?us-ascii?Q?pLE3DCJVs3MVlI1ZX1Jfcf1QT30x5IObaLP4pCYt55N+oucfQHeW0598BIPA?= =?us-ascii?Q?3/+8P+ze7lcXN0Cxc3ufhjdQoM/iS5CmgUTucoabmGtov5M53+4V26u8+WMH?= =?us-ascii?Q?QHbbz7ueR1zrKUIS47UkP82hzdaHxGEFvsluCyB/lIXDFrpCS8RBj3m2O4QO?= =?us-ascii?Q?Wea7AUSWNBElTYNWqNnWgykW366rv2a1QyhCiVyB25YEIWPTy7a/LIuCgx0O?= =?us-ascii?Q?zDq1j+CuloGqRaoMKPijmLe3pUiKu5GTDiFyqU9ysmavN7Eu1wO+bWqFAvO3?= =?us-ascii?Q?WPg7EfcCltQ8UZxJx+iFyggmCo1RtPZ5Q8PzzSEYAInGOcgltlqKjL+Z7QtN?= =?us-ascii?Q?AsbF1nciy1omEfzOz1rcVwg9XiI5exvKGxdVYFRA5NbYOvJGT8yqfBwrAbd1?= =?us-ascii?Q?8Wy4K6GaLXde7IzcN+TDCEpAEdJG8Vq3v+/BG/e98s5KdRwG8nfy3bw8i0+N?= =?us-ascii?Q?mXdLB0TfXQ+Ke/IOkY7/aWEnt0qikmLk1BJ1HIBD2zhtrSsmbOkkwSS13QQm?= =?us-ascii?Q?XIMxwiIeuMlQxsOqeIDJ0qR3x0jqo6MN2mFTC8aBWIknCdsxz8a/yv0VR8y2?= =?us-ascii?Q?6rFVvNsMH/GYgY6Z+9BFZEXt7PTghZ5TDVww6OkvC9yCO2iYOzp/pb5Ho5bc?= =?us-ascii?Q?IWCC17NqV5LY5rLTq6RnZKB4oxmqAwjbe6EPEqxsxJhdEUogrmTOZgwqAdIQ?= =?us-ascii?Q?xZRu6u/TzTTuYcZZuW23HVLDpkD4shXE4iod09GWseT27gMsh3Ys3WK9t/yO?= =?us-ascii?Q?kgIJJACF+wIm9lOfESqtLd7qq036IRncKAxrsf3qZbuoLSlqA5hCgBCcM7G8?= =?us-ascii?Q?6uvH9sJUtVakESc5TVKLZx6u4vAZ3ILhPYxd1DvRRztu4dbqDL5G4zH7HxBZ?= =?us-ascii?Q?FuScld7Wpj8xZUWDO5gUJgVekPIU2uREeOZKCsHSKGelZ52no/dwkdFL19KH?= =?us-ascii?Q?W8jVZOpcUztOE6ZseyqQ1iv1UWan36ZSXdOzdBZ57KIKAvHhzNuCMkruypGq?= =?us-ascii?Q?tSnUdIFOeDCLXVlozJ16m4khw2gTCk3bmTcEeVHXoYGPPo2pHaggU3lrpSQa?= =?us-ascii?Q?ul/cDvN2NncOCo+of+0wruaZ?= 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: d05b0a18-bdd9-4627-1660-08d98a14f4d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 04:34:45.9364 (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: eRkgj+eg7xFZ633BRdHzlUbh0u8qgq8Ks7+JIeb4wCYsHNDXgmL0AZOyJcBL/4VoBxmIsJVU3L9y/elgaD6SrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0401MB2503 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: Friday, October 8, 2021 12:29 AM > 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 > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data endi= anness > assumption >=20 > 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 > > > > > > > > > -----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 dat= a > > > > 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 packe= ts 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 d= o > > > > 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 existi= ng > > 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 fre= e > > > to share more 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 > > 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 > > engine. We do see that other drivers in DPDK are using Little Endian *= (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 oth= er > > 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. >=20 > I want clarify that this would impact the application in case user wanted= to > switch between 2 such hw accelator. > Ie. you cannot switch the 2 solutions, they are incompatible except if yo= u > 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 > capturing the implication to be explicit. Ie each device expose the assum= ptions > expected by the application and it is up to the application the bbdev api= to > satisfy the relared assumptions. Hi Nicolas, Bbdev-test is one of a test application and it is using test vectors. Consi= der bbdev example application, the packets are in the network order (i.e. big-endian)= and no swapping is being done in this application. It is probably assumed that the= packets which are arriving/going out at the network are in the endianness order whi= ch are to be processed by the device. Similarly in the real world usage/applications, the endianness handling wou= ld be done on the other end (the originator/consumer of the data), which again could b= e done in hw accelerators without impacting the real world applications. Also, as standard is open for both, the current change makes sense and swap= ping in any of the PMD does not seems suitable. Regards, Nipun >=20 > > > > BTW Nicolos, my name is Nipun :) >=20 > My bad! >=20 > I am marking this patch as obsolete since you have included it in your se= rie. >=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 bu= t > > > 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 t= he > > PMD. > > > > Please see previous comment for endianness support. > > I agree with the RTE_ prefix we can add it as it is for the application= interface. > > > > > > > > > > > > > > + > > > > > /** > > > > > * 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 th= e > > 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 th= e > > > new PMD. > > > I will let Nipin/Hemant comment back. > > > > Again endianness is implementation specific and not standard for 5G > > processing, unlike it is for network packet. > > > > Regards, > > Nipun > > > > > > > > > > > > > > /** Default queue configuration used if none is supplied */ > > > > > struct rte_bbdev_queue_conf default_queue_conf; > > > > > /** Device operation capabilities */ > > > > > -- > > > > > 1.8.3.1