From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 3B5B8558C for ; Tue, 17 Jan 2017 09:46:05 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP; 17 Jan 2017 00:46:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,243,1477983600"; d="scan'208";a="809801996" Received: from dpdk26.sh.intel.com ([10.239.128.228]) by FMSMGA003.fm.intel.com with ESMTP; 17 Jan 2017 00:46:03 -0800 From: Wenzhuo Lu To: dev@dpdk.org Cc: Wenzhuo Lu Date: Tue, 17 Jan 2017 16:45:28 +0800 Message-Id: <1484642728-73411-27-git-send-email-wenzhuo.lu@intel.com> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1484642728-73411-1-git-send-email-wenzhuo.lu@intel.com> References: <1480637533-37425-1-git-send-email-wenzhuo.lu@intel.com> <1484642728-73411-1-git-send-email-wenzhuo.lu@intel.com> Subject: [dpdk-dev] [PATCH v12 26/26] doc: update doc for VFD 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: Tue, 17 Jan 2017 08:46:06 -0000 Update the doc and release note. Signed-off-by: Wenzhuo Lu --- doc/guides/contributing/design.rst | 14 ++++++++++++++ doc/guides/nics/i40e.rst | 1 + doc/guides/rel_notes/release_17_02.rst | 29 +++++++++++++++++++++++++++++ 3 files changed, 44 insertions(+) diff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst index bac3d1b..88d3a43 100644 --- a/doc/guides/contributing/design.rst +++ b/doc/guides/contributing/design.rst @@ -158,3 +158,17 @@ cache bandwidth, memory bandwidth, etc) that depends on: branches are usually required. When processing a burst of packets that have been validated for header integrity, counting the number of bits set in a bitmask might be needed. + +PF and VF Considerations +------------------------ + +The primary goal of DPDK is to provide a userspace dataplane. Managing VFs from +a PF driver is a control plane feature and developers should generally rely on +the Linux Kernel for that. + +Developers should work with the Linux Kernel community to get the required +functionality upstream. PF functionality should only be added to DPDK for +testing and prototyping purposes while the kernel work is ongoing. It should +also be marked with an "EXPERIMENTAL" tag. If the functionality isn't +upstreamable then a case can be made to maintain the PF functionality in DPDK +without the EXPERIMENTAL tag. diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index 0cc9268..1245ecf 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -64,6 +64,7 @@ Features of the I40E PMD are: - SR-IOV VF - Hot plug - IEEE1588/802.1AS timestamping +- VF Daemon (VFD) - EXPERIMENTAL Prerequisites diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst index aa90e59..f7e9f86 100644 --- a/doc/guides/rel_notes/release_17_02.rst +++ b/doc/guides/rel_notes/release_17_02.rst @@ -71,6 +71,35 @@ New Features Support for Mellanox ConnectX-5 family of 10/25/40/50/100 Gbps adapters has been added to the existing mlx5 PMD. +* **Added VF Daemon (VFD) on i40e. - EXPERIMENTAL** + + This's an EXPERIMENTAL feature to enhance the capability of DPDK PF as many + VF management features are not supported by kernel PF driver. + Some new private APIs are implemented in PMD without abstrction layer. + They can be used directly by some users who have the need. + + The new APIs to control VFs directly from PF include, + 1) set VF MAC anti-spoofing + 2) set VF VLAN anti-spoofing + 3) set TX loopback + 4) set VF unicast promiscuous mode + 5) set VF multicast promiscuous mode + 6) set VF MTU + 7) get/reset VF stats + 8) set VF MAC address + 9) set VF VLAN stripping + 10) VF VLAN insertion + 12) set VF broadcast mode + 13) set VF VLAN tag + 14) set VF VLAN filter + VFD also includes VF to PF mailbox message management by APP. + When PF receives mailbox messages from VF, PF should call the callback + provided by APP to know if they're permitted to be processed. + + As an EXPERIMENTAL feature, please aware it can be changed or even + removed without prior notice. + + Resolved Issues --------------- -- 1.9.3