[v2,2/2] net/mlx5: add flow sync API

  When creating a flow, the rule itself might not take effort
immediately once the function call returns with success. It would
take some time to let the steering synchronize with the hardware.

If the application wants the packet to be sent to hit the flow after
it is created, this flow sync API can be used to clear the steering
HW cache to enforce next packet hits the latest rules.

For TX, usually the NIC TX domain and/or the FDB domain should be
synchronized depends in which domain the flow is created.

The application could also try to synchronize the NIC RX and/or the
FDB domain for the ingress packets.

Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c       | 24 ++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow.h       |  5 +++++
 drivers/net/mlx5/mlx5_flow_dv.c    | 27 +++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5_flow_verbs.c | 12 ++++++++++++
 drivers/net/mlx5/rte_pmd_mlx5.h    | 25 +++++++++++++++++++++++++
 drivers/net/mlx5/version.map       |  2 ++
 6 files changed, 95 insertions(+)
  

Hi, Bing

Release notes / mlx5 features documentation update?
Beside this:
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>

> -----Original Message-----
> From: Bing Zhao <bingz@nvidia.com>
> Sent: Tuesday, October 27, 2020 16:47
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: [PATCH v2 2/2] net/mlx5: add flow sync API
> 
> When creating a flow, the rule itself might not take effort immediately once
> the function call returns with success. It would take some time to let the
> steering synchronize with the hardware.
> 
> If the application wants the packet to be sent to hit the flow after it is created,
> this flow sync API can be used to clear the steering HW cache to enforce next
> packet hits the latest rules.
> 
> For TX, usually the NIC TX domain and/or the FDB domain should be
> synchronized depends in which domain the flow is created.
> 
> The application could also try to synchronize the NIC RX and/or the FDB
> domain for the ingress packets.
> 
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> ---
>  drivers/net/mlx5/mlx5_flow.c       | 24 ++++++++++++++++++++++++
>  drivers/net/mlx5/mlx5_flow.h       |  5 +++++
>  drivers/net/mlx5/mlx5_flow_dv.c    | 27 +++++++++++++++++++++++++++
>  drivers/net/mlx5/mlx5_flow_verbs.c | 12 ++++++++++++
>  drivers/net/mlx5/rte_pmd_mlx5.h    | 25 +++++++++++++++++++++++++
>  drivers/net/mlx5/version.map       |  2 ++
>  6 files changed, 95 insertions(+)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c index
> 02e19e8..8a1d8da 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -32,6 +32,7 @@
>  #include "mlx5_flow_os.h"
>  #include "mlx5_rxtx.h"
>  #include "mlx5_common_os.h"
> +#include "rte_pmd_mlx5.h"
> 
>  static struct mlx5_flow_tunnel *
>  mlx5_find_tunnel_id(struct rte_eth_dev *dev, uint32_t id); @@ -3043,6
> +3044,14 @@ struct mlx5_flow_tunnel_info {
>  				  RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> NULL, NULL);  }
> 
> +static int
> +flow_null_sync_domain(struct rte_eth_dev *dev __rte_unused,
> +		      uint32_t domains __rte_unused,
> +		      uint32_t flags __rte_unused)
> +{
> +	return 0;
> +}
> +
>  /* Void driver to protect from null pointer reference. */  const struct
> mlx5_flow_driver_ops mlx5_flow_null_drv_ops = {
>  	.validate = flow_null_validate,
> @@ -3052,6 +3061,7 @@ struct mlx5_flow_tunnel_info {
>  	.remove = flow_null_remove,
>  	.destroy = flow_null_destroy,
>  	.query = flow_null_query,
> +	.sync_domain = flow_null_sync_domain,
>  };
> 
>  /**
> @@ -8169,3 +8179,17 @@ int mlx5_alloc_tunnel_hub(struct
> mlx5_dev_ctx_shared *sh)
>  		mlx5_free(thub);
>  	return err;
>  }
> +
> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains) {
> +	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> +	const struct mlx5_flow_driver_ops *fops;
> +	int ret;
> +	struct rte_flow_attr attr = { .transfer = 0 };
> +
> +	fops = flow_get_drv_ops(flow_get_drv_type(dev, &attr));
> +	ret = fops->sync_domain(dev, domains,
> MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW);
> +	if (ret > 0)
> +		ret = -ret;
> +	return ret;
> +}
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 8b5a93f..a22ae21 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -1176,6 +1176,10 @@ typedef int (*mlx5_flow_action_update_t)
>  			 struct rte_flow_shared_action *action,
>  			 const void *action_conf,
>  			 struct rte_flow_error *error);
> +typedef int (*mlx5_flow_sync_domain_t)
> +			(struct rte_eth_dev *dev,
> +			 uint32_t domains,
> +			 uint32_t flags);
>  struct mlx5_flow_driver_ops {
>  	mlx5_flow_validate_t validate;
>  	mlx5_flow_prepare_t prepare;
> @@ -1196,6 +1200,7 @@ struct mlx5_flow_driver_ops {
>  	mlx5_flow_action_create_t action_create;
>  	mlx5_flow_action_destroy_t action_destroy;
>  	mlx5_flow_action_update_t action_update;
> +	mlx5_flow_sync_domain_t sync_domain;
>  };
> 
>  /* mlx5_flow.c */
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index dafe07f..945eae6 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -33,6 +33,7 @@
>  #include "mlx5_flow.h"
>  #include "mlx5_flow_os.h"
>  #include "mlx5_rxtx.h"
> +#include "rte_pmd_mlx5.h"
> 
>  #ifdef HAVE_IBV_FLOW_DV_SUPPORT
> 
> @@ -12310,6 +12311,31 @@ struct field_modify_info modify_tcp[] = {
>  	return ret;
>  }
> 
> +static int
> +flow_dv_sync_domain(struct rte_eth_dev *dev, uint32_t domains, uint32_t
> +flags) {
> +	struct mlx5_priv *priv = dev->data->dev_private;
> +	int ret = 0;
> +
> +	if ((domains & MLX5_DOMAIN_BIT_NIC_RX) && priv->sh->rx_domain
> != NULL) {
> +		ret = mlx5_glue->dr_sync_domain(priv->sh->rx_domain,
> +						flags);
> +		if (ret != 0)
> +			return ret;
> +	}
> +	if ((domains & MLX5_DOMAIN_BIT_NIC_TX) && priv->sh->tx_domain
> != NULL) {
> +		ret = mlx5_glue->dr_sync_domain(priv->sh->tx_domain, flags);
> +		if (ret != 0)
> +			return ret;
> +	}
> +	if ((domains & MLX5_DOMAIN_BIT_FDB) && priv->sh->fdb_domain !=
> NULL) {
> +		ret = mlx5_glue->dr_sync_domain(priv->sh->fdb_domain,
> flags);
> +		if (ret != 0)
> +			return ret;
> +	}
> +	return 0;
> +}
> +
>  const struct mlx5_flow_driver_ops mlx5_flow_dv_drv_ops = {
>  	.validate = flow_dv_validate,
>  	.prepare = flow_dv_prepare,
> @@ -12330,6 +12356,7 @@ struct field_modify_info modify_tcp[] = {
>  	.action_create = flow_dv_action_create,
>  	.action_destroy = flow_dv_action_destroy,
>  	.action_update = flow_dv_action_update,
> +	.sync_domain = flow_dv_sync_domain,
>  };
> 
>  #endif /* HAVE_IBV_FLOW_DV_SUPPORT */
> diff --git a/drivers/net/mlx5/mlx5_flow_verbs.c
> b/drivers/net/mlx5/mlx5_flow_verbs.c
> index 6bcc009..d04c37f 100644
> --- a/drivers/net/mlx5/mlx5_flow_verbs.c
> +++ b/drivers/net/mlx5/mlx5_flow_verbs.c
> @@ -2078,6 +2078,17 @@
>  	return ret;
>  }
> 
> +static int
> +flow_verbs_sync_domain(struct rte_eth_dev *dev, uint32_t domains,
> +		       uint32_t flags)
> +{
> +	RTE_SET_USED(dev);
> +	RTE_SET_USED(domains);
> +	RTE_SET_USED(flags);
> +
> +	return 0;
> +}
> +
>  const struct mlx5_flow_driver_ops mlx5_flow_verbs_drv_ops = {
>  	.validate = flow_verbs_validate,
>  	.prepare = flow_verbs_prepare,
> @@ -2086,4 +2097,5 @@
>  	.remove = flow_verbs_remove,
>  	.destroy = flow_verbs_destroy,
>  	.query = flow_verbs_query,
> +	.sync_domain = flow_verbs_sync_domain,
>  };
> diff --git a/drivers/net/mlx5/rte_pmd_mlx5.h
> b/drivers/net/mlx5/rte_pmd_mlx5.h index 8c69228..e531e52 100644
> --- a/drivers/net/mlx5/rte_pmd_mlx5.h
> +++ b/drivers/net/mlx5/rte_pmd_mlx5.h
> @@ -32,4 +32,29 @@
>  __rte_experimental
>  int rte_pmd_mlx5_get_dyn_flag_names(char *names[], unsigned int n);
> 
> +#define MLX5_DOMAIN_BIT_NIC_RX	(1 << 0) /**< NIC RX domain bit mask.
> */
> +#define MLX5_DOMAIN_BIT_NIC_TX	(1 << 1) /**< NIC TX domain bit mask.
> */
> +#define MLX5_DOMAIN_BIT_FDB	(1 << 2) /**< FDB (TX + RX) domain bit
> mask. */
> +
> +/**
> + * Synchronize the flows to make them take effort on hardware.
> + * It only supports DR flows now. For DV and Verbs flows, there is no
> +need to
> + * call this function, and a success will return directly in case of Verbs.
> + *
> + * @param[in] port_id
> + *   The port identifier of the Ethernet device.
> + * @param[in] domains
> + *   Refer to "/usr/include/infiniband/mlx5dv.h".
> + *   Bitmask of domains in which the synchronization will be done.
> + *   MLX5_DOMAIN_BIT* macros are used to specify the domains.
> + *   An ADD or OR operation could be used to synchronize flows in more than
> + *   one domain per call.
> + *
> + * @return
> + *   - (0) if successful.
> + *   - Negative value if an error.
> + */
> +__rte_experimental
> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains);
> +
>  #endif
> diff --git a/drivers/net/mlx5/version.map b/drivers/net/mlx5/version.map
> index bc1d3d0..82a32b5 100644
> --- a/drivers/net/mlx5/version.map
> +++ b/drivers/net/mlx5/version.map
> @@ -7,4 +7,6 @@ EXPERIMENTAL {
> 
>  	# added in 20.02
>  	rte_pmd_mlx5_get_dyn_flag_names;
> +	# added in 20.11
> +	rte_pmd_mlx5_sync_flow;
>  };
> --
> 1.8.3.1
  

