All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Li, Xiaoyun" <xiaoyun.li@intel.com>,
	Anoob Joseph <anoobj@marvell.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	"shepard.siegel@atomicrules.com" <shepard.siegel@atomicrules.com>,
	"ed.czeck@atomicrules.com" <ed.czeck@atomicrules.com>,
	"john.miller@atomicrules.com" <john.miller@atomicrules.com>,
	Igor Russkikh <irusskikh@marvell.com>,
	"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
	"somnath.kotur@broadcom.com" <somnath.kotur@broadcom.com>,
	"rahul.lakkireddy@chelsio.com" <rahul.lakkireddy@chelsio.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"sachin.saxena@oss.nxp.com" <sachin.saxena@oss.nxp.com>,
	"Wang, Haiyue" <haiyue.wang@intel.com>,
	"Daley, John" <johndale@cisco.com>,
	"hyonkim@cisco.com" <hyonkim@cisco.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Wang, Xiao W" <xiao.w.wang@intel.com>,
	"humin29@huawei.com" <humin29@huawei.com>,
	"yisen.zhuang@huawei.com" <yisen.zhuang@huawei.com>,
	"oulijun@huawei.com" <oulijun@huawei.com>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"matan@nvidia.com" <matan@nvidia.com>,
	"viacheslavo@nvidia.com" <viacheslavo@nvidia.com>,
	"sthemmin@microsoft.com" <sthemmin@microsoft.com>,
	"longli@microsoft.com" <longli@microsoft.com>,
	"heinrich.kuhn@corigine.com" <heinrich.kuhn@corigine.com>,
	Kiran Kumar Kokkilagadda <kirankumark@marvell.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	"Maciej Czekaj [C]" <mczekaj@marvell.com>,
	"jiawenwu@trustnetic.com" <jiawenwu@trustnetic.com>,
	"jianwang@trustnetic.com" <jianwang@trustnetic.com>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"mdr@ashroe.eu" <mdr@ashroe.eu>,
	"Jayatheerthan, Jay" <jay.jayatheerthan@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 3/7] ethdev: copy ethdev 'fast' API into separate structure
Date: Sun, 3 Oct 2021 20:58:25 +0000	[thread overview]
Message-ID: <DM6PR11MB4491AF0A3D321806CBE791169AAD9@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR18MB4086ECC8BB1E17C216E44E05DEAC9@PH0PR18MB4086.namprd18.prod.outlook.com>


> >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' calls
> >(like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> >
> >Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >---
> > lib/ethdev/ethdev_private.c  | 52
> >++++++++++++++++++++++++++++++++++++
> > lib/ethdev/ethdev_private.h  |  7 +++++
> > lib/ethdev/rte_ethdev.c      | 17 ++++++++++++
> > lib/ethdev/rte_ethdev_core.h | 45
> >+++++++++++++++++++++++++++++++
> > 4 files changed, 121 insertions(+)
> >
> 
> <snip>
> 
> >+void
> >+eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> >+{
> >+	static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
> >+	static const struct rte_eth_fp_ops dummy_ops = {
> >+		.rx_pkt_burst = dummy_eth_rx_burst,
> >+		.tx_pkt_burst = dummy_eth_tx_burst,
> >+		.rxq = {.data = dummy_data, .clbk = dummy_data,},
> >+		.txq = {.data = dummy_data, .clbk = dummy_data,},
> >+	};
> >+
> >+	*fpo = dummy_ops;
> >+}
> >+
> >+void
> >+eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> >+		const struct rte_eth_dev *dev)
> >+{
> >+	fpo->rx_pkt_burst = dev->rx_pkt_burst;
> >+	fpo->tx_pkt_burst = dev->tx_pkt_burst;
> >+	fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
> >+	fpo->rx_queue_count = dev->rx_queue_count;
> >+	fpo->rx_descriptor_status = dev->rx_descriptor_status;
> >+	fpo->tx_descriptor_status = dev->tx_descriptor_status;
> >+
> >+	fpo->rxq.data = dev->data->rx_queues;
> >+	fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
> >+
> >+	fpo->txq.data = dev->data->tx_queues;
> >+	fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> >+}
> >diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
> >index 3724429577..40333e7651 100644
> >--- a/lib/ethdev/ethdev_private.h
> >+++ b/lib/ethdev/ethdev_private.h
> >@@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev
> >*_start, rte_eth_cmp_t cmp,
> > /* Parse devargs value for representor parameter. */
> > int rte_eth_devargs_parse_representor_ports(char *str, void *data);
> >
> >+/* reset eth 'fast' API to dummy values */
> >+void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
> >+
> >+/* setup eth 'fast' API to ethdev values */
> >+void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> >+		const struct rte_eth_dev *dev);
> >+
> > #endif /* _ETH_PRIVATE_H_ */
> >diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> >index 424bc260fa..9fbb1bc3db 100644
> >--- a/lib/ethdev/rte_ethdev.c
> >+++ b/lib/ethdev/rte_ethdev.c
> >@@ -44,6 +44,9 @@
> > static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> > struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
> >
> >+/* public 'fast' API */
> >+struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> >+
> > /* spinlock for eth device callbacks */
> > static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
> >
> >@@ -1788,6 +1791,9 @@ rte_eth_dev_start(uint16_t port_id)
> > 		(*dev->dev_ops->link_update)(dev, 0);
> > 	}
> >
> >+	/* expose selection of PMD rx/tx function */
> >+	eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
> >+
> 
> Secondary process will not set these properly I believe as it might not
> call start() if it does primary process ops will not be set.

