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 30516A0597; Wed, 8 Apr 2020 09:49:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 31BDF1C023; Wed, 8 Apr 2020 09:49:03 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id A8BF31BF6D for ; Wed, 8 Apr 2020 09:49:01 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id g15so5819942ilj.10 for ; Wed, 08 Apr 2020 00:49:01 -0700 (PDT) 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=CFFkElrrMf2MZSD3SatoJGJIHXlz+kdONUI4kCutVgU=; b=hMWIhjm1d3Xbbzg0b+IVZGNNpJwB001mvrpdMNLkQd8OwUyCvKCvttn/RG3CZ/nlhO AdhzTOk3dOBsARMHaxt8LMkYD5bvdeJVaL3IQytW2xWsKLQCmeMZuJhrvUSf8jsR4AvH MEeH2BBb4Gxgdxy7TJSU7/UtjZWsul0onZwS5pEJtW4aNmXQ0UN6jCXybQJQK+bcd2Y5 CZ6V1Qdc1cCKERkwAvY5a3/fG53RE/QB0X3goH1pvZZ32rIBdlNn2dFWTITeV2qItA2S o0XDWVo/lGmeWTfmN8vU1QU+gTPa0JU/g77q6e8nYjb8RohU3gwV4MMuqVDFsOX+QBeN 58ow== 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=CFFkElrrMf2MZSD3SatoJGJIHXlz+kdONUI4kCutVgU=; b=aleTkwxlm/3b4eLq0zW7R1d6ih7lysapWUKWWZ03ykbg1wxcMNukG7/fO3zQN30e1t j/SALDEvuqrnOGiCHDagldV1/u2VselnEE1XkFFIVHI48p04g39uOeBN6p0RHE0gOJfv vt9Cku44EMSRXutRSEgg07wnDMZNXbiL+1aobKu6RY8MXmxC47/JIxI7d/NUN0Spw0nq aGhZP7Cq8gANL9qEN9EzgOORN6ahVLB+vVSsyCqFbuGKgm2aYPt3RkaIVvYx/bLTxTCs cowkjLUjufDKjPqLQng1pkWHtjEN2nfLEFFOVFeLvwFJnSb3KdYyKHS/MIl1/m3+Elrn N5BQ== X-Gm-Message-State: AGi0Puaw8o/pFwrxkBRFSixrCzmj7b/Mwt8cIjosU++/4nWW5d0WDcLX 7IFWEvO5mZ7hvyyOxGAHWnp0bk/4NO2dkHweKPw= X-Google-Smtp-Source: APiQypJG9nJag26QlW1zR5Ub2/JRYwn93SEBh3y0tFsgf8ZQI77EuMoP4xQG0QRsS4S63LVYO97Y/X2m+/BZlpyOgHo= X-Received: by 2002:a92:cecd:: with SMTP id z13mr1052290ilq.271.1586332140894; Wed, 08 Apr 2020 00:49:00 -0700 (PDT) MIME-Version: 1.0 References: <1585464438-111285-1-git-send-email-orika@mellanox.com> <1585464438-111285-3-git-send-email-orika@mellanox.com> In-Reply-To: From: Jerin Jacob Date: Wed, 8 Apr 2020 13:18:44 +0530 Message-ID: To: Ori Kam Cc: Guy Kaneti , Jerin Jacob Kollanukkaran , "xiang.w.wang@intel.com" , "dev@dpdk.org" , Pavan Nikhilesh Bhagavatula , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file 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" On Wed, Apr 8, 2020 at 1:07 PM Ori Kam wrote: > > > > -----Original Message----- > > From: dev On Behalf Of Jerin Jacob > > Sent: Tuesday, April 7, 2020 7:27 PM > > Subject: Re: [dpdk-dev] [PATCH v1 2/4] regexdev: add regex core h file > > > > On Tue, Apr 7, 2020 at 9:46 PM Ori Kam wrote: > > > > > Hi Guy, > > > > > > > -----Original Message----- > > > > From: dev On Behalf Of Guy Kaneti > > > > Sent: Tuesday, April 7, 2020 11:54 AM > > > > > + > > > > > +/** > > > > > + * @internal > > > > > + * The generic data structure associated with each RegEx device. > > > > > + * > > > > > + * Pointers to burst-oriented packet receive and transmit > functions > > > are > > > > > + * located at the beginning of the structure, along with the > pointer > > > to > > > > > + * where all the data elements for the particular device are > stored in > > > > > +shared > > > > > + * memory. This split allows the function pointer and driver dat= a > to > > > be > > > > > +per- > > > > > + * process, while the actual configuration data for the device i= s > > > shared. > > > > > + */ > > > > > +struct rte_regexdev { > > > > > + regexdev_enqueue_t enqueue; > > > > > + regexdev_dequeue_t dequeue; > > > > > + const struct rte_regexdev_ops *dev_ops; > > > > > + /**< Functions exported by PMD */ > > > > > + struct rte_device *device; /**< Backing device */ } > > > > > +__rte_cache_aligned; > > > > > + > > > > > > > > What about a handle for the PMD private data such as > > > > struct rte_eventdev_data *data; > > > > /**< Pointer to device data */ > > > > > > > > struct rte_cryptodev_data *data; > > > > /**< Pointer to device data */ > > > > > > I was thinking about new approach. To use container of. > > > Meaning each PMD will create like normal its priv structure. > > > In this structure there will be a regex_dev member. > > > For example: > > > struct mlx5_regex_priv { > > > struct rte_regex_dev regex_dev; > > > > > > > The rte_regex_dev which has enqueue() and dequeue() function pointer > > should not be NOT allocated from hugepage > > as per process it will have different enqueue() and dequeue() function > > pointer value. Making it hugepage, another process > > overwrites it. > > > > > > I didn't say this structure should be allocated from huge page. > Unless I'm missing something, from memory this is exactly the same > as if we had pointer to the priv. > Private data should be allocated from the hugepage so that multiple processes can access it. Whereas the memory that contains the enqueue() and dequeue() should not be from hugepage. So both can not be from the same memory. Right? > > > > > //private fields > > > ... > > > ... > > > } > > > On registration the PMD will give the rte_regexdev the reference to t= he > > > regex_dev. > > > The PMD will use container_of > > > > > > This approach hides the private data from the application, > > > saves malloc, a bit faster, and saves the use of references. > > > > > > So a better approach =F0=9F=98=8A also this approach is in use by the= rte_device. > > > > > > > > > >