On 10/27/2020 3:42 PM, Slava Ovsiienko wrote:
> Hi, Bing
> 
> Release notes / mlx5 features documentation update?
> Beside this:
> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> 
>> -----Original Message-----
>> From: Bing Zhao <bingz@nvidia.com>
>> Sent: Tuesday, October 27, 2020 16:47
>> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
>> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>
>> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
>> Subject: [PATCH v2 2/2] net/mlx5: add flow sync API
>>
>> When creating a flow, the rule itself might not take effort immediately once
>> the function call returns with success. It would take some time to let the
>> steering synchronize with the hardware.
>>
>> If the application wants the packet to be sent to hit the flow after it is created,
>> this flow sync API can be used to clear the steering HW cache to enforce next
>> packet hits the latest rules.
>>
>> For TX, usually the NIC TX domain and/or the FDB domain should be
>> synchronized depends in which domain the flow is created.
>>
>> The application could also try to synchronize the NIC RX and/or the FDB
>> domain for the ingress packets.
>>
>> Signed-off-by: Bing Zhao <bingz@nvidia.com>
>> Acked-by: Ori Kam <orika@nvidia.com>

<...>

>> @@ -8169,3 +8179,17 @@ int mlx5_alloc_tunnel_hub(struct
>> mlx5_dev_ctx_shared *sh)
>>   		mlx5_free(thub);
>>   	return err;
>>   }
>> +
>> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains) {
>> +	struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>> +	const struct mlx5_flow_driver_ops *fops;
>> +	int ret;
>> +	struct rte_flow_attr attr = { .transfer = 0 };
>> +
>> +	fops = flow_get_drv_ops(flow_get_drv_type(dev, &attr));
>> +	ret = fops->sync_domain(dev, domains,
>> MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW);
>> +	if (ret > 0)
>> +		ret = -ret;
>> +	return ret;
>> +}

