From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 887FAA49A for ; Thu, 25 Jan 2018 12:33:53 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2041420D39; Thu, 25 Jan 2018 06:33:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 25 Jan 2018 06:33:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=bsrW6B2txMTuzLkxvc9rYMypcc 1rFgAMn0Q0Fs03CBc=; b=JkVfj8bNuFphcu3v7RmqUQpWkR80Q1nLjfh2r5EhMI MsH5VqAdkGxxMl9PPTwYBh5+4AJWUFW6fUKtsuVBSF7cL6p6NCeYRxm8muNAhM6C Q3aaLJfTtSFaWONyIALgZOLDyJ+j6YZRcfRxSJ+FZg33zu6rkf5pAiftToChNahn E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bsrW6B 2txMTuzLkxvc9rYMypcc1rFgAMn0Q0Fs03CBc=; b=n9RgLfXtpMX5KoMTo+KOsV scheAsNgPeyCOo8AXOm2tSTA203UanGrLY1sGOsBwZbKbfW/TKu1xARMquTwYloH 5FD82LtnEdLRix55TtiqweNJTLPJaTdGT1buBQVQqeYpRnXAz6gfU6ffleMjE70D 9bl4th1XkUiHA3K26fTBeYCLULywbxv5pL9ZcvmVRlZdf6YVVNAK5adj9Kv9dYKh rgAvtg5XmrJHO6YCOJsToGCM2GI/ainjVmRyfBaKVpztSNxrXY80rEgeQ3OAnce+ 5fXSSJUhiUGhfQvGeI3FyrZsS2yvCUc0k06q/5LVq2MH+uhVR5nPcWqcmKnjO0ow == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C18E57E4A8; Thu, 25 Jan 2018 06:33:52 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Matan Azrad , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org, Neil Horman , "Richardson, Bruce" Date: Thu, 25 Jan 2018 12:33:09 +0100 Message-ID: <6943290.WpmPGMvTZ0@xps> In-Reply-To: <2601191342CEEE43887BDE71AB97725886283602@irsmsx105.ger.corp.intel.com> References: <1516293317-30748-8-git-send-email-matan@mellanox.com> <8784959.KALqi1c4OM@xps> <2601191342CEEE43887BDE71AB97725886283602@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 7/7] app/testpmd: adjust ethdev port ownership 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: , X-List-Received-Date: Thu, 25 Jan 2018 11:33:53 -0000 25/01/2018 12:15, Ananyev, Konstantin: > Hi everyone, > > > > > 25/01/2018 10:36, Matan Azrad: > > > Gaetan, Konstantin, Thomas > > > > > > Any response to my suggestion below? > > > > > > From: Matan Azrad > > > > Suggestion: > > > > > > > > 2 system owners. > > > > APP_OWNER - 1. > > > > NO_OWNER - 0. > > > > > > > > And allowing for more owners as now. > > > > > > > > 1. Every port creation will set the owner for NO_OWNER (as now). > > > > 2. There is option for all dpdk entities to take owner of NO_OWNER ports all > > > > the time(as now). > > > > 3. In some point in the end of EAL init: set all the NO_OWNER to > > > > APP_OWNER(for V6). > > What will happen if we have 2 (or more process) sharing the same device? > How we will distinguish what APP_OWNER we are talking about? > Shouldn't default_owner be unique per process? Yes, good point! Each application process should be considered a different owner by default. > > > > 4. Change the old iterator to iterate over APP_OWNER ports(for V6). > > If I get it right it means no changes in tetpmd, correct? It is my understanding yes. > > > > What do you think? > > > > Reminder for everybody: there is no issue if no hotplug. > > There is a race condition with hotplug. > > Hotplug is not managed by EAL yet, but there is a temporary hotplug > > management in failsafe. > > So until now, the issue is seen only with hotplug in failsafe. > > > > Your suggestion makes no change for applications, > > and fix the ownership issue for failsafe. > > And later, if an application wants to support generic hotplug properly > > (when it will be generally available in DPDK), > > the application should use the ownership API. > > Right? > > > > I think it is a good compromise. > > I still think it would be good if future hotplug support will be transparent > to existing apps (no/minimal changes). > But I suppose we can discuss it later, when will have hotplug patches. It cannot be really transparent. If an application is based on port detection at init, it has to be changed to decide how to handle new ports. That's why I introduced the new events for ethdev notification callback.