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 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zlTAsYnjfWi/N51MTIXI8rTMtRQfg0CrbJygEJ5V0Dw=; b=UMwhEM1VGOWhP28AynQCoJ3kluBuZ2dxqm4jkK/pPr+m5z5t5xXvH0odjcBIXohZ0a VRxz0Wsb1+U6qDnlQSow2LQdTA0csXZIP4oUfJduS95vjqpd3GbAzNh/D0k6kzzCPxY/ hIPLrVql0Q8ZgKt3IVBqubtg5yVO2+vpXiVOBkyxMcNEWKytU2dLflk9oXlae+2Vp7ku gA5fTVpsEAFHO4aYS8RB9wDH30NNg35XsGXeeOEfMgRDrCIbK3gABQ8o4DbS40lq1ryy UU2ubzKri/u1asfXgv1uB48PZuUHC8c8eteYFByfEVql6NKo1A39HYycpztYS/UNypxE D87w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zlTAsYnjfWi/N51MTIXI8rTMtRQfg0CrbJygEJ5V0Dw=; b=TpLJZHzE2WUaHioGOBRDQnzYNnVYAWwyz39LBVqqKvQ6bn5zDOD0W5o70fqFdctXUf dXp3QtTEEdaDAkDSc7t/8sCDBcPFxto8ebOpAqPUwmLJ8TST4Hv2tlqdFeHOBZswCjys MLRGZTC/JlL7k/28GLiCHMo98lsqcOvZh9O9yJJbuTqK94eT6E2ps2GgAM1io1iZVxCp nn/gJVkJQEuTwjhJEWZZ91ibQN354jrDZfo7UlRe+mXWiO3MMqnH6bff3zLQYdX27nAP fhNlmGzpgltQ0jHrla+Up7C0N+MMCzVNR7cXWjvyQ++F6k/Obhlwhsp26Pub1JMKFZpS Ai/Q== X-Gm-Message-State: APzg51A7zC8E0F8yfhb0B07NoVKjv06cYTauNm0Qq3Kr4BP+pSDCTfWQ +EycndddQ0aab0HnApJ6G4iK2+R4mM+1uQ== X-Google-Smtp-Source: ANB0VdZ0PGszjtQUNg5avpp1zTTal2jgo34ZR6m7OU3189A3q9O2ebbPq/Tm7lZLmU2SG3KoZ1+syg== X-Received: by 2002:a1c:f611:: with SMTP id w17-v6mr5460442wmc.143.1535377566768; Mon, 27 Aug 2018 06:46:06 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id k34-v6sm27573158wre.18.2018.08.27.06.46.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 06:46:05 -0700 (PDT) Date: Mon, 27 Aug 2018 15:45:50 +0200 From: Adrien Mazarguil To: Vivek Sharma Cc: dev@dpdk.org Message-ID: <20180827134550.GD3695@6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] RTE-FLOW: PF vs PHY_PORT 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: , X-List-Received-Date: Mon, 27 Aug 2018 13:46:07 -0000 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