From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 5A09FA09E0;
Fri, 13 Nov 2020 14:13:25 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 9D8D1C86A;
Fri, 13 Nov 2020 14:13:23 +0100 (CET)
Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com
[209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 35CA9C868
for <dev@dpdk.org>; Fri, 13 Nov 2020 14:13:21 +0100 (CET)
Received: by mail-wm1-f68.google.com with SMTP id c9so8109338wml.5
for <dev@dpdk.org>; Fri, 13 Nov 2020 05:13:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to:user-agent;
bh=pxDdcBoj3YC5fq2MY7rq97t69ZBoZf7sXfPejsHkYPs=;
b=QlEbvzm22aCVean96q0eyJDv5khx+CZJhvpHnpw7Smv0TfsZzTcdgHjmdKznoahFns
qcGCzFYcQrV6UBw6GwaNYnrfLxKrShxYur3fkSHvo0Qt5Dta6E++HIT+qAjcQVmjlX+b
FHMG0NW8ZYkw8ZA/j53PziVEv60lbKe5pHpvFihag7L9qjFYSm7D2s1kdvsfIabhB7wO
orhSy9T3c5JAz+2mYxFlryacn0zmERx8cRp65QeOAkD4NFUJA0bY1Jt75pBOo/MgjGJ1
CetNIwAj7eSoB4yJap46DgkRUTsHwtzBPutgT4xu7WvcU+c7A65qCSMaZ9TFctiCa8zf
LMTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to:user-agent;
bh=pxDdcBoj3YC5fq2MY7rq97t69ZBoZf7sXfPejsHkYPs=;
b=SktnR4Vigv6b0q/9ZVdNuI65ha7X+iJ6YmMAc4OGeoKFC0uaoR+sB8wnr20EmKq/OX
e1QF8vdximMQUm2c1e4E4eLSra73O4RR0rL/Ki+CNlQY8q9LA9U4Qby/WgOAbETdscD4
nJwTTwT+3tJ1RxuiCQzmpYDDwXrbcPffhHjJJaLiCejyuh5VRAHaRGseEtJbsh9TFgYl
bGNs377Sb0ubWDBO5vlvAeUuQgFilpXKiX/Lz3WQbRP9SrZL/wpFIwCcH4Rumy9lrPr+
3Z0YxlGxqB2sMCsR6jeO6+9kYD2yb0XKykPgccHbOwYUZdJJvs1g9Vepwz3H4wtXE2mq
mGQw==
X-Gm-Message-State: AOAM530nqHdFo0dzv5VWIAFDwty2m/Z3017fv6+ctZjlrBM7pAWS/pYj
lwQmBanPDIBCn6Qj2X0SbjwQXMNp82QXPg==
X-Google-Smtp-Source: ABdhPJyOT9WIzZzVd+ViCz0MbcZO+JmxWKtTjjM+C9xBUYBsNFvr7GPdjmX0adYJZ+Bxq3BGIMzRdg==
X-Received: by 2002:a1c:2583:: with SMTP id l125mr2506695wml.50.1605273200344;
Fri, 13 Nov 2020 05:13:20 -0800 (PST)
Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr.
[2a01:cb0c:5:a600:3456:36f7:e65e:d1a0])
by smtp.gmail.com with ESMTPSA id u16sm10844068wrn.55.2020.11.13.05.13.19
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 13 Nov 2020 05:13:19 -0800 (PST)
Date: Fri, 13 Nov 2020 14:13:19 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: dev@dpdk.org
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
David Marchand <david.marchand@redhat.com>,
Thomas Monjalon <thomas@monjalon.net>
Message-ID: <20201113131319.GR1898@platinum>
References: <20201113103957.19068-1-olivier.matz@6wind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201113103957.19068-1-olivier.matz@6wind.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [dpdk-dev] [PATCH] net/pcap: fix registration of timestamp
dynamic field
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Fri, Nov 13, 2020 at 11:39:57AM +0100, Olivier Matz wrote:
> In pcap pmd, the timestamp mbuf dynamic field is mandatory. When the
> pcap pmd is created in a secondary process (this is the case for pdump),
> it cannot be registered because this is not allowed from a secondary
> process.
>
> To ensure that the field is properly registered, do it from probe()
> instead of configure(). Indeed, probe() is invoked on the primary
> process when a device is created in a secondary.
>
> Bugzilla ID: 571
> Fixes: d23d73d088c1 ("net/pcap: switch Rx timestamp to dynamic mbuf field")
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
One additional comment about this patch.
While it solves the issue described in the bug report, there may still
be a gap when it is needed to register a dynamic field/flag from a
secondary process. This happens when registering and configuring devices
from a secondary process (is it supported?). It happens if the secondary
process initializes a library which is not initialized in primary, and
which requires a dynamic field.
>From afar, it does not look too difficult to implement dynamic field
registration from secondary processes. The only thing missing is a way
to allocate the shared memory in the primary process at initialization.
Currently, there is no init callback that is invoked when eal init is
done.
This is the exact same problem than for this issue:
http://inbox.dpdk.org/dev/20200504074227.GA6327@platinum/#t
> drivers/net/pcap/rte_eth_pcap.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index 4e6d49370e..4930d7d382 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -661,15 +661,6 @@ eth_dev_stop(struct rte_eth_dev *dev)
> static int
> eth_dev_configure(struct rte_eth_dev *dev __rte_unused)
> {
> - int ret;
> -
> - ret = rte_mbuf_dyn_rx_timestamp_register(×tamp_dynfield_offset,
> - ×tamp_rx_dynflag);
> - if (ret != 0) {
> - PMD_LOG(ERR, "Failed to register Rx timestamp field/flag");
> - return -rte_errno;
> - }
> -
> return 0;
> }
>
> @@ -1387,6 +1378,13 @@ pmd_pcap_probe(struct rte_vdev_device *dev)
> start_cycles = rte_get_timer_cycles();
> hz = rte_get_timer_hz();
>
> + ret = rte_mbuf_dyn_rx_timestamp_register(×tamp_dynfield_offset,
> + ×tamp_rx_dynflag);
> + if (ret != 0) {
> + PMD_LOG(ERR, "Failed to register Rx timestamp field/flag");
> + return -1;
> + }
> +
> if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> eth_dev = rte_eth_dev_attach_secondary(name);
> if (!eth_dev) {
> --
> 2.25.1
>