From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by dpdk.org (Postfix) with ESMTP id 7FD621B14C for ; Wed, 26 Sep 2018 16:33:43 +0200 (CEST) Received: by mail-ed1-f45.google.com with SMTP id q19-v6so2116117edr.1 for ; Wed, 26 Sep 2018 07:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=IReIBEcZ0sd4NXwDqHug8af4e/9JxQOhqAApfk6z5+E=; b=ylII6FM449E+N5xWWxz0WcJDAXVH1e+AnMENDXqQkPzMboD6frpFzUxwuyCuBjmAk3 3LHs1H1aHGiEi5hF7KvGKYZ1KUeaXMfgeromiyHW7fpMvRAslHUtaAa4q7K7KLZ+iFr4 26VEsyMLDbhjFva2gSVnPi1cIuPkcidfCUWBbbVeBlBMrS4s/My/NIkABdRO2UgZA2dC WmrcH9leSLGoK7REOwdD3uWOPV6KhmvlgF/4q+HhI0wq8DzqvohR62PQewz+5UK0C8q7 UI1PFiu7V5/ZO1UkI7olTCJvLxhkwozC3dN39efPF84Cc5yhVpijHTxW1zqothad6n7v v2/w== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=IReIBEcZ0sd4NXwDqHug8af4e/9JxQOhqAApfk6z5+E=; b=Qt/T7KN22Q75lJ36Lt7nRCcAa91KpvylRGcDMgaHPDrMce7hhJr2RtxPACy51ttKMP xMV8c2cR+dibJZBb/rWjHFarDwZFNBT1S5ZT4cn1ep3Wt69x/tPVUDZ/xXcElVYx2Ed6 FM0xMYoxLt5tqCCnyIfizix+DcYXKTiOndev/Vmhv9WHGlW8jKOXWqdREetZ1XuZ002x InIa6cz9M5r5w6ufpgydyUD8mijKaaSJOEc5hYKAhiPDaJ2Iw1a7AZ5WoM+aArrno+bY Mf9RfaV6Lyt+Y8JWlQRmnNyhQBQD/r/DiD2GcWgQKXMAqCZ8S8G4PBhYizDJGp9S7shU 9w6A== X-Gm-Message-State: ABuFfojYbp17/Fd+jxBXno15XIi5/Nma5arY1TfzhAc8ez0wlZaFx4FN uh2svvsakvOGBz6JbP66z43nTg== X-Google-Smtp-Source: ACcGV60/tuPf2YbbgF6702DrfGg11TI763ReLGSJvh01XERHsP4oMrDqWR/vIQ3lJZVCVNZQ9zMFXA== X-Received: by 2002:a50:8bd5:: with SMTP id n21-v6mr10160463edn.41.1537972423031; Wed, 26 Sep 2018 07:33:43 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([213.244.170.154]) by smtp.gmail.com with ESMTPSA id y42-v6sm11113504edb.83.2018.09.26.07.33.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Sep 2018 07:33:42 -0700 (PDT) Date: Wed, 26 Sep 2018 15:33:40 +0100 From: Stephen Hemminger To: Thomas Monjalon Cc: Alejandro Lucero , dev@dpdk.org, Ferruh Yigit , Andrew Rybchenko , "Burakov, Anatoly" , rasland@mellanox.com Message-ID: <20180926153340.3a672360@shemminger-XPS-13-9360> In-Reply-To: <2325089.6vXeJmFoYy@xps> References: <2325089.6vXeJmFoYy@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] secondary processes and private data 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: Wed, 26 Sep 2018 14:33:43 -0000 On Wed, 26 Sep 2018 15:21:52 +0200 Thomas Monjalon wrote: > Hi Alejandro, > > 25/09/2018 16:10, Alejandro Lucero: > > I've a problem when part of device private data needs to be private per > > process. > > It appears we are facing the same issue to support multi-process in tap. > > > Current multiprocess support shares device private data between primary and > > secondaries but it is all dependent on a pointer initialized to the same > > memory address by the multiprocess support code. If there is a per-process > > data, If a secondary process changes it the primary gets affected, and the > > same for additional secondaries which will affect not just the primary but > > other previous secondaries. > > Yes, the field rte_eth_dev.data.dev_private is private to the device, > but shared between processes. > > > The solution is to add support for this inside struct rte_eth_dev, > > something like > > > > void *secondary_priv_data; > > > > so it is up to the secondaries to use this field if necessary. > > I would say it is not only for secondary process. > What about this name: > > rte_eth_dev.process_private > > > NFP PMD creates the required rte_eth_devs specifically, similar to what is > > done inside rte_ethdev.c but adding initialization for an interface needed > > when calling device ethdev_init function. There are other PMDs doing this > > but none has this requirement for per-process private data. > > Actually tap has a per-process requirement for its file descriptors. > > > Please, let me know what you think about this change to struct rte_ethdev > > or if you have a better idea for solving this problem. > > I support the idea, but we need to agree on name bikeshedding :-) Good idea, as long as it stays contained to DPDK. Don't want additional user API pointers buried in internal structures (like ethdev). If application needs device private data it should manage its own state.