From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"thomas@monjalon.net" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Xing, Beilei" <beilei.xing@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
Date: Fri, 16 Mar 2018 00:42:16 +0000 [thread overview]
Message-ID: <039ED4275CED7440929022BC67E706115316E424@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772589E2902E9@irsmsx105.ger.corp.intel.com>
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 11:39 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>; thomas@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
>
>
>
> > -----Original Message-----
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 3:09 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> > thomas@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > setup
> >
> >
> >
> > > -----Original Message-----
> > > From: Ananyev, Konstantin
> > > Sent: Thursday, March 15, 2018 9:17 PM
> > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; thomas@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing
> > > <jingjing.wu@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > > setup
> > >
> > > Hi Qi,
> > >
> > > > -----Original Message-----
> > > > From: Zhang, Qi Z
> > > > Sent: Thursday, March 15, 2018 3:14 AM
> > > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> > > > thomas@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu,
> > > > Jingjing <jingjing.wu@intel.com>; Lu, Wenzhuo
> > > > <wenzhuo.lu@intel.com>
> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred
> > > > queue setup
> > > >
> > > > Hi Konstantin:
> > > >
> > > > > -----Original Message-----
> > > > > From: Ananyev, Konstantin
> > > > > Sent: Wednesday, March 14, 2018 8:32 PM
> > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; thomas@monjalon.net
> > > > > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Wu,
> > > > > Jingjing <jingjing.wu@intel.com>; Lu, Wenzhuo
> > > > > <wenzhuo.lu@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred
> > > > > queue setup
> > > > >
> > > > > Hi Qi,
> > > > >
> > > > > >
> > > > > > The patch let etherdev driver expose the capability flag
> > > > > > through rte_eth_dev_info_get when it support deferred queue
> > > > > > configuraiton, then base on the flag
> > > > > > rte_eth_[rx|tx]_queue_setup could decide continue to setup the
> > > > > > queue or just return fail when device already started.
> > > > > >
> > > > > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> > > > > > ---
> > > > > > doc/guides/nics/features.rst | 8 ++++++++
> > > > > > lib/librte_ether/rte_ethdev.c | 30
> > > > > > ++++++++++++++++++------------ lib/librte_ether/rte_ethdev.h |
> > > > > > 11 +++++++++++
> > > > > > 3 files changed, 37 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/doc/guides/nics/features.rst
> > > > > > b/doc/guides/nics/features.rst index 1b4fb979f..36ad21a1f
> > > > > > 100644
> > > > > > --- a/doc/guides/nics/features.rst
> > > > > > +++ b/doc/guides/nics/features.rst
> > > > > > @@ -892,7 +892,15 @@ Documentation describes performance
> > > values.
> > > > > >
> > > > > > See ``dpdk.org/doc/perf/*``.
> > > > > >
> > > > > > +.. _nic_features_queue_deferred_setup_capabilities:
> > > > > >
> > > > > > +Queue deferred setup capabilities
> > > > > > +---------------------------------
> > > > > > +
> > > > > > +Supports queue setup / release after device started.
> > > > > > +
> > > > > > +* **[provides] rte_eth_dev_info**:
> > > > > >
> > > > >
> > >
> ``deferred_queue_config_capa:DEV_DEFERRED_RX_QUEUE_SETUP,DEV_DEFE
> > > > > RRED_
> > > > > > TX_QUEUE_SETUP,DEV_DEFERRED_RX_QUEUE_RELE
> > > > > > ASE,DEV_DEFERRED_TX_QUEUE_RELEASE``.
> > > > > > +* **[related] API**: ``rte_eth_dev_info_get()``.
> > > > > >
> > > > > > .. _nic_features_other:
> > > > > >
> > > > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > > > b/lib/librte_ether/rte_ethdev.c index a6ce2a5ba..6c906c4df
> > > > > > 100644
> > > > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > > > @@ -1425,12 +1425,6 @@ rte_eth_rx_queue_setup(uint16_t
> > > > > > port_id,
> > > > > uint16_t rx_queue_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > - if (dev->data->dev_started) {
> > > > > > - RTE_PMD_DEBUG_TRACE(
> > > > > > - "port %d must be stopped to allow configuration\n",
> > > port_id);
> > > > > > - return -EBUSY;
> > > > > > - }
> > > > > > -
> > > > > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get,
> > > > > -ENOTSUP);
> > > > > >
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_setup,
> > > > > -ENOTSUP);
> > > > > >
> > > > > > @@ -1474,10 +1468,19 @@ rte_eth_rx_queue_setup(uint16_t
> > > port_id,
> > > > > uint16_t rx_queue_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > + if (dev->data->dev_started &&
> > > > > > + !(dev_info.deferred_queue_config_capa &
> > > > > > + DEV_DEFERRED_RX_QUEUE_SETUP))
> > > > > > + return -EINVAL;
> > > > > > +
> > > > >
> > > > > I think now you have to check here that the queue is stopped.
> > > > > Otherwise you might attempt to reconfigure running queue.
> > > >
> > > > I'm not sure if it's necessary to let application use different
> > > > API sequence
> > > for a deferred configure and deferred re-configure.
> > > > Can we just call dev_ops->rx_queue_stop before rx_queue_release
> > > > here
> > >
> > > I don't follow you here.
> > > Let say now inside queue_start() we do check:
> > >
> > > if (dev->data->rx_queue_state[rx_queue_id] !=
> > > RTE_ETH_QUEUE_STATE_STOPPED)
> > >
> > > Right now it is not possible to call queue_setup() without
> > > dev_stop() before it - that's why we have check if
> > > (dev->data->dev_started) in queue_setup() right now.
> > > Though with your patch it not the case anymore - user is able to
> > > call
> > > queue_setup() without stopping the whole device.
> > > But he still has to stop the queue.
> >
> > >
> > > >
> > > > >
> > > > >
> > > > > > rxq = dev->data->rx_queues;
> > > > > > if (rxq[rx_queue_id]) {
> > > > > >
> > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_release,
> > > > > > -ENOTSUP);
> > > > >
> > > > > I don't think it is *that* straightforward.
> > > > > rx_queue_setup() parameters can imply different rx function (and
> > > > > related dev
> > > > > icesettings) that are already setuped by previous
> > > queue_setup()/dev_start.
> > > > > So I think you need to do one of 2 things:
> > > > > 1. rework ethdev layer to introduce a separate rx function (and
> > > > > related
> > > > > settings) for each queue.
> > > > > 2. at rx_queue_setup() if it is invoked after dev_start - check
> > > > > that given queue settings wouldn't contradict with current
> > > > > device settings (rx function, etc.).
> > > > > If they do - return an error.
> > > > Yes, I think what we have is option 2 here, the
> > > > dev_ops->rx_queue_setup will return fail if conflict with previous
> > > > setting
> > >
> > > Hmm and what makes you think that?
> > > As I know it is not the case right now.
> > > Let say I do:
> > > ....
> > > rx_queue_setup(port=0,queue=0, mp=mb_size_2048);
> > > dev_start(port=0);
> > > ...
> > > rx_queue_setup(port=0,queue=1,mp=mb_size_1024);
> > >
> > > If current rx function doesn't support multi-segs then second
> > > rx_queue_setup() should fail.
> > > Though I don't think that would happen with the current
> implementation.
> >
> > Why you think that would not happen? dev_ops->rx_queue_setup can fail,
> right?
> > I mean it's the responsibility of low level driver (i40e) to check the conflict
> with current implementation.
>
> Yes it is responsibility if the PMD because only it knows its own logic of rx/tx
> function selection.
> But I don't see such changes in i40e in your patch series.
> Probably I missed them?
OK, I think we are aligned on this patch, and I see the problem in i40e patch, will fix.
>
> > >
> > > Same story for TX offloads, though it probably not that critical, as
> > > for most Intel PMDs HW TX offloads will become per port in 18.05.
> > >
> > > As I can see you do have either of these options implemented right
> > > now - that's the problem.
> > >
> > > > I'm also thinking about option 1, the idea is to move per queue
> > > > rx/tx
> > > function into driver layer, so it will not break existing API.
> > > >
> > > > 1. driver can expose the capability like per_queue_rx or
> > > > per_queue_tx 2. application can enable this capability by
> > > > dev_config with rte_eth_conf 3, if per_queue_rx is not enable,
> > > > nothing change, so we are at option 2 4. if per_queue_rx is
> > > > enabled, driver will set rx_pkt_burst with a hook function which
> > > > redirect to an function ptr in a per queue rx function tables ( I
> > > > guess performance is impacted somehow, but this is the cost if you
> > > > want different offload for different queue)
> > >
> > > I don't think we need to overcomplicate things here.
> > > It should be transparent to the user - user just calls queue_setup()
> > > - based on its input parameters PMD selects a function that fits best.
> > > Pretty much what we have right now, just possibly have an array of
> > > functions (one per queue).
> >
> > If we don't introduce a new capability or something like, but just
> > take per queue functions as default way, does that mean, we need to
> change all drivers to adapt this?
> > Or do you mean below?
> >
> > If (dev->rx_pkt_burst)
> > /* default way */
> > else
> > /* per queue function */
>
> For me either way seems ok.
> Second one probably a bit easier, as no changes from PMDs are required.
> But again - might be even rte_ethdev layer can fill queue's rx_pkt_burst[]
> array for the drivers that don't support it - just by copying dev->rx_pkt_burst
> into it.
> Konstantin
Ok, I will add this in v2
Thanks
Qi
next prev parent reply other threads:[~2018-03-16 0:42 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 4:53 [dpdk-dev] [PATCH 0/4] " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 1/4] ether: support " Qi Zhang
2018-02-12 13:55 ` Thomas Monjalon
2018-02-12 4:53 ` [dpdk-dev] [PATCH 2/4] app/testpmd: add parameters for " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 3/4] app/testpmd: add command for " Qi Zhang
2018-02-12 4:53 ` [dpdk-dev] [PATCH 4/4] net/i40e: enable deferred " Qi Zhang
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 0/4] " Qi Zhang
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 1/4] ether: support " Qi Zhang
2018-03-14 12:31 ` Ananyev, Konstantin
2018-03-15 3:13 ` Zhang, Qi Z
2018-03-15 13:16 ` Ananyev, Konstantin
2018-03-15 15:08 ` Zhang, Qi Z
2018-03-15 15:38 ` Ananyev, Konstantin
2018-03-16 0:42 ` Zhang, Qi Z [this message]
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for " Qi Zhang
2018-03-14 17:38 ` Ananyev, Konstantin
2018-03-15 3:58 ` Zhang, Qi Z
2018-03-15 13:42 ` Ananyev, Konstantin
2018-03-15 14:31 ` Zhang, Qi Z
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 3/4] app/testpmd: add command for " Qi Zhang
2018-03-14 17:36 ` Ananyev, Konstantin
2018-03-14 17:41 ` Ananyev, Konstantin
2018-03-15 3:59 ` Zhang, Qi Z
2018-03-02 4:13 ` [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred " Qi Zhang
2018-03-14 12:35 ` Ananyev, Konstantin
2018-03-15 3:22 ` Zhang, Qi Z
2018-03-15 3:50 ` Zhang, Qi Z
2018-03-15 13:22 ` Ananyev, Konstantin
2018-03-15 14:30 ` Zhang, Qi Z
2018-03-15 15:22 ` Ananyev, Konstantin
2018-03-16 0:52 ` Zhang, Qi Z
2018-03-16 9:54 ` Ananyev, Konstantin
2018-03-16 11:00 ` Bruce Richardson
2018-03-16 13:18 ` Zhang, Qi Z
2018-03-16 14:15 ` Zhang, Qi Z
2018-03-16 18:47 ` Ananyev, Konstantin
2018-03-18 7:55 ` Zhang, Qi Z
2018-03-20 13:18 ` Ananyev, Konstantin
2018-03-21 1:53 ` Zhang, Qi Z
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 0/3] runtime " Qi Zhang
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 1/3] ether: support " Qi Zhang
2018-03-25 19:47 ` Ananyev, Konstantin
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 2/3] app/testpmd: add command for " Qi Zhang
2018-03-21 7:28 ` [dpdk-dev] [PATCH v3 3/3] net/i40e: enable runtime " Qi Zhang
2018-03-25 19:46 ` Ananyev, Konstantin
2018-03-26 8:49 ` Zhang, Qi Z
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 0/3] " Qi Zhang
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 1/3] ether: support " Qi Zhang
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 2/3] app/testpmd: add command for " Qi Zhang
2018-04-01 12:21 ` Ananyev, Konstantin
2018-03-26 8:59 ` [dpdk-dev] [PATCH v4 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-01 12:18 ` Ananyev, Konstantin
2018-04-02 2:20 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 0/3] " Qi Zhang
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 1/3] ether: support " Qi Zhang
2018-04-06 19:42 ` Rosen, Rami
2018-04-08 2:20 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 2/3] app/testpmd: add command for " Qi Zhang
2018-04-07 15:49 ` Rosen, Rami
2018-04-08 2:22 ` Zhang, Qi Z
2018-04-02 2:59 ` [dpdk-dev] [PATCH v5 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-02 23:36 ` [dpdk-dev] [PATCH v5 0/3] " Ananyev, Konstantin
2018-04-08 2:42 ` Qi Zhang
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 1/3] ether: support " Qi Zhang
2018-04-10 13:59 ` Thomas Monjalon
2018-04-20 11:14 ` Ferruh Yigit
2018-04-24 19:36 ` Thomas Monjalon
2018-04-25 5:33 ` Zhang, Qi Z
2018-04-25 7:54 ` Thomas Monjalon
2018-04-20 11:16 ` Ferruh Yigit
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 2/3] app/testpmd: add command for " Qi Zhang
2018-04-20 11:29 ` Ferruh Yigit
2018-04-22 11:57 ` Zhang, Qi Z
2018-04-08 2:42 ` [dpdk-dev] [PATCH v6 3/3] net/i40e: enable runtime " Qi Zhang
2018-04-20 11:17 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 0/5] " Qi Zhang
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 1/5] ethdev: support " Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 2/5] app/testpmd: add command for " Qi Zhang
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 3/5] app/testpmd: enable per queue configure Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 4/5] app/testpmd: enable queue ring size configure Qi Zhang
2018-04-23 17:45 ` Ferruh Yigit
2018-04-24 3:16 ` Zhang, Qi Z
2018-04-24 11:05 ` Ferruh Yigit
2018-04-22 11:58 ` [dpdk-dev] [PATCH v7 5/5] net/i40e: enable runtime queue setup Qi Zhang
2018-04-23 17:45 ` [dpdk-dev] [PATCH v7 0/5] " Ferruh Yigit
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 " Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 1/5] ethdev: support " Qi Zhang
2018-04-24 14:01 ` Thomas Monjalon
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 2/5] app/testpmd: add command for " Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 3/5] app/testpmd: enable per queue configure Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 4/5] app/testpmd: enable queue ring size configure Qi Zhang
2018-04-24 12:44 ` [dpdk-dev] [PATCH v8 5/5] net/i40e: enable runtime queue setup Qi Zhang
2018-04-24 14:50 ` [dpdk-dev] [PATCH v8 0/5] " Ferruh Yigit
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=039ED4275CED7440929022BC67E706115316E424@SHSMSX103.ccr.corp.intel.com \
--to=qi.z.zhang@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=thomas@monjalon.net \
--cc=wenzhuo.lu@intel.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 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).