From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"Yang, Qiming" <qiming.yang@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Xing, Beilei" <beilei.xing@intel.com>,
"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 2/7] eth: make drivers to use new API for Rx
Date: Tue, 14 Sep 2021 14:28:51 +0000 [thread overview]
Message-ID: <DM6PR11MB44913D0DC20F834F5320ABD99ADA9@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <dfa3b259-c4d7-ed1c-15cc-bc3af0d7fa33@intel.com>
Hi Ferruh,
>
> Overall this enables us hiding the ethdev internals, which is good. But it
> duplicates most of the datapath function (rx burst for this patch) per each PMD ops.
Yes, same as right now rte_eth_rx/tx_burst() code can be duplicated in dozen places
inside user-level code. And as any other 'static inline' function that we define and use inside DPDK.
Personally I don't see why it is a problem.
>
> I wonder if we can have the callbacks ('_rte_eth_rx_epilog()') as separate
> function, this still enables us to hide the structs. Of course additional
> function call will bring some overhead, but if we enabled callbacks and calling
> them per packet, do we really care about additional function call?
Callbacks are not per packet, but per burst of packets - same as actual RX/TX.
A drawback with such approach - we either have to keep
post_rx_burst_cbs[RTE_MAX_QUEUES_PER_PORT] visible to the user
(which I'd prefer not to), or call epilolg() unconditionally - which means
performance drop.
>
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> <...>
>
> > @@ -3229,7 +3289,7 @@ int
> > ice_rx_burst_mode_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
> > struct rte_eth_burst_mode *mode)
> > {
> > - eth_rx_burst_t pkt_burst = dev->rx_pkt_burst;
> > + rte_eth_rx_burst_t pkt_burst = rte_eth_get_rx_burst(dev->data->port_id);
>
> Does it makes easier to orginanise the patchset to have a separate patch to
> switch first to 'rte_eth_get_rx_burst()' / 'rte_eth_set_rx_burst()' with old
> implementation ('dev->rx_pkt_burst' get/set), and later just change the
> 'rte_eth_get_rx_burst()' / 'rte_eth_set_rx_burst()' implementation when
> structure is updated.
This is doable, don't know would be there any benefit from that or not.
>
> <...>
>
> > --- a/drivers/net/ice/ice_rxtx_vec_sse.c
> > +++ b/drivers/net/ice/ice_rxtx_vec_sse.c
> > @@ -587,13 +587,15 @@ _ice_recv_raw_pkts_vec(struct ice_rx_queue *rxq, struct rte_mbuf **rx_pkts,
> > * - nb_pkts > ICE_VPMD_RX_BURST, only scan ICE_VPMD_RX_BURST
> > * numbers of DD bits
> > */
> > -uint16_t
> > +static inline uint16_t
>
> These functions eventually will be called via a function pointer, so is there a
> benefit to request them to 'inline', why not just 'static' ?
Agree.
> <...>
>
> > +_RTE_ETH_RX_DEF(ice_recv_scattered_pkts_vec)
> > +
>
> This will duplicate most of the Rx burst function for each PMD Rx ops.
>
> <...>
>
> > +
> > +#define _RTE_ETH_FUNC(fn) _rte_eth_##fn
> > +
>
> Do we need this macro? The functions are still 'static', so they won't be
> visible to application and there won't be a namespace problem.
Not all RX/TX burst functions are defined as 'static'.
> Dropping and just use the original fucntion name may reduce the changes in the
> drivers.
It allows to keep existing RX/TX functions intact - no need to change prototype, add prolog/epilog, etc. manually.
Instead these macros help to create a wrapper functions around existing ones, that will
become new public entry points.
All that should help to make changes faster and in a safer manner.
Though these macros are just helper ones to simplify the transition.
if someone will prefer to make changes in all their RX/TX function by hand - that is still possible.
> <...>
>
> > +__rte_experimental
> > +rte_eth_rx_burst_t rte_eth_get_rx_burst(uint16_t port_id);
> > +
> > +__rte_experimental
> > +int rte_eth_set_rx_burst(uint16_t port_id, rte_eth_rx_burst_t rxf);
>
> can s/__rte_experimental/__rte_internal/
OK.
> <...>
>
> > +
> > +__rte_experimental
> > +rte_eth_rx_burst_t
> > +rte_eth_get_rx_burst(uint16_t port_id)
> > +{
> > + if (port_id >= RTE_DIM(rte_eth_burst_api)) {
> > + rte_errno = EINVAL;
> > + return NULL;
> > + }
> > + return rte_eth_burst_api[port_id].rx_pkt_burst;
> > +}
> > +
> > +__rte_experimental
> > +int
> > +rte_eth_set_rx_burst(uint16_t port_id, rte_eth_rx_burst_t rxf)
> > +{
> > + if (port_id >= RTE_DIM(rte_eth_burst_api))
> > + return -EINVAL;
> > +
> > + rte_eth_burst_api[port_id].rx_pkt_burst = rxf;
> > + return 0;
> > +}
>
> Since these are internal functions for drivers, it can be easier for drivers to
> use directly with 'struct rte_eth_dev *eth_dev', instead of 'port_id'.
>
> So instead of APIs getting 'port_id' as parameter, they can get 'struct
> rte_eth_dev *eth_dev'? Drivers for sure will have 'eth_dev' references for their
> device.
I am fine either way - it is a control path internal function.
> Overall, I think make sense for all public APIs to have handler ('port_id') as
> parameter, and all driver APIs to have 'eth_device' as paramter.
>
> <...>
>
> > @@ -4981,44 +4981,11 @@ static inline uint16_t
> > rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> > struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
> > {
> > - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > - uint16_t nb_rx;
> > -
> > -#ifdef RTE_ETHDEV_DEBUG_RX
> > - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> > -
> > - if (queue_id >= dev->data->nb_rx_queues) {
> > - RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
> > + if (port_id >= RTE_MAX_ETHPORTS)
>
> As an API, it makes sense to validate the input. But not sure to add these
> checks as part of this set, as previous versions don't have it. Perhaps we can
> add them with separate patch and discussion.
You mean 'if (port_id >= RTE_MAX_ETHPORTS)'?
No, this check is not present in current version.
Obviously, it can be removed, though I think it would be good to have it:
will help to keep thigs less error-prone.
I don’t think it would really impact the performance, in some cases
compiler will even be able to optimise out such check.
> <...>
>
> > +++ b/lib/ethdev/version.map
> > @@ -249,6 +249,11 @@ EXPERIMENTAL {
> > rte_mtr_meter_policy_delete;
> > rte_mtr_meter_policy_update;
> > rte_mtr_meter_policy_validate;
> > +
> > + # added in 21.11
> > + rte_eth_burst_api;
> > + rte_eth_get_rx_burst;
> > + rte_eth_set_rx_burst;
>
> I think these APIs intented to use only by drivers, so instead of experimental,
> they can be added as 'INTERNAL'.
OK.
next prev parent reply other threads:[~2021-09-14 14:28 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 16:28 [dpdk-dev] [RFC 0/7] hide eth dev related structures Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 1/7] eth: move ethdev 'burst' API into separate structure Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 2/7] eth: make drivers to use new API for Rx Konstantin Ananyev
2021-09-06 18:41 ` Ferruh Yigit
2021-09-14 14:28 ` Ananyev, Konstantin [this message]
2021-08-20 16:28 ` [dpdk-dev] [RFC 3/7] eth: make drivers to use new API for Tx Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 4/7] eth: make drivers to use new API for Tx prepare Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 5/7] eth: make drivers to use new API to obtain descriptor status Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 6/7] eth: make drivers to use new API for Rx queue count Konstantin Ananyev
2021-08-20 16:28 ` [dpdk-dev] [RFC 7/7] eth: hide eth dev related structures Konstantin Ananyev
2021-08-26 12:37 ` [dpdk-dev] [RFC 0/7] " Jerin Jacob
2021-09-06 18:09 ` Ferruh Yigit
2021-09-14 13:33 ` Ananyev, Konstantin
2021-09-15 9:45 ` Jerin Jacob
2021-09-22 15:08 ` Ananyev, Konstantin
2021-09-27 16:14 ` Jerin Jacob
2021-09-28 9:37 ` Ananyev, Konstantin
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 0/5] " Konstantin Ananyev
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 1/5] ethdev: allocate max space for internal queue array Konstantin Ananyev
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 2/5] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-09-23 5:51 ` Wang, Haiyue
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 3/5] ethdev: copy ethdev 'burst' API into separate structure Konstantin Ananyev
2021-09-23 5:58 ` Wang, Haiyue
2021-09-27 18:01 ` Jerin Jacob
2021-09-28 9:42 ` Ananyev, Konstantin
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 4/5] ethdev: make burst functions to use new flat array Konstantin Ananyev
2021-09-22 14:09 ` [dpdk-dev] [RFC v2 5/5] ethdev: 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 1/7] ethdev: allocate max space for internal queue array Konstantin Ananyev
2021-10-01 16:48 ` Ferruh Yigit
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 2/7] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 3/7] ethdev: copy ethdev 'fast' API into separate structure Konstantin Ananyev
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 4/7] ethdev: make burst functions to use new flat array Konstantin Ananyev
2021-10-01 16:46 ` Ferruh Yigit
2021-10-01 17:40 ` Ananyev, Konstantin
2021-10-04 8:46 ` Ferruh Yigit
2021-10-04 9:20 ` Ananyev, Konstantin
2021-10-04 10:13 ` Ferruh Yigit
2021-10-04 11:17 ` Ananyev, Konstantin
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 5/7] ethdev: add API to retrieve multiple ethernet addresses Konstantin Ananyev
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 6/7] ethdev: remove legacy Rx descriptor done API Konstantin Ananyev
2021-10-01 14:02 ` [dpdk-dev] [PATCH v3 7/7] ethdev: hide eth dev related structures Konstantin Ananyev
2021-10-01 16:53 ` Ferruh Yigit
2021-10-01 17:04 ` Ferruh Yigit
2021-10-01 17:02 ` [dpdk-dev] [PATCH v3 0/7] " Ferruh Yigit
2021-10-04 13:55 ` [dpdk-dev] [PATCH v4 " Konstantin Ananyev
2021-10-04 13:55 ` [dpdk-dev] [PATCH v4 1/7] ethdev: allocate max space for internal queue array Konstantin Ananyev
2021-10-05 12:09 ` Thomas Monjalon
2021-10-05 16:45 ` Ananyev, Konstantin
2021-10-05 16:49 ` Thomas Monjalon
2021-10-05 12:21 ` Thomas Monjalon
2021-10-04 13:55 ` [dpdk-dev] [PATCH v4 2/7] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-04 13:55 ` [dpdk-dev] [PATCH v4 3/7] ethdev: copy ethdev 'fast' API into separate structure Konstantin Ananyev
2021-10-05 13:09 ` Thomas Monjalon
2021-10-05 16:41 ` Ananyev, Konstantin
2021-10-05 16:48 ` Thomas Monjalon
2021-10-05 17:04 ` Ananyev, Konstantin
2021-10-04 13:56 ` [dpdk-dev] [PATCH v4 4/7] ethdev: make burst functions to use new flat array Konstantin Ananyev
2021-10-05 9:54 ` David Marchand
2021-10-05 10:13 ` Ananyev, Konstantin
2021-10-04 13:56 ` [dpdk-dev] [PATCH v4 5/7] ethdev: add API to retrieve multiple ethernet addresses Konstantin Ananyev
2021-10-05 13:13 ` Thomas Monjalon
2021-10-05 16:35 ` Ananyev, Konstantin
2021-10-05 16:45 ` Thomas Monjalon
2021-10-05 17:12 ` Ananyev, Konstantin
2021-10-05 17:41 ` Thomas Monjalon
2021-10-04 13:56 ` [dpdk-dev] [PATCH v4 6/7] ethdev: remove legacy Rx descriptor done API Konstantin Ananyev
2021-10-05 13:14 ` Thomas Monjalon
2021-10-05 16:21 ` Ananyev, Konstantin
2021-10-04 13:56 ` [dpdk-dev] [PATCH v4 7/7] ethdev: hide eth dev related structures Konstantin Ananyev
2021-10-05 10:04 ` David Marchand
2021-10-05 10:43 ` Ferruh Yigit
2021-10-05 11:37 ` David Marchand
2021-10-05 15:57 ` Ananyev, Konstantin
2021-10-05 13:24 ` Thomas Monjalon
2021-10-05 16:19 ` Ananyev, Konstantin
2021-10-05 16:25 ` Thomas Monjalon
2021-10-06 16:42 ` [dpdk-dev] [PATCH v4 0/7] " Ali Alnubani
2021-10-06 17:26 ` Ali Alnubani
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 " Konstantin Ananyev
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 1/7] ethdev: remove legacy Rx descriptor done API Konstantin Ananyev
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array Konstantin Ananyev
2021-10-11 9:20 ` Andrew Rybchenko
2021-10-11 16:25 ` Ananyev, Konstantin
2021-10-11 17:15 ` Andrew Rybchenko
2021-10-11 23:06 ` Ananyev, Konstantin
2021-10-12 5:47 ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 3/7] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-11 8:06 ` Andrew Rybchenko
2021-10-12 17:59 ` Hyong Youb Kim (hyonkim)
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure Konstantin Ananyev
2021-10-09 12:05 ` fengchengwen
2021-10-11 1:18 ` fengchengwen
2021-10-11 8:39 ` Andrew Rybchenko
2021-10-11 15:24 ` Ananyev, Konstantin
2021-10-11 8:35 ` Andrew Rybchenko
2021-10-11 15:15 ` Ananyev, Konstantin
2021-10-11 8:25 ` Andrew Rybchenko
2021-10-11 16:52 ` Ananyev, Konstantin
2021-10-11 17:22 ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 5/7] ethdev: make fast-path functions to use new flat array Konstantin Ananyev
2021-10-11 9:02 ` Andrew Rybchenko
2021-10-11 15:47 ` Ananyev, Konstantin
2021-10-11 17:03 ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 6/7] ethdev: add API to retrieve multiple ethernet addresses Konstantin Ananyev
2021-10-11 9:09 ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 7/7] ethdev: hide eth dev related structures Konstantin Ananyev
2021-10-11 9:20 ` Andrew Rybchenko
2021-10-11 15:54 ` Ananyev, Konstantin
2021-10-11 17:04 ` Andrew Rybchenko
2021-10-08 18:13 ` [dpdk-dev] [PATCH v5 0/7] " Slava Ovsiienko
2021-10-11 9:22 ` Andrew Rybchenko
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=DM6PR11MB44913D0DC20F834F5320ABD99ADA9@DM6PR11MB4491.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=qiming.yang@intel.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).