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 5D1A0A0597; Wed, 8 Apr 2020 11:41:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 755701C0CC; Wed, 8 Apr 2020 11:41:27 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10041.outbound.protection.outlook.com [40.107.1.41]) by dpdk.org (Postfix) with ESMTP id 5B7D41C0C6 for ; Wed, 8 Apr 2020 11:41:25 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y6YDmd3Ggcur/2ECbM2V3ATcTPkpgb3g7OA6jso5l9SXoy+hwbtj7O2rbOiTaXMCMKrO21IdRFbAg6/OhmXOAFfZM5Lw0juJF6iqbwQSUHaG8ccRk5GyiylOcxORJ+EKC1VqcONvrExZkp5G1Cuw8iItmjCA4cnQBzghEl1N1viKAG7TvPNw1azuzPzJ++75LmJeAW1tFLJybF1JKHd7EtmMLBWOhGRt8WmYXVx5BqEVHh1O9gwCKHZ7VXmzwUbCvsVDuZYi3I6/hCSDuhAF80/kV3j5sh6OwfCaHWI0Wwi8EMoe4jiNjKXen/a8AcOOcLouLvU3F6Oe8rMhIS1Ogw== 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-SenderADCheck; bh=ojqyd1KQXzg14l4w+Sl8GYUkL2V5IU8rjJe/5BGo8aA=; b=ksOXjGhwM8/YFOSoWsWIPYfZ1B/Mv/2b7A1nsVt1G7wXDKMWpPx/8QqsVhYs9miguFwfPaQJF9s8ZgtzGturQKtWMergbeTTWTCl51SoF5mN1NFiIW/q1KGRKuStDr9Rx5w+rGm+DfdasePdpnR0ZQK5Ls6nPxJCSTQgN1FfsVJOtr1yz2cAgL2I71LMtX7Drd5kx4O1xhtQYuUgh53Mm8BNiLGbYXtPzXH3y6GcvAhYKfcjB3zBl4k1dr8jJ7tdLzZJVEPW4lVxPqd6zqLrOQZuaetCUPvRXIyVgNTVsXde3pvU3PR35EJYfqIiF5VoW3x6TefLY5m7f/QflfFjXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ojqyd1KQXzg14l4w+Sl8GYUkL2V5IU8rjJe/5BGo8aA=; b=AUFVVgg8jJIXxbyzkqUUsoClQG2YQuEW5rF3F54xG+3ESksfMd0UFjRguo2ancBhBu2oe6mMjKiRZTknItHOraUdxyz+NvAY96sNtXsHmBed3lj8oHa52s9OI3ZPTB0jNrksN7BSaRSE8thhD4qBqlynMiE5LLaTOYKzc9YyJC8= Received: from AM6PR05MB5176.eurprd05.prod.outlook.com (2603:10a6:20b:63::30) by AM6PR05MB5239.eurprd05.prod.outlook.com (2603:10a6:20b:67::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Wed, 8 Apr 2020 09:41:23 +0000 Received: from AM6PR05MB5176.eurprd05.prod.outlook.com ([fe80::f5cd:b10f:5f1b:4b22]) by AM6PR05MB5176.eurprd05.prod.outlook.com ([fe80::f5cd:b10f:5f1b:4b22%7]) with mapi id 15.20.2878.018; Wed, 8 Apr 2020 09:41:23 +0000 From: Ori Kam To: Pavan Nikhilesh Bhagavatula , Jerin Jacob Kollanukkaran , "xiang.w.wang@intel.com" CC: "dev@dpdk.org" , Shahaf Shuler , "hemant.agrawal@nxp.com" , Opher Reviv , Alex Rosenbaum , Dovrat Zifroni , Prasun Kapoor , "nipun.gupta@nxp.com" , "bruce.richardson@intel.com" , "yang.a.hong@intel.com" , "harry.chang@intel.com" , "gu.jian1@zte.com.cn" , "shanjiangh@chinatelecom.cn" , "zhangy.yun@chinatelecom.cn" , "lixingfu@huachentel.com" , "wushuai@inspur.com" , "yuyingxia@yxlink.com" , "fanchenggang@sunyainfo.com" , "davidfgao@tencent.com" , "liuzhong1@chinaunicom.cn" , "zhaoyong11@huawei.com" , "oc@yunify.com" , "jim@netgate.com" , "hongjun.ni@intel.com" , "j.bromhead@titan-ic.com" , "deri@ntop.org" , "fc@napatech.com" , "arthur.su@lionic.com" , Thomas Monjalon , Parav Pandit Thread-Topic: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions Thread-Index: AQHWDBG06iD3s109dUuVTWXNJb20nKhu6xhw Date: Wed, 8 Apr 2020 09:41:23 +0000 Message-ID: References: <1585464438-111285-1-git-send-email-orika@mellanox.com> <1585464438-111285-4-git-send-email-orika@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=orika@mellanox.com; x-originating-ip: [185.149.253.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e982a884-de47-4a11-d163-08d7dba0fffe x-ms-traffictypediagnostic: AM6PR05MB5239:|AM6PR05MB5239: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR05MB5176.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(136003)(376002)(396003)(6506007)(53546011)(81156014)(33656002)(54906003)(110136005)(7696005)(66446008)(86362001)(66946007)(64756008)(66556008)(66476007)(8936002)(76116006)(316002)(2906002)(7416002)(55016002)(9686003)(186003)(26005)(81166007)(71200400001)(5660300002)(52536014)(4326008)(107886003)(478600001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tfz6sHCrfea3rAnUnUc4MD5uFvtexA4fBPEbzeuWsQXpG0Oai61TdYWsS5yp87hxwibIdSi9kP5Ap8sTYSHu1/TJSSV07Z78laPoL1iavfjlA78mF/z2+qe/kPiUr1pZbuMBcS5HO6zss9gIyu0hX9ar2Cd4I1iRvYDn75AEvaIM9T4QBGR1EqVCY8zmOMVZ2XO+BWgVjFtK8avP9284qm2yybYOGMQpL8Tk7DNqXI8NVnR94mLcuibLiLMCF4K4FAfzXBLTgAai3ty5s6Hq1CblrLjIeBvJHlTP4Uov3T2l7af0QFqcQGoNQW2Pg7r3A4OhG2YjHir2AlK30NJ8o9aVym8rBxcEoTbEL8Xo1QwbLPGPDtjaJ/hd1Xe/v/jDgg6CaZE89QmFYc6OSPpqDqbiNu6xGZMbQUk9KlF9KJp1nEPtabSCLQT7r65h2AxM x-ms-exchange-antispam-messagedata: UVD3wxeP+5mN06lBRG2hl64EVANYd+bNxgjThIZF6VXt/T+NTyiRHD6l1ZNZikouvjGcf9wlvcoK/uKgHlU3hKJSTtIliUcUZR2lAZtAfSDMfuKH8QUhAQ5DpUQpftqgx1MRgcQziVjb28toJoL3Sw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: e982a884-de47-4a11-d163-08d7dba0fffe X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 09:41:23.0595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: O4tqRpazKYFw8GOiuZYtrUaRtLPA5gZJPZfCpKbKEG1MYkxsu6A3qSr4EeHaYPokvfB0jbc+2dbkMPnD5oHFdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB5239 Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev core functions 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" Hi Pavan > -----Original Message----- > From: dev On Behalf Of Pavan Nikhilesh Bhagavatula > Sent: Monday, April 6, 2020 3:48 PM >=20 > Hi Ori, >=20 > >Hi Pavan, > > > >> -----Original Message----- > >> From: dev On Behalf Of Pavan Nikhilesh > >Bhagavatula > >> Sent: Sunday, April 5, 2020 8:11 PM > >> To: Ori Kam ; Jerin Jacob Kollanukkaran > >> ; xiang.w.wang@intel.com > >> Cc: dev@dpdk.org; Shahaf Shuler ; > >> hemant.agrawal@nxp.com; Opher Reviv ; > >Alex > >> Rosenbaum ; Dovrat Zifroni > >; > >> Prasun Kapoor ; nipun.gupta@nxp.com; > >> bruce.richardson@intel.com; yang.a.hong@intel.com; > >harry.chang@intel.com; > >> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn; > >> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; > >wushuai@inspur.com; > >> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com; > >> davidfgao@tencent.com; liuzhong1@chinaunicom.cn; > >> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com; > >> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org; > >> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon > >> ; Parav Pandit > >> Subject: Re: [dpdk-dev] [EXT] [PATCH v1 3/4] regexdev: add regexdev > >core > >> functions > >> > >> Hi Ori, > >> > >> >> From: dev On Behalf Of Pavan > >Nikhilesh > >> >Bhagavatula > >> >> > >> >> Looks like this implementation is incomplete? > >> >> I don't see any pmd specific helper functions for @see > >> >rte_cryptodev_pmd.c, > >> >> rte_eventdev_pmd* > >> >> > >> >I think the current implementation includes all needed functions, > >> >at least for the first stage. > >> >You can find in rte_regexdev_driver.h the functions that should be > >> >called > >> >by the PMD. We have the register / unregister which acts the same > >as > >> >create > >> >and destroy. For parsing argument the PMD may call > >rte_kvargs_parse. > >> > > >> > >> _driver.h should atleast include > >> rte_regex_dev_pci_generic_probe/rte_regex_pmd_vdev_init > >> else there would be a lot of code repetition and possibly udefined > >behavior > >> at the driver layer. > >> > >Why should they be included? At least in this stage, there is no code to > >share > >ethdev why should we add code for the vdev? >=20 > Ok I think I failed to communicate my concerns across. > Let me retry >=20 > 1. SW based regex devices such as PCRE/Hyperscan rely on vdev framework > i.e. user needs to pass an EAL argument --vdev=3D"regex_pcre" for the dri= ver to > initialize all the other EAL subsystems (ethdev, eventdev, cryptodev, > etc..)support this. >=20 > 2. HW based independent regex devices that are exposed as PCI devices wou= ld > need > pci probe helpers. >=20 >=20 Like mentions in other treads lets leave it as is for now, And based on PMD implementation add the required functions. > >I agree that if we see that there is shared code, we should think about > >creating > >those functions. > > > >> And also why take a different path than the rest of the rte > >subsystems? > >> > > > >Even now if you look at the reference code you will see that there is > >really minimum shared code. > >also this result in that the PMD is not free to allocate resource in the > >order he needs. > >My thinking is that if there are only 2 lines of shared code I prefer to= let > >the PMD handle it. > >I know that sharing code should be the first option, but this also makes > >the PMD developer unaware what is going on. > >and lose some control. For example if the PMD programmer wants to > >create hybrid PMD net + > >regex for example, then either he will be forced to do some hacks or > >just by pass the function > >so when this function will be updated his code will break. >=20 > Shouldn't the application/end user make that decision rather than PMD > programmer?. > If application wants to connect net to regex it should be made possible t= o do it > via rte_flow. >=20 In this case there will be I guess new rte_flow command, and there will be = no no use for the enqueue/deques or there will not be use for rx_burst / tx_bu= rst This is a story for another day. In any case the PMD should be as flexiable as possible. This is why I thin= k that the most code should be in the PMD since it is PMD implemetion and if we ad= d common code in rte level this can make the PMD less flexable. For example h= ow to share resource between net / regex device. For example even in current=20 stage the application can receive packets from the net device and send thos= e=20 packets to the regex device, if the application uses both devices from the = same=20 company they can share information that can save time, for example memory=20 registration values. =20 > As an example if we see event device spec. It has robust features to conn= ect > multiple > subsystems(ethernet/crypto/timer) to event device and it is controlled fr= om > RTE layer. > PMD layer should act on the inputs from RTE layer rather than action on i= t own. >=20 > Thoughts? > Thanks, > Pavan. >=20 Like I said above until we support inline regex, the application=20 moves the packets just like it moves them between net devices, so each PMD should have the ability to configure itself as best as it can. Again I totally in favor that if we see common code we should move it to rte level. But this should be done only after we have a code and in any case this doesn't effect the API. =20 > So I prefer if it > >is very short code > >and this code can be developed in different ways to leave it to the > >PMD. > >I suggest that if needed we will add such function. Is that O.K by you? > > > >> > > >> >> >This commit introduce the API that is needed by the RegEx > >devices in > >> >> >order to work with the RegEX lib. > >> >> > > >> >> >During the probe of a RegEx device, the device should configure > >> >itself, > >> >> >and allocate the resources it requires. > >> >> >On completion of the device init, it should call the > >> >> >rte_regex_dev_register in order to register itself as a RegEx > >device. > >> >> > > >> >> >Signed-off-by: Ori Kam > >> >> >Signed-off-by: Parav Pandit > >> >> >--- > >> >> > config/common_base | 3 +- > >> >> > config/meson.build | 1 + > >> >> > lib/librte_regexdev/Makefile | 1 + > >> >> > lib/librte_regexdev/meson.build | 5 ++- > >> >> > lib/librte_regexdev/rte_regexdev.c | 74 > >> >> >++++++++++++++++++++++++++++++- > >> >> > lib/librte_regexdev/rte_regexdev.h | 7 +++ > >> >> > lib/librte_regexdev/rte_regexdev_core.h | 2 + > >> >> > lib/librte_regexdev/rte_regexdev_driver.h | 50 > >> >> >+++++++++++++++++++++ > >> >> > meson_options.txt | 2 + > >> >> > 9 files changed, 142 insertions(+), 3 deletions(-) > >> >> > create mode 100644 lib/librte_regexdev/rte_regexdev_driver.h > >> >> > > >> >> > >> >>