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 A8604A0524; Tue, 25 Feb 2020 06:57:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C58C1BC24; Tue, 25 Feb 2020 06:57:27 +0100 (CET) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id A75482C4F for ; Tue, 25 Feb 2020 06:57:25 +0100 (CET) Received: by mail-il1-f194.google.com with SMTP id x2so359108ila.9 for ; Mon, 24 Feb 2020 21:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s1o3gS89vcF65gxvGRVgZlU+tRejgr0KyR+Vgqr+MUI=; b=a47i2b6ZU05bdv8GH0OusO+Zz+0HyufaUzlSKZ6tfBC1fVsnb/Hdaemj85i4SCtf4U FoAe1jLQ6FnER3Lbsdrit4iWX0M/A1vbgFGY8WSudzp0X8ZmcZoxcr5NojvMD8cbbvfn jkMKwLMSdxBAaAlvRhRi80di9/U1W9IMQaSOhRz1C53tPXjbXgcUVf3WXsUp4L9M6v3L Q9Oq7L7tvfsVXgvpOrtvmY3NaoEIB5K7KOIH6fxG73wJfQKx7UH0iqrLaelKh6efIQLo 0rQdTQYkXsyv7sYt0QFS/7qFrxvz1+r6Lm+oNaycfZK/l9WkRmgcfMTNPfGBHLVDVx8X ykvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s1o3gS89vcF65gxvGRVgZlU+tRejgr0KyR+Vgqr+MUI=; b=UjC+dWFsvC+PSOUxUHgJQM5DJ5uHUmiJE+tQ041uX2aboIXHxavnU53XgfODFS4JF0 pWh2yjE9VNxyHALfdWpwKRvDLbkrS6fxgVLEnA2Sjpyq//+D5fSR100XfpvTWz6FVCdi 2+d2WhsYR+GITztdR2jH1lBiHmamdPSEvun2bRtYODGKz8VJsbXkAmjRmBq1I5u3/mGw E58ple+LhSR8mj+bH4ofAbNZjsZOXugmyz6zNsHZTagoHJDvplNDchp9a6bFc5/qtyaO qaovPwe/teq/F4aqGbTo9z0sl0OwinOGwLrDdGpDKTxTPSM+sDpAhNGPdJ6mNo+QVLPh z5lg== X-Gm-Message-State: APjAAAWc6fl2Mruu1UU1QgmnjDWzIB+p5eaGW2YIN89RPc693JsNcpB2 qUKDeuO2hRWS4y3Th5MSIiXC2woESsTsv9FM00A= X-Google-Smtp-Source: APXvYqzheV1f99mFZ2cDHCAj8u/7HjP00ycMBzZd2mXM34Cg0JOZv2vOE+uFBG+UGWLxPPNcNyghF84WWOWm6VjE37g= X-Received: by 2002:a05:6e02:f47:: with SMTP id y7mr68698762ilj.162.1582610244880; Mon, 24 Feb 2020 21:57:24 -0800 (PST) MIME-Version: 1.0 References: <20190627155036.56940-1-jerinj@marvell.com> <1580202029-37096-1-git-send-email-orika@mellanox.com> In-Reply-To: From: Jerin Jacob Date: Tue, 25 Feb 2020 11:27:08 +0530 Message-ID: To: Ori Kam Cc: Jerin Jacob , "xiang.w.wang@intel.com" , dpdk-dev , Pavan Nikhilesh , Shahaf Shuler , Hemant Agrawal , Opher Reviv , Alex Rosenbaum , "dovrat@marvell.com" , Prasun Kapoor , Nipun Gupta , "Richardson, Bruce" , "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 Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3] regexdev: introduce regexdev subsystem 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" > > 4) app/test/test_regexdev.c like app/test/test_eventdev.c > > We started to create a super basic app, after the API will be finalized and we will have HW > we can push it. (if you need it faster than feel free) A simple Unit test case needs to be present for the APIs. On the course of developing common code, it can be developed to test the common code with dummy/skeleton driver. > > > 5) Need a maintainer for maintaining the regex subsystem > > > We wish to maintain it if you agree. Yes. Please. > > > > > > One more thing, regarding the ops structure, I think it is better to split it to 2 > > different > > > structures one enque and one for dequeue, since there are no real shared > > data and we will > > > be able to save memory, what do you think? > > > > Ops are allocated from mempool so it will be overhead to manage both. > > moreover, some > > of the fields added in req can be used for resp as info. cryptodev > > follows the similar concept, > > I think, we can have symmetry with cryptodev wherever is possible to avoid > > end-user to learn new API models. > > True that there will be overhead with 2 mempools (small one) > but lets assume 255 results. This means that the buffer should be 255 * sizeof(rte_regex_match) = 2K > also this will enable us to replace groupX with group[] which will allow even more groups. > In addition don't think that crypto is a good example. > The main difference is that in RegEx the output is different format then the input. # IMO, Some of the fields may be useful for a response as well. I think application may be interested in following req filed in the response. a) buf_addr b) scan_size c) user_id (This would be main one) # Having two mempools adds overhead per lcore L1 cache usage and extra complexity to the application. # IMO, From a performance perspective, one mempool is good due to less stress on the cache and it is costly to add new mempool for HW mempool implementations. # I think, group[] use case we can add it when it required by introducing "matches_start_offset" field, which will tell the req, where is the end of group[] and where "matches" start with single mempool scheme also. # I think, one of the other use case for "matches_start_offset" that, It may possible to put vendor-specific opaque data. It will be filled by driver on response. The application can reference the matches as struct rte_regex_match *matches = RTE_PTR_ADD(ops, ops->matches_start_offset); > > > I assume you will send the v4 with these comments. I think, with v4 we > > can start implementing common library code. > > Just need to agree on the split (one more iteration ) > and I will start working on the common code. Ack.