From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: RTE-FLOW: PF vs PHY_PORT Date: Mon, 27 Aug 2018 15:45:50 +0200 Message-ID: <20180827134550.GD3695@6wind.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org To: Vivek Sharma 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 1369D2C28 for ; Mon, 27 Aug 2018 15:46:07 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id o18-v6so8393093wmc.0 for ; Mon, 27 Aug 2018 06:46:07 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Vivek, On Wed, Aug 22, 2018 at 05:16:52PM +0530, Vivek Sharma wrote: > Hi Devs, > > I am trying to enable RTE-FLOW support on one of our platforms & having hard time in figuring out PF vs PHY_PORT differences and DPDK rationale for introducing these two distinct identities. > > Rte-Flow distinguishes between RTE_FLOW_ITEM_TYPE_PF & RTE_FLOW_ITEM_TYPE_PHY_PORT and > > RTE_FLOW_ACTION_TYPE_PF & RTE_FLOW_ACTION_TYPE_PHY_PORT. > > > I am finding it difficult to justify the presence of both these types, when functionality & implementation wise, these look quite similar. I would really appreciate if you could illustrate the differences between above item & action types by taking some hardware/platform as reference. Some devices, typically those with a single PCI bus address shared for all ports (e.g. Mellanox ConnectX-3) expose all their physical ports to each PF/VF instance [1], not the other way around. With these, PHY_PORT item and action give the ability to select a nondefault physical port in a flow rule. PHY_PORT cannot be specified on most devices with PF/VF dedicated to physical ports, although their drivers should at least recognize 0 as a supported index and ignore it. Since devices can expose any number of PF/VF instances and physical ports, this gives applications the ability to use both as matching criteria and/or action target. A higher level alternative to PHY_PORT and PF/VF items/actions is PORT_ID to match/target DPDK port IDs, which users may find more convenient. One drawback is that it only works with devices instantiated within DPDK. PF/VF and PHY_PORT should be reserved for corner cases where PORT_ID cannot be used. My advice is to implement PORT_ID and not bother with the others since port IDs are what applications are familiar with. [1] Although with CX3, individual ports can be disabled per VF, they remain "seen" by each instance. -- Adrien Mazarguil 6WIND