From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7173543752; Thu, 21 Dec 2023 19:33:53 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FE03402BD; Thu, 21 Dec 2023 19:33:53 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 5DF204028B for ; Thu, 21 Dec 2023 19:33:52 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 6CDFC32002E2; Thu, 21 Dec 2023 13:33:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 21 Dec 2023 13:33:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1703183628; x=1703270028; bh=BUXQkJpFJ80Okwg69EJnrpdNvImhPyhw+/DrgqQT8Fk=; b= Gd6XwyaygwtxH5aRuvFauCa8KUXGqWFAYvnFaGJEA6pBFJZRKG5itSpp+mCdq5mP zgdig+BALH4kepX61KVH/LgF4SCFQuGphRYYhf5CsuKeUbWHofZQMDX9+aebNnqa NjuQpTM9poROwL9dXYC4ku1XZDh0tvqFv6WVzHEyRMnCEwPrEv4XYDjFTZTv9eNN fr9E1Oq33SVoddkaLIDA0vLc5udn6zse864bDYTxYkAy2mmYkUnzdFmjs7KC2Bee BL6fLkmxlpqCA/RwBpg6ulzTYRUH9dTbgBTxuY5n5Ts2VnAiQoo2A8M48uSnrBX6 mfqGtx913noBGPPinI6ZRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1703183628; x= 1703270028; bh=BUXQkJpFJ80Okwg69EJnrpdNvImhPyhw+/DrgqQT8Fk=; b=W zh78Spy8e682epFW38AXChy2MaKJcVI25/BDALShrqBBQ5ykfIeVJXL2J8tjvg0h 0sY93+qKkhiIcNG85tZwwT/gK+4VkBWJf0GlUEppTysb2gWfkUhnK/7r45KvdfKE zb6SnWQbFVssBeZ5ukwMBL67NcImpM3xOmETm9TdXolWNnVNM3p89yuZDJtBXUuy IPbHROyLCe2IIXiAS42/Qut3i3HrNryHTe83su47WvArUkO1VaZmAS/lxmlr8HOz 0p8yrP+LwQI8LEv72X+brrytzOSxpjxvGidbK/ip4DR9MEdwjFvlUty9pWNkfpQq dYLg83PaIO1xzlcBpkNUA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduhedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Dec 2023 13:33:47 -0500 (EST) From: Thomas Monjalon To: Harman Kalra Cc: Nithin Kumar Dabilpuram , Kiran Kumar Kokkilagadda , Sunil Kumar Kori , Satha Koteswara Rao Kottidi , "dev@dpdk.org" , Jerin Jacob Kollanukkaran Subject: Re: [EXT] Re: [PATCH v2 24/24] doc: port representors in cnxk Date: Thu, 21 Dec 2023 19:33:46 +0100 Message-ID: <3506212.yKrmzQ4Hd0@thomas> In-Reply-To: References: <20230811163419.165790-1-hkalra@marvell.com> <3113395.8hb0ThOEGa@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 21/12/2023 14:28, Harman Kalra: > From: Thomas Monjalon > > 19/12/2023 18:40, Harman Kalra: > > > + Representor ports to be created for respective representees should be > > > + defined via these representor devargs. > > > + Eg. To create a representor for representee PF1VF0, devargs to be > > passed > > > + is ``-a ,representor=pf0vf0`` > > > + > > > + For PF representor > > > + ``-a ,representor=pf2`` > > > + > > > + For defining range of vfs, say 5 representor ports under a PF > > > + ``-a ,representor=pf0vf[0-4]`` > > > + > > > + For representing different VFs under different PFs > > > + ``-a > > + BDF>,representor=pf0vf[1,2],representor=pf1vf[2-5]`` > > > > It looks like something we should describe globally for ethdev, instead of > > driver documentation. > > DPDK generic representor devarg parser (rte_eth_devargs_parse_representor_ports()) can parse first > 3 cases i.e. a ,representor=pf0vf0 .... ``-a ,representor=pf0vf[0-4]``, > while 4 case was a special case which our PMD needs. > > Representor devargs are processed as part of new device (eswitch) PMD only, normal CNXK > PMD won't accept representor as a devarg. Hence all devargs we define under eswitch PCI device > and all the required representors are created while probing eswitch device probing. > > In the following format we are defining representors for which PFs and VFs should be created: > Eg. > -a ,representor=pf0vf[1,2],representor=pf1vf[2-5] > Here > VF representor will be created only for PF0VF1, PF2VF2, PF1VF2.....PF1VF5 > Although there may be n no of PF VF combinations but user wants representors for this devices only. > > Please let us know your opinion if "-a ,representor=pf0vf[1,2],representor=pf1vf[2-5]" > format handling can also be handled in common code. We can push a separate patch for it. I think yes it could be moved to common code in ethdev. > > > +In case of exception path (i.e. until the flow definition is > > > +offloaded to the hardware), packets transmitted by the VFs shall be > > > +received by these representor port, while packets transmitted by > > > +representor ports shall be received by respective VFs. > > > > Not clear. How is it related to any offload? > > Point what I wanted to highlight here is, until the flow rule for a fastpath is identified > and installed (offloaded) to the HW, packet flow will take the slow path (exception path) > i.e. for every packet sent out via VF should be received by its representor port and > vice versa. That's the case for any flow rule, right? I don't think it is specific to VF and representors. > Once the application installs the rule packets can take fast path i.e. directly > from VF to destination (wire or other VF), representors will not come in the > datapath for fast processing. You probably need to rephrase to explain what happens in VF scenario without being something which looks like an exception.