From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by dpdk.org (Postfix) with ESMTP id 877D41B3AE for ; Wed, 26 Sep 2018 17:20:10 +0200 (CEST) Received: by mail-ed1-f66.google.com with SMTP id e15-v6so2244812edr.4 for ; Wed, 26 Sep 2018 08:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vc+86QQAN4q5jziIk8MPZMH2CkY9OpwgC7RhQwlwV2Y=; b=dhsV/yLf9ViCihuwPo+gosuaUVAXPcH72V0fc6WMiJKw+6My8PM1gzfX4TFc779q/P y1Mif0pIKJ3lXXnA46VMYRI1f2K807EfWjKaYTUnCDt0O+PYgylX1udQccBzqMcDORla dbtvgbDmjwIVQADSRjbGVKVRAJxFKGDTXIjzU1McelpC9c/bSoNx2MkeAQ+q0z92W7RG ecnK5b+87aUUsBZtmd4yGJrzCxj0t0umc0jKRvz7V/ZnrWiQzPQSVleArbacDgVs1zCx hKnK+oU1c3Lm/A9FJv+Pq+3mfeKSk9Ykp+ZnPD1p+Ev7eVuOWiVAWQG9JedSmUNi8SP7 rZ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vc+86QQAN4q5jziIk8MPZMH2CkY9OpwgC7RhQwlwV2Y=; b=l+WSSnvDnLJ62/LY8L0uolyIA+Y6YPKV1SMLaPgN81tulm23Y8uOLyZlyygkgtAJrU Q+Uu4hsMu1El2qQRnbO4xHLOT2kAlUx07z/kEG9vyGRJBYIKfrlA+wVWCdtr3+CqqajV TdAImloYRGq1VofoqVwHEOEtkWFOLiu+o/HFO9rWkxjD+HtPyJXQmcfH8hZuufAO0u+c w+e9wLDoAyRX7EHlX02k+lf1ortaOWJK42BBGKMrsQ9/N6YOR/DUS+431PJXn0ZAxBdE o+Hqsb2ADLyOJSB98YNM4O2mgATnaQVRVC61lZLqxdPZmuN2sgkxfGc8y1vzWzS3ttt7 g77g== X-Gm-Message-State: ABuFfoi85SjA5APtetg7uGY3xFYXZ42vuMFfJMok6zzLAVLtgxQiO3zS 04rx0rA+Y9seYpRggK2f/zm8aswJHO7752Dfcl+BFw== X-Google-Smtp-Source: ACcGV63IFDuGpyIJc2OQb8ZdOulhjK+Drz7+XdjsVWWQaahZ5blGuyW4IWQCYLvo3P05Nc7tHkhsGbYQCwGuYq3XeWY= X-Received: by 2002:a50:f05e:: with SMTP id u30-v6mr10142189edl.91.1537975210204; Wed, 26 Sep 2018 08:20:10 -0700 (PDT) MIME-Version: 1.0 References: <2325089.6vXeJmFoYy@xps> <20180926153340.3a672360@shemminger-XPS-13-9360> In-Reply-To: <20180926153340.3a672360@shemminger-XPS-13-9360> From: Alejandro Lucero Date: Wed, 26 Sep 2018 16:19:59 +0100 Message-ID: To: Stephen Hemminger Cc: Thomas Monjalon , dev , Ferruh Yigit , Andrew Rybchenko , "Burakov, Anatoly" , rasland@mellanox.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 15:20:10 -0000 On Wed, Sep 26, 2018 at 3:33 PM Stephen Hemminger < stephen@networkplumber.org> wrote: > 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. > > AFAIK the per-device data is not used by apps but only PMDs, and the new field should be the same.