patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Harman Kalra <hkalra@marvell.com>
Cc: Pavan Nikhilesh <pbhagavatula@marvell.com>,
	Jerin Jacob <jerinj@marvell.com>,  dpdk-dev <dev@dpdk.org>,
	dpdk stable <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] event/octeontx2: fix device reconfigure for single slot
Date: Mon, 12 Apr 2021 11:31:29 +0530	[thread overview]
Message-ID: <CALBAE1MjA3VHfHvDrazs-w=9m6E+0TzUi57SZeXQcT9mxwpN7w@mail.gmail.com> (raw)
In-Reply-To: <20210405162415.13818-1-hkalra@marvell.com>

On Mon, Apr 5, 2021 at 9:54 PM Harman Kalra <hkalra@marvell.com> wrote:
>
> When device is re-configured, memory allocated for work slot is freed
> and new memory is allocated. Due to this we may loose some important
> configurations/mappings done with initial work slot memory.
>
> For example, whenever rte_event_eth_tx_adapter_queue_add is called
> some important meta i.e. txq handle is stored in work slot structure.
> If device gets reconfigured after this tx adaptor add, txq to work
> slot mapping will be lost resulting in seg fault during packet
> processing, as txq handle could not be retrieved from work slot.
>
> Fixes: 67b5f4686459 ("event/octeontx2: add port config functions")
> Cc: stable@dpdk.org
>
> Signed-off-by: Harman Kalra <hkalra@marvell.com>

Applied to dpdk-next-eventdev/for-main. Thanks.



> ---
>  drivers/event/octeontx2/otx2_evdev.c | 34 +++++++++++++---------------
>  1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/event/octeontx2/otx2_evdev.c b/drivers/event/octeontx2/otx2_evdev.c
> index 7e2343599..a6beed069 100644
> --- a/drivers/event/octeontx2/otx2_evdev.c
> +++ b/drivers/event/octeontx2/otx2_evdev.c
> @@ -885,29 +885,27 @@ sso_configure_ports(const struct rte_eventdev *event_dev)
>                 struct otx2_ssogws *ws;
>                 uintptr_t base;
>
> -               /* Free memory prior to re-allocation if needed */
>                 if (event_dev->data->ports[i] != NULL) {
>                         ws = event_dev->data->ports[i];
> -                       rte_free(ssogws_get_cookie(ws));
> -                       ws = NULL;
> -               }
> +               } else {
> +                       /* Allocate event port memory */
> +                       ws = rte_zmalloc_socket("otx2_sso_ws",
> +                                               sizeof(struct otx2_ssogws) +
> +                                               RTE_CACHE_LINE_SIZE,
> +                                               RTE_CACHE_LINE_SIZE,
> +                                               event_dev->data->socket_id);
> +                       if (ws == NULL) {
> +                               otx2_err("Failed to alloc memory for port=%d",
> +                                        i);
> +                               rc = -ENOMEM;
> +                               break;
> +                       }
>
> -               /* Allocate event port memory */
> -               ws = rte_zmalloc_socket("otx2_sso_ws",
> -                                       sizeof(struct otx2_ssogws) +
> -                                       RTE_CACHE_LINE_SIZE,
> -                                       RTE_CACHE_LINE_SIZE,
> -                                       event_dev->data->socket_id);
> -               if (ws == NULL) {
> -                       otx2_err("Failed to alloc memory for port=%d", i);
> -                       rc = -ENOMEM;
> -                       break;
> +                       /* First cache line is reserved for cookie */
> +                       ws = (struct otx2_ssogws *)
> +                               ((uint8_t *)ws + RTE_CACHE_LINE_SIZE);
>                 }
>
> -               /* First cache line is reserved for cookie */
> -               ws = (struct otx2_ssogws *)
> -                       ((uint8_t *)ws + RTE_CACHE_LINE_SIZE);
> -
>                 ws->port = i;
>                 base = dev->bar2 + (RVU_BLOCK_ADDR_SSOW << 20 | i << 12);
>                 sso_set_port_ops(ws, base);
> --
> 2.18.0
>

      reply	other threads:[~2021-04-12  6:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 16:24 [dpdk-stable] " Harman Kalra
2021-04-12  6:01 ` Jerin Jacob [this message]

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='CALBAE1MjA3VHfHvDrazs-w=9m6E+0TzUi57SZeXQcT9mxwpN7w@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=hkalra@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=pbhagavatula@marvell.com \
    --cc=stable@dpdk.org \
    /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).