From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 82A054CE7 for ; Sat, 8 Oct 2016 00:52:51 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id k125so56570649wma.1 for ; Fri, 07 Oct 2016 15:52:51 -0700 (PDT) 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:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=uJzZpGIAtiwxLBg0S1ZnoxQqB7H5sfpgfNlVicgoLAY=; b=NbD+HWwbjlu9xhlAoyLdH/Rc75A/UtiacB/21e8NyiGzVfLUd1mSHrKuxXP4/c9Qme AyCXCp/RZASBdbkQobtOcRUQooDv6OPAZ0eqOlv9zRmMTMd1uqUjYzErCh0DLdqm9Zm7 y5J23+bjzS0Lsh/QGs3aqI9AM2PkP4tNHIhY8amPr7SZuF6wE6fnZzyFxB2mjX7NuSxJ VVK4AcioA8BdwkG1SevbFWh7FCITCx8mLkx8b0w5zP9dNxgMpqxPV7IOGkyaSkiwee/U g8hgyVuEorRIYgXsseixQH/xOXwpaP98o3X5m8JMXC0nbjMMGntXUtPCYDis3bo1YRXz uEpA== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=uJzZpGIAtiwxLBg0S1ZnoxQqB7H5sfpgfNlVicgoLAY=; b=EEI+BrITRQSbrW+jAw8vskwNMpeIXYxQ1UW3UpGoGbdRO4HaAK07AAhnJgcbKhzTlV zHCVH7fj3j/Y0HMb8vNxjNg6eCAP4hPtMBfzrwkuG4wOD6bAHxksjFrhGd0faf/0yT8N jnUOb9bMZvPvhtw/cEUU6HO6oxb/31HpRPuAcO3OPi675v9J16IWG2OyALvMSFffCvHY KA7hDqWf3w4PR3390aw5dVHqmvuZ+5orjDJebYnXhhJBypdSaSo7hqtlGQfhFmkzm7b3 7MbtXMniJBllRhv1P0NnlGKqY6/MhA8gklm+8OzqS7x8syNR6iiaBOAi79kJ+ZNt/Rwu N7sA== X-Gm-Message-State: AA6/9RlB+Czv6rCBwSpvpbFgu03ubYqGLCJI1FY1ZV8+swSlHEGm1SZuuFU7deHHlLVr3U0S X-Received: by 10.28.19.134 with SMTP id 128mr800943wmt.40.1475880771281; Fri, 07 Oct 2016 15:52:51 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id g9sm21847425wjk.25.2016.10.07.15.52.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 15:52:50 -0700 (PDT) From: Thomas Monjalon To: dev@dpdk.org Cc: Bernard Iremonger , rahul.r.shah@intel.com, wenzhuo.lu@intel.com, az5157@att.com Date: Sat, 08 Oct 2016 00:52:49 +0200 Message-ID: <1958473.G65NeSqF66@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1475858784-5303-1-git-send-email-bernard.iremonger@intel.com> References: <1475772490-10491-1-git-send-email-bernard.iremonger@intel.com> <1475858784-5303-1-git-send-email-bernard.iremonger@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 0/2] modify callback for VF management 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, 07 Oct 2016 22:52:51 -0000 2016-10-07 17:46, Bernard Iremonger: > This patchset modifies the callback function for VF management. > > A third parameter has been added to the _rte_eth_dev_callback_process > function. All references to this function have been updated. > Changes have been made to the ixgbe_rcv_msg_from_vf function to > use the new callback parameter. > > This patchset depends on the following patch. > http://dpdk.org/dev/patchwork/patch/16430/ > [dpdk-dev,v7,1/2] net/ixgbe: add API's for VF management OK, this is probably a temporary solution. I am OK to let it enter in DPDK 16.11 and starts some discussions. That's why I'll try to sum up the situation for this patchset and the other one (API for VF management). The VF features are not yet enough standardized. So the functions to manage them from the PF will be in some specific headers (drivers/net/ixgbe/rte_pmd_ixgbe.h in this case). They could be promoted in the generic ethdev API if it appears to be generic enough. There can be also some application callbacks called from the drivers with a specific signature: - a "generic" event type for VF - a specific parameter defined in the driver Obviously, we cannot have different meanings of this event depending on the driver in use. So we must have something more robust when implementing such feature in a second driver. As there is no obvious solution, the pragmatic approach is to accept this first specific implementation while waiting for a better idea.