DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Hu, Jiayu" <jiayu.hu@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Xia, Chenbo" <chenbo.xia@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6 2/3] vhost: rework async configuration structure
Date: Tue, 20 Jul 2021 07:45:37 +0000	[thread overview]
Message-ID: <000df76841b04021b30ddb496c58a3b4@intel.com> (raw)
In-Reply-To: <4540d13d-d3c2-77d8-0963-70a5ff0ff5a2@redhat.com>



> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, July 20, 2021 3:18 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>; dev@dpdk.org
> Cc: Xia, Chenbo <chenbo.xia@intel.com>
> Subject: Re: [PATCH v6 2/3] vhost: rework async configuration structure
> 
> 
> 
> On 7/19/21 5:00 PM, Jiayu Hu wrote:
> > This patch reworks the async configuration structure to improve code
> > readability. In addition, add preserved padding fields on the
> > structure for future usage.
> >
> > Signed-off-by: Jiayu Hu <jiayu.hu@intel.com>
> > Reviewed-by: Chenbo Xia <chenbo.xia@intel.com>
> > ---
> >  doc/guides/prog_guide/vhost_lib.rst | 21 ++++++++++--------
> >  examples/vhost/main.c               |  8 +++----
> >  lib/vhost/rte_vhost_async.h         | 44 ++++++++++++++++++-------------------
> >  lib/vhost/vhost.c                   | 19 +++++++---------
> >  lib/vhost/vhost.h                   |  3 +--
> >  5 files changed, 46 insertions(+), 49 deletions(-)
> 
> 
> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> 
> Please see one comment below:
> 
> 
> > diff --git a/doc/guides/prog_guide/vhost_lib.rst
> > b/doc/guides/prog_guide/vhost_lib.rst
> > index d18fb98..2a61b85 100644
> > --- a/doc/guides/prog_guide/vhost_lib.rst
> > +++ b/doc/guides/prog_guide/vhost_lib.rst
> > @@ -218,26 +218,29 @@ The following is an overview of some key Vhost
> API functions:
> >
> >    Enable or disable zero copy feature of the vhost crypto backend.
> >
> > -* ``rte_vhost_async_channel_register(vid, queue_id, features, ops)``
> > +* ``rte_vhost_async_channel_register(vid, queue_id, config, ops)``
> >
> > -  Register a vhost queue with async copy device channel after vring
> > -  is enabled. Following device ``features`` must be specified
> > together
> > +  Register an async copy device channel for a vhost queue after vring
> > + is enabled. Following device ``config`` must be specified together
> >    with the registration:
> >
> > -  * ``async_inorder``
> > +  * ``features``
> >
> > -    Async copy device can guarantee the ordering of copy completion
> > -    sequence. Copies are completed in the same order with that at
> > -    the submission time.
> > +    This field is used to specify async copy device features.
> >
> > -    Currently, only ``async_inorder`` capable device is supported by vhost.
> > +    ``RTE_VHOST_ASYNC_INORDER`` represents the async copy device can
> > +    guarantee the order of copy completion is the same as the order
> > +    of copy submission.
> > +
> > +    Currently, only ``RTE_VHOST_ASYNC_INORDER`` capable device is
> > +    supported by vhost.
> >
> >    * ``async_threshold``
> >
> >      The copy length (in bytes) below which CPU copy will be used even if
> >      applications call async vhost APIs to enqueue/dequeue data.
> >
> > -    Typical value is 512~1024 depending on the async device capability.
> > +    Typical value is 256~1024 depending on the async device capability.
> >
> >    Applications must provide following ``ops`` callbacks for vhost lib to
> >    work with the async copy devices:
> > diff --git a/examples/vhost/main.c b/examples/vhost/main.c index
> > d2179ea..9cd855a 100644
> > --- a/examples/vhost/main.c
> > +++ b/examples/vhost/main.c
> > @@ -1468,7 +1468,7 @@ new_device(int vid)
> >  		vid, vdev->coreid);
> >
> >  	if (async_vhost_driver) {
> > -		struct rte_vhost_async_features f;
> > +		struct rte_vhost_async_config config = {0};
> >  		struct rte_vhost_async_channel_ops channel_ops;
> >
> >  		if (dma_type != NULL && strncmp(dma_type, "ioat", 4) == 0)
> { @@
> > -1476,11 +1476,11 @@ new_device(int vid)
> >  			channel_ops.check_completed_copies =
> >  				ioat_check_completed_copies_cb;
> >
> > -			f.async_inorder = 1;
> > -			f.async_threshold = 256;
> > +			config.features = RTE_VHOST_ASYNC_INORDER;
> > +			config.async_threshold = 256;
> >
> >  			return rte_vhost_async_channel_register(vid,
> VIRTIO_RXQ,
> > -				f.intval, &channel_ops);
> > +				config, &channel_ops);
> >  		}
> >  	}
> >
> > diff --git a/lib/vhost/rte_vhost_async.h b/lib/vhost/rte_vhost_async.h
> > index 6faa31f..ef8c1a2 100644
> > --- a/lib/vhost/rte_vhost_async.h
> > +++ b/lib/vhost/rte_vhost_async.h
> > @@ -93,49 +93,47 @@ struct async_inflight_info {  };
> >
> >  /**
> > - *  dma channel feature bit definition
> > + *  async channel features
> >   */
> > -struct rte_vhost_async_features {
> > -	union {
> > -		uint32_t intval;
> > -		struct {
> > -			uint32_t async_inorder:1;
> > -			uint32_t resvd_0:15;
> > -			uint32_t async_threshold:12;
> > -			uint32_t resvd_1:4;
> > -		};
> > -	};
> > +enum {
> > +	RTE_VHOST_ASYNC_INORDER = 1U << 0,
> 
> I think I understand the point of this flag, but the naming is misleading. The
> code later on fails registration if the "INORDER" flag is not passed, but the
> code behaves in the opposite, it does not support Virtio INORDER mode as
> soon as a threashold is used.
> 
> Why do we need the DMA to write the descriptors buffers in order? My
> understanding is that it is an optimization in order to ease the DMA
> completion handling. So we are requiring DMA to be in-order, but on the
> other hand we cannot guarantee the Virtio ring to be handled in order,
> moving the complexity (and potential performance cost) to the guest.

Yes, the reason of requiring dma in-order is to simply vhost for higher performance.
Another reason is that in some cases, where a vring only uses one DMA channel,
the dma device guarantees the ordering already, so dma callback is in-ordered.
For other apps, who want the most complex vring and dma channel mapping, i.e.,
multiple vring use multiple dma, the order is better to be implemented by itself,
i.e., dma callback functions.

If we assume vring and dma channel mapping is M:N, the vhost lib implementation
is going to be more complex. But in my opinion, the mapping relationship of vring and
dma channel is per app specific. Implementing M:N inside vhost will sacrifice performance
for the simplest use case.

Right, the name is misleading, and virtio INORDER mode doesn't work if setting threshold.
But we'd better consider a tradeoff between dma efficiency and out-of-order impacts.
I will measure the performance with removing threshold supporting in the code, and let's
discuss with some data.

Thanks,
Jiayu
> 
> >  };
> >
> >  /**
> > - * register an async channel for vhost
> > + *  async channel configuration
> > + */
> > +struct rte_vhost_async_config {
> > +	uint32_t async_threshold;
> > +	uint32_t features;
> > +	uint32_t rsvd[2];
> > +};
> > +
> > +/**
> > + * Register an async channel for a vhost queue
> >   *
> >   * @param vid
> >   *  vhost device id async channel to be attached to
> >   * @param queue_id
> >   *  vhost queue id async channel to be attached to
> > - * @param features
> > - *  DMA channel feature bit
> > - *    b0       : DMA supports inorder data transfer
> > - *    b1  - b15: reserved
> > - *    b16 - b27: Packet length threshold for DMA transfer
> > - *    b28 - b31: reserved
> > + * @param config
> > + *  Async channel configuration structure
> >   * @param ops
> > - *  DMA operation callbacks
> > + *  Async channel operation callbacks
> >   * @return
> >   *  0 on success, -1 on failures
> >   */
> >  __rte_experimental
> >  int rte_vhost_async_channel_register(int vid, uint16_t queue_id,
> > -	uint32_t features, struct rte_vhost_async_channel_ops *ops);
> > +	struct rte_vhost_async_config config,
> > +	struct rte_vhost_async_channel_ops *ops);
> >
> >  /**
> > - * unregister a dma channel for vhost
> > + * Unregister an async channel for a vhost queue
> >   *
> >   * @param vid
> > - *  vhost device id DMA channel to be detached
> > + *  vhost device id async channel to be detached from
> >   * @param queue_id
> > - *  vhost queue id DMA channel to be detached
> > + *  vhost queue id async channel to be detached from
> >   * @return
> >   *  0 on success, -1 on failures
> >   */
> > diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c index
> > 53a470f..908758e 100644
> > --- a/lib/vhost/vhost.c
> > +++ b/lib/vhost/vhost.c
> > @@ -1619,19 +1619,17 @@ int rte_vhost_extern_callback_register(int vid,
> >  	return 0;
> >  }
> >
> > -int rte_vhost_async_channel_register(int vid, uint16_t queue_id,
> > -					uint32_t features,
> > -					struct rte_vhost_async_channel_ops
> *ops)
> > +int
> > +rte_vhost_async_channel_register(int vid, uint16_t queue_id,
> > +		struct rte_vhost_async_config config,
> > +		struct rte_vhost_async_channel_ops *ops)
> >  {
> >  	struct vhost_virtqueue *vq;
> >  	struct virtio_net *dev = get_device(vid);
> > -	struct rte_vhost_async_features f;
> >
> >  	if (dev == NULL || ops == NULL)
> >  		return -1;
> >
> > -	f.intval = features;
> > -
> >  	if (queue_id >= VHOST_MAX_VRING)
> >  		return -1;
> >
> > @@ -1640,7 +1638,7 @@ int rte_vhost_async_channel_register(int vid,
> uint16_t queue_id,
> >  	if (unlikely(vq == NULL || !dev->async_copy))
> >  		return -1;
> >
> > -	if (unlikely(!f.async_inorder)) {
> > +	if (unlikely(!(config.features & RTE_VHOST_ASYNC_INORDER))) {
> >  		VHOST_LOG_CONFIG(ERR,
> >  			"async copy is not supported on non-inorder mode "
> >  			"(vid %d, qid: %d)\n", vid, queue_id); @@ -1719,9
> +1717,7 @@ int
> > rte_vhost_async_channel_register(int vid, uint16_t queue_id,
> >
> >  	vq->async_ops.check_completed_copies = ops-
> >check_completed_copies;
> >  	vq->async_ops.transfer_data = ops->transfer_data;
> > -
> > -	vq->async_inorder = f.async_inorder;
> > -	vq->async_threshold = f.async_threshold;
> > +	vq->async_threshold = config.async_threshold;
> >
> >  	vq->async_registered = true;
> >
> > @@ -1731,7 +1727,8 @@ int rte_vhost_async_channel_register(int vid,
> uint16_t queue_id,
> >  	return 0;
> >  }
> >
> > -int rte_vhost_async_channel_unregister(int vid, uint16_t queue_id)
> > +int
> > +rte_vhost_async_channel_unregister(int vid, uint16_t queue_id)
> >  {
> >  	struct vhost_virtqueue *vq;
> >  	struct virtio_net *dev = get_device(vid); diff --git
> > a/lib/vhost/vhost.h b/lib/vhost/vhost.h index 8ffe387..d98ca8a 100644
> > --- a/lib/vhost/vhost.h
> > +++ b/lib/vhost/vhost.h
> > @@ -218,9 +218,8 @@ struct vhost_virtqueue {
> >  	};
> >
> >  	/* vq async features */
> > -	bool		async_inorder;
> >  	bool		async_registered;
> > -	uint16_t	async_threshold;
> > +	uint32_t	async_threshold;
> >
> >  	int			notif_enable;
> >  #define VIRTIO_UNINITIALIZED_NOTIF	(-1)
> >


  reply	other threads:[~2021-07-20  7:45 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-28  8:11 [dpdk-dev] [PATCH 0/2] provide thread unsafe async registration functions Jiayu Hu
2021-05-28  8:11 ` [dpdk-dev] [PATCH 1/2] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-02  7:36   ` Maxime Coquelin
2021-07-07 11:18   ` [dpdk-dev] [PATCH v2 0/3] provide thread unsafe async registration functions Jiayu Hu
2021-07-07 11:18     ` [dpdk-dev] [PATCH v2 1/3] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-09  9:43       ` [dpdk-dev] [PATCH v3 0/3] provide thread unsafe async registration functions Jiayu Hu
2021-07-09  9:43         ` [dpdk-dev] [PATCH v3 1/3] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-13  7:46           ` [dpdk-dev] [PATCH v4 0/3] provide thread unsafe async registration functions Jiayu Hu
2021-07-13  7:46             ` [dpdk-dev] [PATCH v4 1/3] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-16 19:51               ` [dpdk-dev] [PATCH v5 0/3] provide thread unsafe async registration functions Jiayu Hu
2021-07-16 19:51                 ` [dpdk-dev] [PATCH v5 1/3] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-19 15:00                   ` [dpdk-dev] [PATCH v6 0/3] provide thread unsafe async registration functions Jiayu Hu
2021-07-19 15:00                     ` [dpdk-dev] [PATCH v6 1/3] vhost: fix lock on device readiness notification Jiayu Hu
2021-07-19 15:00                     ` [dpdk-dev] [PATCH v6 2/3] vhost: rework async configuration structure Jiayu Hu
2021-07-20  7:18                       ` Maxime Coquelin
2021-07-20  7:45                         ` Hu, Jiayu [this message]
2021-07-19 15:00                     ` [dpdk-dev] [PATCH v6 3/3] vhost: add thread unsafe async registeration functions Jiayu Hu
2021-07-20  7:25                       ` Maxime Coquelin
2021-07-21  6:16                     ` [dpdk-dev] [PATCH v6 0/3] provide thread unsafe async registration functions Xia, Chenbo
2021-07-16 19:51                 ` [dpdk-dev] [PATCH v5 2/3] vhost: rework async configuration structure Jiayu Hu
2021-07-19  2:25                   ` Xia, Chenbo
2021-07-19  7:20                   ` Maxime Coquelin
2021-07-16 19:51                 ` [dpdk-dev] [PATCH v5 3/3] vhost: add thread unsafe async registeration functions Jiayu Hu
2021-07-19  2:27                   ` Xia, Chenbo
2021-07-13  7:46             ` [dpdk-dev] [PATCH v4 2/3] vhost: rework async configuration struct Jiayu Hu
2021-07-16  6:03               ` Xia, Chenbo
2021-07-16  6:18                 ` Hu, Jiayu
2021-07-16  6:27                   ` Xia, Chenbo
2021-07-16  6:34                     ` Hu, Jiayu
2021-07-13  7:46             ` [dpdk-dev] [PATCH v4 3/3] vhost: add thread unsafe async registeration functions Jiayu Hu
2021-07-16  6:54               ` Xia, Chenbo
2021-07-09  9:43         ` [dpdk-dev] [PATCH v3 2/3] vhost: rework async configuration struct Jiayu Hu
2021-07-09  9:43         ` [dpdk-dev] [PATCH v3 3/3] vhost: add thread unsafe async registeration functions Jiayu Hu
2021-07-07 11:18     ` [dpdk-dev] [PATCH v2 2/3] vhost: rework async feature struct Jiayu Hu
2021-07-07  6:39       ` Maxime Coquelin
2021-07-07 11:18     ` [dpdk-dev] [PATCH v2 3/3] vhost: add thread unsafe async registeration functions Jiayu Hu
2021-05-28  8:11 ` [dpdk-dev] [PATCH 2/2] vhost: add thread unsafe async registration functions Jiayu Hu
2021-07-02  7:40   ` Maxime Coquelin
2021-07-05  1:35     ` Hu, Jiayu
2021-07-05  8:58   ` Maxime Coquelin
2021-07-06  8:36     ` Hu, Jiayu
2021-06-04  7:18 ` [dpdk-dev] [PATCH 0/2] provide " Maxime Coquelin
2021-06-04  7:24 ` Maxime Coquelin
2021-06-07  8:07   ` Hu, Jiayu
2021-06-07 13:20     ` Maxime Coquelin
2021-06-08  6:36       ` Hu, Jiayu
2021-06-29  5:36       ` Hu, Jiayu
2021-07-01 15:42         ` Maxime Coquelin
2021-07-02  0:53           ` Hu, Jiayu

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=000df76841b04021b30ddb496c58a3b4@intel.com \
    --to=jiayu.hu@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.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).