From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 77E36C300 for ; Fri, 5 Feb 2016 16:06:57 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id g62so51925495wme.0 for ; Fri, 05 Feb 2016 07:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=88trEuFAkcDJ7t7b1lZ/+q0zver4DozBZujumdgZ/7M=; b=PO253ZN1Xa4W/wC18vpHw5X3gMhpCXu/+G2IhULWxdgT1Emw+9dQSjoxdQiCwRO4As 0VfbcfC9DULocqVSwGFmPnQuKqocEc0Xxpisfj7+8gZBrM4pBbH+pMu9YEfOoN5+5UXB aA1GEozke7OmXUNK/whVmeiT248/hqfPcZfX7vGqC1wYUgoqdCknGB5oPPNX/TjUaJCX RTI5O7yZk5r0BsH2/t1C/1y/XQo6XFI0b/g2ILFsD5+gw01k2dd1nD6bf+sb8NQnSsZG Bpdn/SVrUaDKc3WEq5Nbm6I8MqS1rhhYeYIu4QbLEu5W6rhDHYM32ygE+n5AKuMDCSqc arjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=88trEuFAkcDJ7t7b1lZ/+q0zver4DozBZujumdgZ/7M=; b=AqIffO1vBy/9webV5KgSckSbS0EwdvLPKJYCiLlXGkGYEIT/lcSMPhp+w0TpgKrIHw 9qBot/RM35Mm46u79uiM8P70b4BFUyDch53AdW6s83JgsgL7nKTJ16Cn5VfrXvd6r7fW TQQWSZzH/Dl/7YWYAiQZNUsI+6YamjHoumoynj31ifWWUGiD2YSyUKl8vaMz41iorTI1 NxYbLLwscR4ckU7D/EZro3KfF0fci8zl63/botuyAteRr0lcVYWEPmdIo8xa49RjrqIx j6w26bBYevcZ93sLhuzcjMHT5umzJdeH6JrWkHdPvWFJEGws9JpyaFFJpNN2a0Yew4DN mQDA== X-Gm-Message-State: AG10YOTgD2a2QqBafwNJkgkdU1j0qBixjxlCSLQjJMzDSyx6yvkLmEQ+T57HxBQZQxxRlzl7 X-Received: by 10.194.21.163 with SMTP id w3mr14458276wje.58.1454684817287; Fri, 05 Feb 2016 07:06:57 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id cb2sm16318615wjc.16.2016.02.05.07.06.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 07:06:56 -0800 (PST) From: Thomas Monjalon To: "Pattan, Reshma" Date: Fri, 05 Feb 2016 16:05:40 +0100 Message-ID: <2250582.9NrEEBnPD3@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3AEA2BF9852C6F48A459DA490692831FFBEB1B@IRSMSX109.ger.corp.intel.com> References: <1450873172-21932-1-git-send-email-reshma.pattan@intel.com> <8174506.yrx6lfkTWS@xps13> <3AEA2BF9852C6F48A459DA490692831FFBEB1B@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 0/3] fix RTE_PROC_PRIMARY_OR_ERR_RET RTE_PROC_PRIMARY_OR_RET X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:06:57 -0000 2016-02-05 14:58, Pattan, Reshma: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-01-05 16:34, Reshma Pattan: > > > From: reshmapa > > > > > > Patches 1 and 2 removes RTE_PROC_PRIMARY_OR_ERR_RET and > > > RTE_PROC_PRIMARY_OR_RET macro usage from rte_ether and rte_cryptodev > > > libraries to allow API access to secondary process. > > > > I don't understand the use case. > > These changes were added for the use case where vdev has to be configured from secondary process. > As of now, secondary process is allowed to create vdev but not allowed to configure it. > Ex1: tcpdump feature needs these changes. As we create & configure vdev from secondary process. > Ex2: Sean Harte, initially reported this as limitation as part of his development related to containers proof-of concept. > > > What is the role of the primary process if queues are configured by the > > secondary process? > > There can be use cases where primary and secondary processes needs to configure different queues of same port or needs to configure different PCI ports. > I assume, users will be aware of PCI port & queue combinations used in primary and will not try to reconfigure them in secondary. > > > You have not answered to Michael: > > http://dpdk.org/ml/archives/dev/2015-December/030811.html > > > > Other question first asked by Michael > > http://dpdk.org/ml/archives/dev/2015-December/030777.html > > There are some comments asserting that it is not safe for secondary. > > And your answer was it is safe for vdev? And what about PCI devices? > > I assume, users will be aware of PCI port & queue combinations used in primary and will not try to reconfigure them in secondary. OK, thanks, good answer. Anyone against this idea?