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 A9F07A09E0; Fri, 13 Nov 2020 21:35:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 084FBC87E; Fri, 13 Nov 2020 21:35:43 +0100 (CET) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id E656FC872 for ; Fri, 13 Nov 2020 21:35:41 +0100 (CET) Received: by mail-wr1-f66.google.com with SMTP id 33so11526333wrl.7 for ; Fri, 13 Nov 2020 12:35:41 -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=1cJMyb0t+iumxDzfCAWdLTnB9iiXo9b57m5MaYnfDaQ=; b=YQSJU2QwVqam0l3R69PXoW4VQ7AMB1jedfpgxLg0htQS2GGvc+cNPHa+Fwh38ekqoV ILhASrJGuo9SfdtwMjxvubdkOzCjMuqZ62Ogv/7qXUqgN6aVryuwCzhuL9Xw/NvigYly QSurJIhrIm7RIoFFdKlcJyzcPVR89NVVhbjRURIul/dfSE4YE+dxf4YZoYiGLSuepSAj iXlWns0G6b3pwlJPtCWIKgjLXaVj7DwFCZuzKR0ntseQOnWFfUkQpxYjd5mgoU/SFtUs zP7Qf9T7UdWTTHmwcprlgKqZWNzu3OWv43cXQAyK1EakjEedUrXMoOhLLPX9nwNV0auH AR6Q== 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=1cJMyb0t+iumxDzfCAWdLTnB9iiXo9b57m5MaYnfDaQ=; b=js5zyRolU0y0bkouKAy3fnhIaymhf1/fLCRa0QLoN5iUuHuc94kDITtShFfjqUw21O tICokbqIuoIi0bS0iiToejMVBCjI5KNYijDcCbbxd/dehdeyM6ZH/1NZswpT3iYG29Ru /oZr/LpaH39xHfkH/ryVySqk1bfv2ftixdH+8vULlworVk6KL6K68k8tcJF14toFyZWD jV8IxED4h5fahoXs8WxmNowrKmvFyV4Nhkc7w59ytG5wS9h6bXJsi45p1VspRpf5V6H8 7vPJ5nIs1k7UlrF9WbI6nxN2W5bmMcTTY3y2jyTwh7np5jKhfN/+nOEVtOdIMwp4ymEX AEDg== X-Gm-Message-State: AOAM530t9S8mDPxmuFMk+LAXDf3P7H1Vbj6fbq6AaS3JR0ZGKrhdrtEf vXXtZQA+tRYRYDcfe4coRI4oPw== X-Google-Smtp-Source: ABdhPJwdEh1rkD4OfwYfI5LIHk2jqVHMR5evvRDGN3IE2fu51qgPFETRoQi1lIbFyDADRJ/nUzCq1A== X-Received: by 2002:a5d:50d1:: with SMTP id f17mr5691030wrt.264.1605299740540; Fri, 13 Nov 2020 12:35:40 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a6000c321531fba1e24e.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:c32:1531:fba1:e24e]) by smtp.gmail.com with ESMTPSA id o14sm7697715wrw.4.2020.11.13.12.35.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Nov 2020 12:35:39 -0800 (PST) Date: Fri, 13 Nov 2020 21:35:34 +0100 From: Olivier Matz To: Ferruh Yigit Cc: dev@dpdk.org, David Marchand , Thomas Monjalon Message-ID: <20201113203534.GB6890@arsenic.home> References: <20201113103957.19068-1-olivier.matz@6wind.com> <20201113131319.GR1898@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Nov 13, 2020 at 02:02:38PM +0000, Ferruh Yigit wrote: > 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." Yes, it is more precise, thanks > > > 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? Currently, registration from secondary is explicitly denied, with a code like this: if (rte_eal_process_type() != RTE_PROC_PRIMARY) { rte_errno = EPERM; return -1; } > > This is the exact same problem than for this issue: > > http://inbox.dpdk.org/dev/20200504074227.GA6327@platinum/#t > > > > <...> >