DPDK patches and discussions
 help / color / mirror / Atom feed
From: Renata Saiakhova <renata.saiakhova@ekinops.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] librte_ethdev: Introduce a function to release HW rings
Date: Tue, 5 May 2020 17:25:55 +0000	[thread overview]
Message-ID: <PR0P264MB03324FA393DB6AE0CC6242B692A70@PR0P264MB0332.FRAP264.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <a6fb8233-3710-4e1a-3e88-42631a487b4f@partner.samsung.com>

Hi Lukasz,

thanks for your comments! I understand Anatoly is going to to make a fix rather in memzone API level, to introduce atomic "find and allocate" and "find and free" operations, so this patch code won't stay long and in this case maybe better not to disturb the original code of rte_eth_dma_zone_reserve() ? Just a question.

Kind regards,
Renata
________________________________
From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Sent: Tuesday, May 5, 2020 5:47 PM
To: Renata Saiakhova <renata.saiakhova@ekinops.com>; dev@dpdk.org <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] librte_ethdev: Introduce a function to release HW rings

Hi Renata,

few minor hints inline

W dniu 03.05.2020 o 18:26, Renata Saiakhova pisze:
> Free previously allocated memzone for HW rings
>
> Signed-off-by: Renata Saiakhova <Renata.Saiakhova@ekinops.com>
> ---
>   lib/librte_ethdev/rte_ethdev.c           | 23 +++++++++++++++++++++++
>   lib/librte_ethdev/rte_ethdev_driver.h    | 14 ++++++++++++++
>   lib/librte_ethdev/rte_ethdev_version.map |  1 +
>   3 files changed, 38 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 72aed59a5..c6d27e1aa 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -4206,6 +4206,29 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name,
>                        RTE_MEMZONE_IOVA_CONTIG, align);
>   }
>
> +int
> +rte_eth_dma_zone_free(const struct rte_eth_dev *dev, const char *ring_name,
> +             uint16_t queue_id)
> +{
> +     char z_name[RTE_MEMZONE_NAMESIZE];
> +     const struct rte_memzone *mz;
> +     int rc = 0;
> +
> +     snprintf(z_name, sizeof(z_name), "eth_p%d_q%d_%s",
> +                     dev->data->port_id, queue_id, ring_name);

probably rc=snprintf(...)

but maybe create a macro for that fancy memzone name as the same code
appears already in rte_eth_dma_zone_reserve and keeping it in one place
seems to be better idea to me.

> +     if (rc >= RTE_MEMZONE_NAMESIZE) {
> +             RTE_ETHDEV_LOG(ERR, "ring name too long\n");
> +             rte_errno = ENAMETOOLONG;
> +             return NULL;
It's an int returning function so instead of setting rte_errno, just:
     return -ENAMETOOLONG;
> +     }
> +
> +     mz = rte_memzone_lookup(z_name);
> +     if (mz)
> +             rc = rte_memzone_free(mz);
> +
> +     return rc;
> +}
> +
>   int
>   rte_eth_dev_create(struct rte_device *device, const char *name,
>        size_t priv_data_size,
> diff --git a/lib/librte_ethdev/rte_ethdev_driver.h b/lib/librte_ethdev/rte_ethdev_driver.h
> index 99d4cd6cd..2769a185b 100644
> --- a/lib/librte_ethdev/rte_ethdev_driver.h
> +++ b/lib/librte_ethdev/rte_ethdev_driver.h
> @@ -180,6 +180,20 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *eth_dev, const char *name,
>                         uint16_t queue_id, size_t size,
>                         unsigned align, int socket_id);
>
> +/**
> + * Free previously allocated memzone for HW rings.
> + *
> + * @param eth_dev
> + *   The *eth_dev* pointer is the address of the *rte_eth_dev* structure
param name is dev
> + * @param name
> + *   The name of the memory zone
param name is ring_name
> + * @param queue_id
> + *   The index of the queue to add to name
> + * @param size
There is no size param, but some info about return would be probably nice:
  * @return
*   Negative errno value on error, 0 on success.


And as it's a new API function maybe it should be experimental. Should it?

> + */
> +int rte_eth_dma_zone_free(const struct rte_eth_dev *dev, const char *ring_name,
> +              uint16_t queue_id);
> +
>   /**
>    * @internal
>    * Atomically set the link status for the specific device.
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index 715505604..5d3c209bc 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -82,6 +82,7 @@ DPDK_20.0 {
>        rte_eth_dev_vlan_filter;
>        rte_eth_devices;
>        rte_eth_dma_zone_reserve;
> +     rte_eth_dma_zone_free;
>        rte_eth_find_next;
>        rte_eth_find_next_owned_by;
>        rte_eth_iterator_cleanup;

Best regards

Lukasz

--

Lukasz Wojciechowski
Principal Software Engineer

Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciechow@partner.samsung.com


  reply	other threads:[~2020-05-06 10:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-03 16:26 [dpdk-dev] [PATCH 0/2] Memory corruption due to HW rings allocation Renata Saiakhova
2020-05-03 16:26 ` [dpdk-dev] [PATCH 1/2] librte_ethdev: Introduce a function to release HW rings Renata Saiakhova
2020-05-05 10:25   ` Burakov, Anatoly
2020-05-05 10:45     ` Burakov, Anatoly
2020-05-05 12:49       ` Renata Saiakhova
2020-05-05 13:36         ` Burakov, Anatoly
2020-05-05 15:47   ` Lukasz Wojciechowski
2020-05-05 17:25     ` Renata Saiakhova [this message]
2020-05-05 17:31       ` Lukasz Wojciechowski
2020-05-06 10:14       ` Burakov, Anatoly
2020-05-03 16:26 ` [dpdk-dev] [PATCH 2/2] drivers/net: Fix in e1000 and ixgbe HW rings memory overlap Renata Saiakhova
2020-05-05 10:28   ` Burakov, Anatoly
2020-05-05 10:59     ` Thomas Monjalon
2020-05-05 11:36       ` Burakov, Anatoly
2020-05-05 11:01 ` [dpdk-dev] [PATCH 0/2] Memory corruption due to HW rings allocation Thomas Monjalon
2020-05-05 11:19   ` Renata Saiakhova
2020-05-05 12:35     ` Thomas Monjalon

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=PR0P264MB03324FA393DB6AE0CC6242B692A70@PR0P264MB0332.FRAP264.PROD.OUTLOOK.COM \
    --to=renata.saiakhova@ekinops.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=l.wojciechow@partner.samsung.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).