From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 3E69C58D4 for ; Thu, 22 Sep 2016 19:04:39 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id b130so159511436wmc.0 for ; Thu, 22 Sep 2016 10:04:39 -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=2930GCjj9wrq/taxeKcbxtuQV+apwMmktMd0cg3aFX4=; b=u2iR6pBm68+7/nvlAnjF6tXTczPxPY1mOY1ewEVhAIyh+QwQO/g9IKMQGkeaq25T8h 00CcXqKHyYYQrOeUfqb2uPMgyMjAER9uzBtE92HZX++aoRo6a4HJ+/THJvQETntSRNCu qzXurXz1KrBUixFghSQO8DfqZYrTh42iQJzqiJMC5ZyFmRlxuoArt5u5EODBKzjpB8uV 2eM5rcvv+Zkr0LSnrWAgjKlj5XL6PQskICc2jh0oF6zaLqS+sknywaq/13DxLfmr2/mH khe2so854R9rUwk9z7zYaTbAR8GVy3eGGnE7uzAlOko+CN5AUzNLRPrAKbhX3C/bQ8M0 e+Bw== 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=2930GCjj9wrq/taxeKcbxtuQV+apwMmktMd0cg3aFX4=; b=f062Y/HhUKa9rmpV9f4HGzvYpPAN54UmRiJVLId6EHoGyziWLgPftXpYlAitsYm9as 9Da8c61BjgWsn05PrkJj531jC0HgOnQJ/d7TqHx4nznUA0OpeuRuk6D1W/bWh6sUBtyA DJrPvhqP2cp8+x+aegGf2ZASIRFmbkfcTHdQ7jFZeY6YNQgKDiEbwSzUpmpMURpl9Eoy NMCVMsNaGngkh7Z5X53txSpM3tL1yPzuf5EsDQW8K6a1/msZViZ0xWPVCY29JoCcV8BC 1AzqcmBqpnkoyph198QRgsXLqMvt5CHD28edATMl+TUcRRGQGOUe/ah0vu4bVD9l83lj MuhQ== X-Gm-Message-State: AE9vXwOhlQADAR2r2EJNF9XBR9JofXaGwl67P+rk+3uIjptjTZ0lTMGwa68cFvrXFnyIaYvB X-Received: by 10.194.23.39 with SMTP id j7mr3428089wjf.4.1474563878878; Thu, 22 Sep 2016 10:04:38 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id s6sm2993463wjm.25.2016.09.22.10.04.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 10:04:38 -0700 (PDT) From: Thomas Monjalon To: "Iremonger, Bernard" Cc: dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Date: Thu, 22 Sep 2016 19:04:37 +0200 Message-ID: <3664576.rt1sgYQyhm@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A08123A@IRSMSX108.ger.corp.intel.com> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1616711.yO3pyfy9gD@xps13> <8CEF83825BEC744B83065625E567D7C21A08123A@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: Thu, 22 Sep 2016 17:04:39 -0000 2016-09-15 16:46, Iremonger, Bernard: > > > > 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. > > When the VF is used in a VM the port ID of the VF is not visible to the PF. > I don't think there is another way to do this. I don't understand why we could not assign a port id to the VF from the host instead of having the couple PF port id / VF id. Can we enumerate all the VFs associated to a PF? Then can we allocate them a port id in the array rte_eth_devices?