From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F0DBEA0583; Thu, 19 Mar 2020 10:26:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 223992B9E; Thu, 19 Mar 2020 10:26:30 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id DC61F29D6 for <dev@dpdk.org>; Thu, 19 Mar 2020 10:26:28 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 782A85C013F; Thu, 19 Mar 2020 05:26:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 19 Mar 2020 05:26:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=S4/SeAoh25HDPSMzghddS+2sQYdzzcp+Jc14TmknVuI=; b=Y9aHf9j/6tS2 JP4yVP3NwMQp1ERs3oaNE/KocrSoVu0yWCaa7c5vYjYJbmAGEQWm7ItmOWnnhD/l ijwZ9dfTwRy46teS/xYeX9hV/FdJVJvdZgfg78sVrIpSUr7sGgjFXxtgkYWv5vyJ X7oNMI+0yocjGroiBT+Ubwhjtt5P3CE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=S4/SeAoh25HDPSMzghddS+2sQYdzzcp+Jc14TmknV uI=; b=UGPihvx/6Iv9SgiGmciWzT0ywV5cAZeMeS4MTowUwtg4eFAporMK6A643 8GLlGZ0/Ule1K+rFQ243p2h5/ndeaSOg9+/DjiR+bjJLFHMgGVT+8xeZP1NMTtf4 CHFrbsklaUJDzV3dqMjct9WlORXld4lI66KgZbB4PE2RUxPJm5/7StmeJXWAZ2q1 qw2/3IHQRf9r4xkeohYjNGBIME/jkhMFgFosRXsrjAj449b5YIb0j80STCg5/pnd ZRCoicmdlapvL+NoUFTeFzsiC7VpLZHigbK/Q/9Ja/35ztUVyV3nPbjmyg0gdQok wVY5ttjkmHo/WXUieGGr7uwd+5X1A== X-ME-Sender: <xms:wzpzXrQIIeH0NiNeu_OMxtShy5DU6qzoSK_Ld0T_RrwoQ1594nIF8w> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefledgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:xDpzXsOQOcKTyAtZPdge_5SsoSitrWEf4Nd0p9kxKkgRr4ZqkaGWfw> <xmx:xDpzXh7agIxHrNUDbwpgDJUah9gF9K9VE1bHaREx7vagpKgf6kSq4g> <xmx:xDpzXvVFJuJ-8RoNLiHMrw7um3eNdth-cuPGFHivyZ0UcBwijot8EA> <xmx:xDpzXnjyJ3qgZwPButw5s26c7rud72PMf9WiRC6IwiPtQ1-FbHBsnQ> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D26443061CB6; Thu, 19 Mar 2020 05:26:26 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Kiran Kumar Kokkilagadda <kirankumark@marvell.com> Cc: Ori Kam <orika@mellanox.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>, Jingjing Wu <jingjing.wu@intel.com>, Bernard Iremonger <bernard.iremonger@intel.com>, John McNamara <john.mcnamara@intel.com>, Marko Kovacevic <marko.kovacevic@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, dev@dpdk.org Date: Thu, 19 Mar 2020 10:26:25 +0100 Message-ID: <16170589.5WZRyvrzyv@xps> In-Reply-To: <CH2PR18MB3272EA2A7835B0A9FEFBF038ACF40@CH2PR18MB3272.namprd18.prod.outlook.com> References: <20200310160609.7434-1-kirankumark@marvell.com> <AM6PR05MB5176B86CC535C818A13AC19ADBF60@AM6PR05MB5176.eurprd05.prod.outlook.com> <CH2PR18MB3272EA2A7835B0A9FEFBF038ACF40@CH2PR18MB3272.namprd18.prod.outlook.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: add DBDF action to RTE Flow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 19/03/2020 10:17, Kiran Kumar Kokkilagadda: > From: Ori Kam > > From: Kiran Kumar Kokkilagadda <kirankumark@marvell.com> > > > From: Ori Kam <orika@mellanox.com> > > > > From: kirankumark@marvell.com <kirankumark@marvell.com> > > > > > From: Kiran Kumar K <kirankumark@marvell.com> > > > > > > > > > > Adding suuport to DBDF action in the RTE Flow. > > > > > Application can specify the dbdf value using rte_flow_action_dbdf. > > > > > Matched traffic will be sent to specified PCI DBDF device. > > > > > > > > > I would like to see more detail use case, for example to which > > > > device / device type will the traffic be routed to? > > > > > > > > > > We have the following use case. > > > We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And > > > we have > > > 3 applications running. > > > 1st application on pf0 and pf1 > > > 2nd application on pf0_vf0 > > > 3rd application on pf1_vf0. > > > We want to direct the traffic matching condition1 from application 1 > > > (traffic from both pf0 & pf1) needs to send to application 2 > > > (pf0_vf0) And matching condition2 from application 1 (traffic from > > > both pf0 & pf1) needs to send to application 3 (pf1_vf0). > > > To summarize, we need to send traffic from pf0 to pf1_vf0 and traffic > > > from pf1 to pf0_vf0. In this case This DBDF action will be useful. > > > > > > > It seems that what you are describing it the port action with representors, or any > > other way you wish to implement it. > > Let's say we have a VF with kernel and we want to send the traffic to that VF, then we can't > Use port action. This will be useful in those scenarios. Sorry I don't understand. You mean the VF is managed by a kernel driver while the PF is managed by DPDK? So what prevents having a VF representor?