From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A9452A09E0; Fri, 13 Nov 2020 15:02:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B05F14CA6; Fri, 13 Nov 2020 15:02:48 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 09AA74C96 for ; Fri, 13 Nov 2020 15:02:45 +0100 (CET) IronPort-SDR: 0CIk4m3eBi8LEZYEoMieqPczTV0JYPSq0ORJU+Svpj4FLQjyNN39zNulfRXnpMD3gkZ1hT3Fjf IMiRJnVUXLKQ== X-IronPort-AV: E=McAfee;i="6000,8403,9803"; a="157494460" X-IronPort-AV: E=Sophos;i="5.77,475,1596524400"; d="scan'208";a="157494460" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 06:02:43 -0800 IronPort-SDR: Mq+s1cIxoyTyZuquGNf1AsLWKFIgVUzqzfwp9gkf4w1kxd1t6DpkKm/g/kPHAmAntvayRw0TAF UXvAwFZlUflg== X-IronPort-AV: E=Sophos;i="5.77,475,1596524400"; d="scan'208";a="474670635" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.3.208]) ([10.252.3.208]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 06:02:42 -0800 To: Olivier Matz , dev@dpdk.org Cc: David Marchand , Thomas Monjalon References: <20201113103957.19068-1-olivier.matz@6wind.com> <20201113131319.GR1898@platinum> From: Ferruh Yigit Message-ID: Date: Fri, 13 Nov 2020 14:02:38 +0000 MIME-Version: 1.0 In-Reply-To: <20201113131319.GR1898@platinum> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 11/13/2020 1:13 PM, Olivier Matz wrote: > 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. >> probe() invoked first in the primary, later in the secondary, both process calls the driver probe(). But for this case probe(), and dynfield register, being called first in primary seems solving the problem. Would you be OK to change last sentences as: "Indeed, probe() is first invoked on the primary process when a device is created in a secondary, this enables registering dynfield from secondary process." >> Bugzilla ID: 571 >> Fixes: d23d73d088c1 ("net/pcap: switch Rx timestamp to dynamic mbuf field") >> >> Signed-off-by: Olivier Matz Reviewed-by: Ferruh Yigit >> --- > > 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. > I was checking this, it seems what prevents to register dnyfield from the secondary process is 'init_shared_mem()', so if primary process registers any dynfield first, secondary process can register dynfields too. Do you think should this limitation documented? > This is the exact same problem than for this issue: > http://inbox.dpdk.org/dev/20200504074227.GA6327@platinum/#t > <...>