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 EEACAA0C55; Wed, 13 Oct 2021 16:25:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3517410DA; Wed, 13 Oct 2021 16:25:52 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 4ACB940E64 for ; Wed, 13 Oct 2021 16:25:51 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id B53F17F567; Wed, 13 Oct 2021 17:25:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru B53F17F567 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634135150; bh=8uBUBSUbckerI4vo0ASNbph7DV42srqJC3Jlgm+RPSQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=O5iIlcxGwsCxdt77OOtzTCla71oHIVoTw1A4dyA80okymMm6+3mo1N4/K0xEFDzIi Pj1sgiH5ZPeOvBYmCF+tJmAoSwfMQnlVRH5//MB0FOlvLt7Yh3mw3cN+7frTOF65Kb UnMIuqADkTBVE94Mlu2pdF3hrJoVBUBIUkFwdKVE= To: Konstantin Ananyev , dev@dpdk.org Cc: xiaoyun.li@intel.com, anoobj@marvell.com, jerinj@marvell.com, ndabilpuram@marvell.com, adwivedi@marvell.com, shepard.siegel@atomicrules.com, ed.czeck@atomicrules.com, john.miller@atomicrules.com, irusskikh@marvell.com, ajit.khaparde@broadcom.com, somnath.kotur@broadcom.com, rahul.lakkireddy@chelsio.com, hemant.agrawal@nxp.com, sachin.saxena@oss.nxp.com, haiyue.wang@intel.com, johndale@cisco.com, hyonkim@cisco.com, qi.z.zhang@intel.com, xiao.w.wang@intel.com, humin29@huawei.com, yisen.zhuang@huawei.com, oulijun@huawei.com, beilei.xing@intel.com, jingjing.wu@intel.com, qiming.yang@intel.com, matan@nvidia.com, viacheslavo@nvidia.com, sthemmin@microsoft.com, longli@microsoft.com, heinrich.kuhn@corigine.com, kirankumark@marvell.com, mczekaj@marvell.com, jiawenwu@trustnetic.com, jianwang@trustnetic.com, maxime.coquelin@redhat.com, chenbo.xia@intel.com, thomas@monjalon.net, ferruh.yigit@intel.com, mdr@ashroe.eu, jay.jayatheerthan@intel.com References: <0211007112750.25526-1-konstantin.ananyev@intel.com> <20211013133704.31296-1-konstantin.ananyev@intel.com> <20211013133704.31296-4-konstantin.ananyev@intel.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <6557f6b4-02ab-9af2-af50-c2a73f502365@oktetlabs.ru> Date: Wed, 13 Oct 2021 17:25:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211013133704.31296-4-konstantin.ananyev@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure 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" On 10/13/21 4:37 PM, Konstantin Ananyev wrote: > Copy public function pointers (rx_pkt_burst(), etc.) and related > pointers to internal data from rte_eth_dev structure into a > separate flat array. That array will remain in a public header. > The intention here is to make rte_eth_dev and related structures internal. > That should allow future possible changes to core eth_dev structures > to be transparent to the user and help to avoid ABI/API breakages. > The plan is to keep minimal part of data from rte_eth_dev public, > so we still can use inline functions for fast-path calls > (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown. > The whole idea beyond this new schema: > 1. PMDs keep to setup fast-path function pointers and related data > inside rte_eth_dev struct in the same way they did it before. > 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish() > (for secondary process) we call eth_dev_fp_ops_setup, which > copies these function and data pointers into rte_eth_fp_ops[port_id]. > 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port() > we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id] > into some dummy values. > 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new > flat array to call PMD specific functions. > That approach should allow us to make rte_eth_devices[] private > without introducing regression and help to avoid changes in drivers code. > > Signed-off-by: Konstantin Ananyev Reviewed-by: Andrew Rybchenko