patches for DPDK stable branches
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: "Min Hu (Connor)" <humin29@huawei.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	 Ferruh Yigit <ferruh.yigit@intel.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: dev <dev@dpdk.org>, Huisong Li <lihuisong@huawei.com>,
	dpdk stable <stable@dpdk.org>,
	 Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH] ethdev: fix push new event
Date: Mon, 23 May 2022 11:51:30 +0200	[thread overview]
Message-ID: <CAJFAV8z9NhyVt6=is6-huYUCDXQSgzRmXubuH-DuqX6CE+FGrw@mail.gmail.com> (raw)
In-Reply-To: <20220521065549.33451-1-humin29@huawei.com>

On Sat, May 21, 2022 at 8:57 AM Min Hu (Connor) <humin29@huawei.com> wrote:
>
> From: Huisong Li <lihuisong@huawei.com>
>
> The 'state' in struct rte_eth_dev may be used to update some information
> when app receive these events. For example, when app receives a new event,
> app may get the socket id of this port by calling rte_eth_dev_socket_id to
> setup the attached port. The 'state' is used in rte_eth_dev_socket_id.
>
> If the state isn't modified to RTE_ETH_DEV_ATTACHED before pushing the new
> event, app will get the socket id failed. So this patch moves pushing event
> operation after the state updated.
>
> Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")

A patch moving code is unlikely to be at fault.


Looking at the patch which moved those notifications in this point of
the code, the state update was pushed after the notification on
purpose.
See be8cd210379a ("ethdev: fix port probing notification")

    ethdev: fix port probing notification

    The new device was notified as soon as it was allocated.
    It leads to use a device which is not yet initialized.

    The notification must be published after the initialization is done
    by the PMD, but before the state is changed, in order to let
    notified entities taking ownership before general availability.


Do we need an intermediate state during probing?


-- 
David Marchand


  reply	other threads:[~2022-05-23  9:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-21  6:55 Min Hu (Connor)
2022-05-23  9:51 ` David Marchand [this message]
2022-05-23 12:33   ` Ferruh Yigit
2022-05-23 14:36   ` Thomas Monjalon
2022-05-28  8:53     ` lihuisong (C)
2022-05-30  8:28       ` Thomas Monjalon
2022-05-30 11:10         ` Ferruh Yigit
2022-06-02 11:24           ` lihuisong (C)
2022-06-03  7:42             ` Thomas Monjalon
2022-06-07  1:23               ` lihuisong (C)
2022-06-07  6:44                 ` Thomas Monjalon
2022-06-11  8:59                   ` lihuisong (C)
2022-09-27 10:29                     ` Thomas Monjalon
2022-10-08  4:06                       ` lihuisong (C)

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='CAJFAV8z9NhyVt6=is6-huYUCDXQSgzRmXubuH-DuqX6CE+FGrw@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=humin29@huawei.com \
    --cc=lihuisong@huawei.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /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).