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 dpdk.space (Postfix) with ESMTP id 7CE19A0096
for <public@inbox.dpdk.org>; Thu, 9 May 2019 22:08:52 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 74A9444C3;
Thu, 9 May 2019 22:08:51 +0200 (CEST)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by dpdk.org (Postfix) with ESMTP id 11E083977
for <dev@dpdk.org>; Thu, 9 May 2019 22:08:49 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
09 May 2019 13:08:48 -0700
X-ExtLoop1: 1
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
by fmsmga004.fm.intel.com with ESMTP; 09 May 2019 13:08:48 -0700
Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by
FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
id 14.3.408.0; Thu, 9 May 2019 13:08:48 -0700
Received: from fmsmsx115.amr.corp.intel.com ([169.254.4.68]) by
fmsmsx123.amr.corp.intel.com ([169.254.7.229]) with mapi id 14.03.0415.000;
Thu, 9 May 2019 13:08:48 -0700
From: "Carrillo, Erik G" <erik.g.carrillo@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
CC: "Burakov, Anatoly" <anatoly.burakov@intel.com>, "rsanford@akamai.com"
<rsanford@akamai.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH v2] timer: allow first subsystem init from secondary
Thread-Index: AQHVBqCfSlnHvdjvQES/JSTw6J1eL6ZjNvgA
Date: Thu, 9 May 2019 20:08:47 +0000
Message-ID: <BE54F058557D9A4FAC1D84E2FC6D875723407ADF@fmsmsx115.amr.corp.intel.com>
References: <1557353861-31997-1-git-send-email-erik.g.carrillo@intel.com>
<1557430776-16355-1-git-send-email-erik.g.carrillo@intel.com>
<7268235.EfLeTirqVG@xps>
In-Reply-To: <7268235.EfLeTirqVG@xps>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.600.7
dlp-reaction: no-action
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWJjYzA5YjktNWYyNy00ZDMzLTlmYmItNGUxNzdhYTJhMGZmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRlVsSzZEYVdTUkhSZFJMSlBBdWZLM3JNM0tGN1VOeEpWTWVnV250TTdkSmJYRDdsTjhhQWo5b3BvNHlzeTJmMCJ9
x-ctpclassification: CTP_NT
x-originating-ip: [10.1.200.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v2] timer: allow first subsystem init from
secondary
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>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, May 9, 2019 2:52 PM
> To: Carrillo, Erik G <erik.g.carrillo@intel.com>
> Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; rsanford@akamai.com;
> dev@dpdk.org
> Subject: Re: [PATCH v2] timer: allow first subsystem init from secondary
>=20
> 09/05/2019 21:39, Erik Gabriel Carrillo:
> > Since memzones can be reserved from secondary processes as well as
> > primary processes, if the first call to the timer subsystem init
> > function occurs in a secondary process, we should allow it to succeed.
> >
> > Fixes: c0749f7096c7 ("timer: allow management in shared memory")
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
>=20
> I think this patch is too big for -rc4.
> And it doesn't look so critical.
> Do you agree to wait 19.08?
>=20
The very last hunk of the patch should at least be applied, as it fixes an =
issue in the finalize() function. The rest of it is just to make sure the =
behavior is the same as the prior release with respect to the secondary.
I'd prefer if the whole patch was applied, but I can break out the last hun=
k for a very small patch if that's what you think we should do.
Regards,
Erik