This is causing build error in the travis [1], I guess this is related to the 
rdma-core version, is the 'MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW' check required in the 
header like other usages?

Also 'MLX5DV_' macros seems used in 'mlx5_flow_dv.c', is it expected to use it 
in this file? (just high-level observation, no idea on details.)

[1] https://travis-ci.org/github/ferruhy/dpdk/jobs/740008969



btw, I just recognized that the patch acked with exception, is the documentation 
requested above (with ack) provided?
  

Hi Ferruh,
Thanks for your comments.
PSB

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Friday, October 30, 2020 6:43 AM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Bing Zhao
> <bingz@nvidia.com>; Matan Azrad <matan@nvidia.com>; Ori Kam
> <orika@nvidia.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add flow sync API
> 
> External email: Use caution opening links or attachments
> 
> 
> On 10/27/2020 3:42 PM, Slava Ovsiienko wrote:
> > Hi, Bing
> >
> > Release notes / mlx5 features documentation update?
> > Beside this:
> > Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> >
> >> -----Original Message-----
> >> From: Bing Zhao <bingz@nvidia.com>
> >> Sent: Tuesday, October 27, 2020 16:47
> >> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
> >> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>
> >> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> >> Subject: [PATCH v2 2/2] net/mlx5: add flow sync API
> >>
> >> When creating a flow, the rule itself might not take effort
> >> immediately once the function call returns with success. It would
> >> take some time to let the steering synchronize with the hardware.
> >>
> >> If the application wants the packet to be sent to hit the flow
> after
> >> it is created, this flow sync API can be used to clear the
> steering
> >> HW cache to enforce next packet hits the latest rules.
> >>
> >> For TX, usually the NIC TX domain and/or the FDB domain should be
> >> synchronized depends in which domain the flow is created.
> >>
> >> The application could also try to synchronize the NIC RX and/or
> the
> >> FDB domain for the ingress packets.
> >>
> >> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> >> Acked-by: Ori Kam <orika@nvidia.com>
> 
> <...>
> 
> >> @@ -8169,3 +8179,17 @@ int mlx5_alloc_tunnel_hub(struct
> >> mlx5_dev_ctx_shared *sh)
> >>              mlx5_free(thub);
> >>      return err;
> >>   }
> >> +
> >> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains) {
> >> +    struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> >> +    const struct mlx5_flow_driver_ops *fops;
> >> +    int ret;
> >> +    struct rte_flow_attr attr = { .transfer = 0 };
> >> +
> >> +    fops = flow_get_drv_ops(flow_get_drv_type(dev, &attr));
> >> +    ret = fops->sync_domain(dev, domains,
> >> MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW);
> >> +    if (ret > 0)
> >> +            ret = -ret;
> >> +    return ret;
> >> +}
> 
> This is causing build error in the travis [1], I guess this is
> related to the rdma-core version, is the
> 'MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW' check required in the header like
> other usages?
> 
> Also 'MLX5DV_' macros seems used in 'mlx5_flow_dv.c', is it expected
> to use it in this file? (just high-level observation, no idea on
> details.)

