From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 977C8A0471 for ; Thu, 15 Aug 2019 17:06:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C09241BEC1; Thu, 15 Aug 2019 17:06:13 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id A106F1BEB0 for ; Thu, 15 Aug 2019 17:06:12 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1A3332096B; Thu, 15 Aug 2019 11:06:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 15 Aug 2019 11:06:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:content-type; s=mesmtp; bh=4gfVHT9B+Y jAbF/nCV3+QrsG3V4CcdkdS5uVIGjsCMM=; b=TONNR0Ykl3OX0a1sYEZto0NvcU TEiMFbS1+610zGSF2LCOQ7hOQ0zpiIqW8Xq1+K1KK6EGg3m+HTFTJaomtYpkSnOa q9ZN5cc8gShdVTNd+vbxzU3p+Bc/iKUn52WoZ0Sm9HNq2Pbq1jAb7oT9Q1nLN46u PgjfCArelzMnsS4pU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=4gfVHT 9B+YjAbF/nCV3+QrsG3V4CcdkdS5uVIGjsCMM=; b=blgAIP61BKzHQIpgqVEn47 aO+bJPXwguyeGfE4khoFI5/9HiEVkBVM9z3lrKofdKGvz6b5bvfnt3I7zec1+RqI xn3ZgpCDatZ7lkyakSk3ek5k9jkZSqgLRE/DH7DMi0n9vdNiJS9Sa8wVTAQhY7BQ ii4dkI0P3r4v3kKmKxgBOuDnt6Txpzb7h/uoPsdrh18HITWNpEFUOxLR+qtq6UYa sZMgqm0DGxnNgQB51qCFMYf3znzhTNxwQlBt/NtkWjWe0BRRH/vg63lLgevqD/1J JvCqDKTCzhzUdoyGZxD8pFUrhdy0dGJz5F/EXS5W92GI4EV0byWmW2rotio5mzvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefuddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcu ofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppe ejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0659C380089; Thu, 15 Aug 2019 11:06:07 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Andrew Rybchenko Cc: dev@dpdk.org, Bernard Iremonger , Shahaf Shuler , "E. Scott Daniels" , Wenzhuo Lu , Alex Zelezniak , Ajit Khaparde , Declan Doherty Date: Thu, 15 Aug 2019 17:06:05 +0200 Message-ID: <4165509.5enYigmRGf@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-dev] [RFC] ethdev: configure SR-IOV VF from host 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" In a virtual environment, the network controller may have to configure some SR-IOV VF parameters for security reasons. When the PF (host port) is drived by DPDK (OVS-DPDK case), we face two different cases: - driver is bifurcated (Mellanox case), so the VF can be configured via the kernel. - driver is on top of UIO or VFIO, so DPDK API is required. This RFC proposes to use generic DPDK API for VF configuration. The impacted functions are (can be extended): - rte_eth_dev_is_valid_port - rte_eth_promiscuous_enable - rte_eth_promiscuous_disable - rte_eth_promiscuous_get - rte_eth_allmulticast_enable - rte_eth_allmulticast_disable - rte_eth_allmulticast_get - rte_eth_dev_set_mc_addr_list - rte_eth_dev_default_mac_addr_set - rte_eth_macaddr_get - rte_eth_dev_mac_addr_add - rte_eth_dev_mac_addr_remove - rte_eth_dev_vlan_filter - rte_eth_dev_get_mtu - rte_eth_dev_set_mtu In order to target these functions to a VF (which has no port id in the host), the higher bit of port id is reserved: #define RTE_ETH_VF_PORT_FLAG (1 << 15) This bit can be combined only with the port id of a representor. The meaning is to target the VF connected with the representor port, instead of the representor port itself. If a function is not expected to support VF configuration, it will return -EINVAL, i.e. there is no code change. If an API function (listed above) can support VF configuration, but the PMD does not support it, then -ENOTSUP must be returned. As an example, this is the change required in rte_eth_dev_is_valid_port: int rte_eth_dev_is_valid_port(uint16_t port_id) { + uint32_t dev_flags; + uint16_t vf_flag; + + vf_flag = port_id & RTE_ETH_VF_PORT_FLAG; + port_id &= RTE_ETH_VF_PORT_FLAG - 1; /* remove VF flag */ + if (port_id >= RTE_MAX_ETHPORTS || (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED)) return 0; - else - return 1; + + dev_flags = rte_eth_dev_shared_data->data[port_id].dev_flags; + if (vf_flag != 0 && (dev_flags & RTE_ETH_DEV_REPRESENTOR) == 0) + return 0; /* VF flag has no meaning if not a representor */ + + return 1; }