From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 0B35E590B for ; Tue, 13 Sep 2016 11:24:31 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id c131so101462432wmh.0 for ; Tue, 13 Sep 2016 02:24:31 -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=eATNKP0p4j0dlndfEGycgelq19akMzygI1KE5IUvj/0=; b=pi2ELC2AeXCC2VWWu+eMIfoovkzonYfGCDfL6O/Arxdi/YpJqWyV5UIOQHEQmytQr8 kh9q8Nehc2WhhtHwD0cDthVy6fd9/SY0O1rincuUD19NskYvXLhS672Ws2S/2lxYRPJz Oh2IXACHeS4iB+G4hmNYrzrjGe/0QyNitdhx552phqN7UTis/q+u9wodiwtkfTN2It/N dI3KKXqd3WXxtZm9rnLSGyXzMSQ1oBtpgAHpcWtAQ+HLaLvxzyvXzJTXXwYThaQbS9qd RasR8p0W+qtX702xLId7JyYE/lW8SnniVgi4Yg76CncuW1uN5aIfFWccnLd1HQef7WtO JT6Q== 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=eATNKP0p4j0dlndfEGycgelq19akMzygI1KE5IUvj/0=; b=frNT7AFdxJyW91cMbXvB8Ce4LQuOJaxWLB9TA5javtlOPU2etDxwOtZRLY9kNY7r10 6OHnj9Lv/udf+TmweIlTYkPu+K4s28Pkdcju2jkjom4DoCFwF4cg6/NkGewXU346jQ2R tM7PkNUrhPR+zec5Pdhg+CTDEHmiwVY0XA/TqTjC1QgXPbGEtZQGFkk2rAFrrfdTirKZ CY49hC8D1nOPs4ogUrS6R8u1LgI7NUsDVeNM8LkbiQUEgdCgifF/bo/RiHU42YXMmkOK 24QtwcU7wkMwphilhf1n37GdLEoUuMZohimIkUkYQ0SjjlNf6MNf2SoLTvjLTZS73e5t X12g== X-Gm-Message-State: AE9vXwM3TYZH9I0ez4ame1YMOPklaMS5sGi8SdMQkDjNcTDRRRw6+pajyU+on8jEnRzP4mfJ X-Received: by 10.194.2.51 with SMTP id 19mr14889578wjr.37.1473758670574; Tue, 13 Sep 2016 02:24:30 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id w129sm21931939wmd.9.2016.09.13.02.24.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Sep 2016 02:24:29 -0700 (PDT) From: Thomas Monjalon To: "Iremonger, Bernard" Cc: dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Date: Tue, 13 Sep 2016 11:24:28 +0200 Message-ID: <1616711.yO3pyfy9gD@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A0761A7@IRSMSX108.ger.corp.intel.com> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <20160909142251.GB4100@localhost.localdomain> <8CEF83825BEC744B83065625E567D7C21A0761A7@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's 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: Tue, 13 Sep 2016 09:24:31 -0000 2016-09-12 16:28, Iremonger, Bernard: > > On Fri, Aug 26, 2016 at 10:10:18AM +0100, Bernard Iremonger wrote: > > > Add new API functions to configure and manage VF's on a NIC. > > > > > > add rte_eth_dev_vf_ping function. > > > add rte_eth_dev_set_vf_vlan_anti_spoof function. > > > add rte_eth_dev_set_vf_mac_anti_spoof function. > > > > > > Signed-off-by: azelezniak > > > > > > add rte_eth_dev_set_vf_vlan_strip function. > > > add rte_eth_dev_set_vf_vlan_insert function. > > > add rte_eth_dev_set_loopback function. > > > add rte_eth_dev_set_all_queues_drop function. > > > add rte_eth_dev_set_vf_split_drop_en function add > > > rte_eth_dev_set_vf_mac_addr function. > > > > Do we really need to expose VF specific functions here? > > It can be generic(PF/VF) function indexed only through port_id. > > (example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, uint8_t on)) > > For instance, In Thunderx PMD, We are not exposing a separate port_id for > > PF. We only enumerate 0..N VFs as 0..N ethdev port_id > > Our intention with this patch is to control the VF from the PF. > > The following librte_ether functions already work in a similar way: > > rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf, uint16_t rx_mode, uint8_t on) > > rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on) > > rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on) > > int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t tx_rate, uint64_t q_msk) I have a bad feeling with these functions dedicated to VF from PF. Are we sure there is no other way? I mean we just need to know the VF with a port ID.