That's a very good point, have to admit - I missed that part.

> 
> One simple solution is to call ops_setup() around rte_eth_dev_attach_secondary()
> but if application doesn't invoke start() on Primary the ops will not be set for it.

I think rte_eth_dev_attach_secondary() wouldn't work, as majority of the PMDs setup
fast ops function pointers after it.
From reading the code rte_eth_dev_probing_finish() seems like a good choice -
as it is always the final point in device initialization for secondary process.

BTW, we also need something similar at de-init phase.
rte_eth_dev_release_port() seems like a good candidate for it.

 
> 
> > 	rte_ethdev_trace_start(port_id);
> > 	return 0;
> > }
> >@@ -1810,6 +1816,9 @@ rte_eth_dev_stop(uint16_t port_id)
> > 		return 0;
> > 	}
> >
> >+	/* point rx/tx functions to dummy ones */
> >+	eth_dev_fp_ops_reset(rte_eth_fp_ops + port_id);
> >+
> > 	dev->data->dev_started = 0;
> > 	ret = (*dev->dev_ops->dev_stop)(dev);
> > 	rte_ethdev_trace_stop(port_id, ret);
> >2.26.3


  reply	other threads:[~2021-10-03 20:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-02  0:14 [dpdk-dev] [PATCH v3 3/7] ethdev: copy ethdev 'fast' API into separate structure Pavan Nikhilesh Bhagavatula
2021-10-03 20:58 ` Ananyev, Konstantin [this message]
2021-10-03 21:10   ` Pavan Nikhilesh Bhagavatula
  -- strict thread matches above, loose matches on Subject: below --
2021-09-22 14:09 [dpdk-dev] [RFC v2 0/5] hide eth dev related structures Konstantin Ananyev
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 0/7] " Konstantin Ananyev
2021-10-01 14:02   ` [dpdk-dev] [PATCH v3 3/7] ethdev: copy ethdev 'fast' API into separate structure Konstantin Ananyev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR11MB4491AF0A3D321806CBE791169AAD9@DM6PR11MB4491.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=adwivedi@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=anoobj@marvell.com \
    --cc=beilei.xing@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=dev@dpdk.org \
    --cc=ed.czeck@atomicrules.com \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=heinrich.kuhn@corigine.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=humin29@huawei.com \
    --cc=hyonkim@cisco.com \
    --cc=irusskikh@marvell.com \
    --cc=jay.jayatheerthan@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jingjing.wu@intel.com \
    --cc=john.miller@atomicrules.com \
    --cc=johndale@cisco.com \
    --cc=kirankumark@marvell.com \
    --cc=longli@microsoft.com \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mczekaj@marvell.com \
    --cc=mdr@ashroe.eu \
    --cc=ndabilpuram@marvell.com \
    --cc=oulijun@huawei.com \
    --cc=pbhagavatula@marvell.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=rahul.lakkireddy@chelsio.com \
    --cc=sachin.saxena@oss.nxp.com \
    --cc=shepard.siegel@atomicrules.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=sthemmin@microsoft.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=xiao.w.wang@intel.com \
    --cc=xiaoyun.li@intel.com \
    --cc=yisen.zhuang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.