From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B3D6CA04FD; Mon, 23 May 2022 11:51:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B45340141; Mon, 23 May 2022 11:51:46 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id C1C3140041 for ; Mon, 23 May 2022 11:51:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653299504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5teD0BUmwWddKSrDS36TwzunO5pCjJaYvGVXNqkny+E=; b=R2wk3MZouv93AVVqKMdtZr4bxmYKiF0/uwPEiIUIa5Ny3nRbnELGEpm6w/5e3oq6sE3S6S CaFX5VFBiWB7bsP2Wq+kCC9pVEcQyWY9N/rJq2KxQm0tq9i3U+ThGV+qvQZSXWlGu0XEap 7iEJ/STDaTZQpoeEztf/E4JfgFH2Gio= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-443-YQsk_CbZNViAzZqrn_bhWQ-1; Mon, 23 May 2022 05:51:43 -0400 X-MC-Unique: YQsk_CbZNViAzZqrn_bhWQ-1 Received: by mail-lf1-f71.google.com with SMTP id g11-20020a05651222cb00b0047872568226so1100625lfu.3 for ; Mon, 23 May 2022 02:51:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5teD0BUmwWddKSrDS36TwzunO5pCjJaYvGVXNqkny+E=; b=LiYVvV0QPvZ2A5FOEjOtbQ8fXSc0drPvplV9zWcsCwgYMxN8yW39RWUNwtVK2AC7Hn tCV/mfb+1oMx7vc6KAJb1JunFJArhyVrsjdcTy5V6O1znI0dwqieu73eSU8nIfRvzmuE 08s9vYIZlAnUSM/nU8g1Jl0OK0wak2v220f8EaGkyWCoJU+suge/yr2FLwphCpj6eYl/ UF5S5CmfmvvYB5wfvCC7p5js1lePrnkdZ9lfpi64eMbXlQ6RMGVgu08iffvhYEnacebj z0B258WtcVzgg+U+VViFRlLz9PXe74knXy3Iia4NJ3IzTnKhojWlzAEK/jRZFrVHPrKw 5iSA== X-Gm-Message-State: AOAM5304KTsJFIuAWDS402CCkYwCv6rrpsPZXF9P6Fm5fF5UeK2sJPo+ vgj2meeuCwklbqCnsXbfrWLfEviSAD/xz3yQ1ldkM0N5LZ9V41jOAxQufZggm4QlnQ+x0hDWFOZ oGrpt60UBXYs99PDQAqg= X-Received: by 2002:a05:6512:3183:b0:473:dffc:18ac with SMTP id i3-20020a056512318300b00473dffc18acmr15289740lfe.217.1653299501454; Mon, 23 May 2022 02:51:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJpuylPU2uPxvta2joCiKiAT7k+UbiWtX3pk9l7pOrqCzJ3ElzaPFjKgDRbs/Czbh+HO+E+8SBOBjgU5ngwEI= X-Received: by 2002:a05:6512:3183:b0:473:dffc:18ac with SMTP id i3-20020a056512318300b00473dffc18acmr15289723lfe.217.1653299501196; Mon, 23 May 2022 02:51:41 -0700 (PDT) MIME-Version: 1.0 References: <20220521065549.33451-1-humin29@huawei.com> In-Reply-To: <20220521065549.33451-1-humin29@huawei.com> From: David Marchand Date: Mon, 23 May 2022 11:51:30 +0200 Message-ID: Subject: Re: [PATCH] ethdev: fix push new event To: "Min Hu (Connor)" , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Cc: dev , Huisong Li , dpdk stable , Bruce Richardson Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Sat, May 21, 2022 at 8:57 AM Min Hu (Connor) wrote: > > From: Huisong Li > > 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