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 39F2868F2 for ; Fri, 23 Sep 2016 15:15:28 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id l132so31204920wmf.0 for ; Fri, 23 Sep 2016 06:15:28 -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=YibSOYVulP9xh9yAJG2sEXtXyu9uaFlnvtC99hLH7uM=; b=esz1tnOrTdLV5QszgR7dTsM9BOaTRny5QUYh7I3rJ4JX3xReqrXvm1oL80jPOGR1SP uibnNdZPzawTi4waCvjQEe38e9ROHYuVOVbs4Dq0ny+T5zfkTJrzID53PqvMp2nBVocB CTHsKHyd2QncERFjJ9XvVRSfnorzcXRV3/hJ5Vc6U7iM2CdzCOWUhja3JigtwXcUuqK0 UEClun5Dp9PF2jnfWwtQy/clBnO3VrpuGueHlrsOupLdpGbLYesBLUV3eHF0DkkvM398 SzFyRwDohKBfXokBbNpJTrclxp100/W36afh4rCvqYFOuN0VLEIq6gE1FicVwS+Z6Cnq ibyg== 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=YibSOYVulP9xh9yAJG2sEXtXyu9uaFlnvtC99hLH7uM=; b=Vydx956IB8q6/4sdOGTLbty9tN9QBCpxR8oeomrjkg9mCXrgrZMV3R8pLqZ71PGE4X HlXq8EieEsxxv3dV8iWI7fsRsZwBHUAAgg+3TKBTINdCmrpDQIOQdzlglmNyO9j4CLJd PkeAIQl0OW7k3gX9/HSuLo9Mbdw7/L2lqP2m5+JwhopN5RxKn+VPUjwqVTHYWNm74MOf 1ZcacMHpp9Ubf0GEvdHesRTGQhltZcQBj0Bp2UFvJ5P93/MGEkjUMV5t+mIfYWJUVgXi Kykn+WK0kwAmTlZdhz0wxk3mD0qkYhX+g5xe+W9ry8omz7lzC8R9+iJVvORj5xtkg1J+ sE5Q== X-Gm-Message-State: AA6/9Rkn2wGkn7CxbwRxunySv1b1AE2lBewJEZGOKgJ3tBPfYQMWEzlwC/MnJUEnJxEW4ldD X-Received: by 10.195.11.8 with SMTP id ee8mr7002941wjd.82.1474636527966; Fri, 23 Sep 2016 06:15:27 -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 n28sm3118363wmi.2.2016.09.23.06.15.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2016 06:15:27 -0700 (PDT) From: Thomas Monjalon To: "Richardson, Bruce" , "Iremonger, Bernard" Cc: dev@dpdk.org, Jerin Jacob , "Shah, Rahul R" , "Lu, Wenzhuo" , azelezniak Date: Fri, 23 Sep 2016 15:15:22 +0200 Message-ID: <1942295.3Ll4jqpiva@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <59AF69C657FD0841A61C55336867B5B035AFEF9E@IRSMSX103.ger.corp.intel.com> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <3936536.tPp6g5Daih@xps13> <59AF69C657FD0841A61C55336867B5B035AFEF9E@IRSMSX103.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: Fri, 23 Sep 2016 13:15:28 -0000 2016-09-23 09:53, Richardson, Bruce: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-09-23 10:20, Bruce Richardson: > > > On Thu, Sep 22, 2016 at 07:04:37PM +0200, Thomas Monjalon wrote: > > > > 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? > > > > > > Hi Thomas, > > > > > > The VF is not a port visible to DPDK, though, so it shouldn't have a > > > port id IMHO. DPDK can't actually do anything with it. > > > > You say the contrary below. > > Well, yes and no. The driver can manipulate things for the VF, but DPDK doesn't actually have a device that corresponds to the VF. There are no PCI bar mappings for it, DPDK can't do RX and TX with it etc.? Very good point. There are only few ethdev functions which are supported by every drivers, like Rx/Tx and would not be available for VF from PF interface. > > > The PCI device for the VF is likely passed through to a different VM > > > and being used there. Unfortunately, the VF still needs certain things > > > done for it by the PF, so if the PF is under DPDK control, it needs to > > > provide the functionality to assist the VF. > > > > Why not have a VF_from_PF driver which does the mailbox things? > > So you can manage the VF from the PF with a simple port id. > > It really seems to be the cleanest design to me. > > While I see your point, and it could work, I just want to be sure that we are ok with the results of that. Suppose we do create ethdevs for the VFs controlled by the PF. Does the new VF get counted in the rte_eth_dev_count() value (I assume yes)? How are apps meant to use the port? Do they have to put in a special case when iterating through all the port ids to check that it's not a pseudo port that can't do anything. None of the standard ethdev calls from an app will work on it, you can't configure nb rx/tx queues on it, you can't start or stop it, you can't do rx or tx on it, etc, etc. Yes these devices would be special because their supported API would be quite different. I was thinking that in the future you could add most of the configuration functions through the VF mailbox. But the Intel mailbox currently support only some special configurations which are not supported by other devices even its own VF device (except setting MAC address). And when I read "set drop enable bit in the VF split rx control register", it becomes clear it is really specific and has nothing to do in the generic ethdev API. That's why it is a NACK. When we want to use these very specific features we are aware of the underlying device and driver. So we can directly include a header from the driver. I suggest to retrieve a handler for the device which is not a port id and will allow to call ixgbe functions directly. It could be achieved by adding an ethdev function like discussed here: http://dpdk.org/ml/archives/dev/2016-September/047392.html