I send a fix for this already yesterday, and the issue should be solved.
That fix could be squashed.
http://patches.dpdk.org/patch/82652/

> 
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftr
> avis-
> ci.org%2Fgithub%2Fferruhy%2Fdpdk%2Fjobs%2F740008969&amp;data=04%7C01
> %7Cbingz%40nvidia.com%7C59346fa41fce41e08cce08d87c5c1667%7C43083d157
> 27340c1b7db39efd9ccc17a%7C0%7C0%7C637396082238282132%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&amp;sdata=HGY7vbWWR5ZdIikv39IzZAYcdsJq1FvGjuonClJo%2B
> Pc%3D&amp;reserved=0
> 
> 
> 
> btw, I just recognized that the patch acked with exception, is the
> documentation requested above (with ack) provided?

This is a quite simple internal API. The usage and the information are listed in the API doxygen comments.
Do I need to list it in the doc?

Thanks
  

On 10/30/2020 5:37 AM, Bing Zhao wrote:
> Hi Ferruh,
> Thanks for your comments.
> PSB
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Friday, October 30, 2020 6:43 AM
>> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Bing Zhao
>> <bingz@nvidia.com>; Matan Azrad <matan@nvidia.com>; Ori Kam
>> <orika@nvidia.com>
>> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
>> Subject: Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add flow sync API
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 10/27/2020 3:42 PM, Slava Ovsiienko wrote:
>>> Hi, Bing
>>>
>>> Release notes / mlx5 features documentation update?
>>> Beside this:
>>> Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
>>>
>>>> -----Original Message-----
>>>> From: Bing Zhao <bingz@nvidia.com>
>>>> Sent: Tuesday, October 27, 2020 16:47
>>>> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Matan Azrad
>>>> <matan@nvidia.com>; Ori Kam <orika@nvidia.com>
>>>> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
>>>> Subject: [PATCH v2 2/2] net/mlx5: add flow sync API
>>>>
>>>> When creating a flow, the rule itself might not take effort
>>>> immediately once the function call returns with success. It would
>>>> take some time to let the steering synchronize with the hardware.
>>>>
>>>> If the application wants the packet to be sent to hit the flow
>> after
>>>> it is created, this flow sync API can be used to clear the
>> steering
>>>> HW cache to enforce next packet hits the latest rules.
>>>>
>>>> For TX, usually the NIC TX domain and/or the FDB domain should be
>>>> synchronized depends in which domain the flow is created.
>>>>
>>>> The application could also try to synchronize the NIC RX and/or
>> the
>>>> FDB domain for the ingress packets.
>>>>
>>>> Signed-off-by: Bing Zhao <bingz@nvidia.com>
>>>> Acked-by: Ori Kam <orika@nvidia.com>
>>
>> <...>
>>
>>>> @@ -8169,3 +8179,17 @@ int mlx5_alloc_tunnel_hub(struct
>>>> mlx5_dev_ctx_shared *sh)
>>>>               mlx5_free(thub);
>>>>       return err;
>>>>    }
>>>> +
>>>> +int rte_pmd_mlx5_sync_flow(uint16_t port_id, uint32_t domains) {
>>>> +    struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>>> +    const struct mlx5_flow_driver_ops *fops;
>>>> +    int ret;
>>>> +    struct rte_flow_attr attr = { .transfer = 0 };
>>>> +
>>>> +    fops = flow_get_drv_ops(flow_get_drv_type(dev, &attr));
>>>> +    ret = fops->sync_domain(dev, domains,
>>>> MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW);
>>>> +    if (ret > 0)
>>>> +            ret = -ret;
>>>> +    return ret;
>>>> +}
>>
>> This is causing build error in the travis [1], I guess this is
>> related to the rdma-core version, is the
>> 'MLX5DV_DR_DOMAIN_SYNC_FLAGS_HW' check required in the header like
>> other usages?
>>
>> Also 'MLX5DV_' macros seems used in 'mlx5_flow_dv.c', is it expected
>> to use it in this file? (just high-level observation, no idea on
>> details.)
> 
> I send a fix for this already yesterday, and the issue should be solved.
> That fix could be squashed.
> http://patches.dpdk.org/patch/82652/
> 

Got it, let me squash it in the next-net, and I will test again.

>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftr
>> avis-
>> ci.org%2Fgithub%2Fferruhy%2Fdpdk%2Fjobs%2F740008969&amp;data=04%7C01
>> %7Cbingz%40nvidia.com%7C59346fa41fce41e08cce08d87c5c1667%7C43083d157
>> 27340c1b7db39efd9ccc17a%7C0%7C0%7C637396082238282132%7CUnknown%7CTWF
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>> 6Mn0%3D%7C1000&amp;sdata=HGY7vbWWR5ZdIikv39IzZAYcdsJq1FvGjuonClJo%2B
>> Pc%3D&amp;reserved=0
>>
>>
>>
>> btw, I just recognized that the patch acked with exception, is the
>> documentation requested above (with ack) provided?
> 
> This is a quite simple internal API. The usage and the information are listed in the API doxygen comments.
> Do I need to list it in the doc?
> 

That is the request from @Slava above.