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 7905EA00C5; Thu, 15 Sep 2022 13:16:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 53C5D4021D; Thu, 15 Sep 2022 13:16:29 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 6245F40156 for ; Thu, 15 Sep 2022 13:16:28 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1CD185C00FE; Thu, 15 Sep 2022 07:16:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 15 Sep 2022 07:16:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1663240588; x= 1663326988; bh=C/EETU9QdXA2VH5jhRHy2PingfQCOct0ABocOuDWoOk=; b=R gvKDPgIzLUccrq2t34bWh7b24vb75YMwU0iaX2UW+NaM+50DAlHhblwsGbAjNkle 6dnXjrLpJfzI6rfCZoiAkCMYbmRUZd2CZfsvlgJI5AKbeVWEHYbBpM/nVdZaRA0m 01El6hkuZy15wWCypUvMc8RbD2Op1IPKLsEsUe83wKX66ij8H0QNSbnxEfxx1P38 w5rQPkRvq2tw5rWPDxVL+JTlYhFJkczIVdGqjjvsP/py7KnIgwihfMgVt2VieTCt QzeAVuEOvN6c3W01swr5tEVPOF0glGQLaHSLBdQ3lx1Cx4TBnGNSG6ebnyB/onqs WCpzXfSmDkXCTBDS0C5SA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663240588; x= 1663326988; bh=C/EETU9QdXA2VH5jhRHy2PingfQCOct0ABocOuDWoOk=; b=d 9H3GYB8ciDLG7bekGBEa4RW41WShjQVoCgKns55q0eO+paZ2LDQWgYGglEnarsou NBtH0s3413SYtIU2YKSKQzSG9o572eZwtvTUNbMsVr3vjHtkd+22zdMvcTsw3qxQ DcZwvbnxI7rJAlICf/ow3I7fQWAWIPcOn/hx81I4wYQI0TdQo3Vg9TcxWfjGr8hD GpOb4NcY8gA21PANUu6G0u+2L3d9bF32LFIlLbc/0N1mx4RPzZ3B2SzHw7aN27tP abhpqbkHJzrgoGyrLkFcw0k9vgwvPX2kw95Rz9a+/n/iOGqXdezXYafGE3YQjXQM /jDlUja/GTFPeXOmOrk9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedukedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 15 Sep 2022 07:16:26 -0400 (EDT) From: Thomas Monjalon To: Rongwei Liu , Ivan Malov Cc: Matan Azrad , Slava Ovsiienko , Ori Kam , Aman Singh , Yuying Zhang , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: Re: [PATCH v1] ethdev: add direction info when creating the transfer table Date: Thu, 15 Sep 2022 13:16:25 +0200 Message-ID: <2834724.SvYEEZNnvj@thomas> In-Reply-To: <297a487e-b5d-4928-e96-c80b2603dd8@oktetlabs.ru> References: <20220907024020.2474860-1-rongweil@nvidia.com> <297a487e-b5d-4928-e96-c80b2603dd8@oktetlabs.ru> 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 15/09/2022 12:59, Ivan Malov: > Hi Rongwei, > > In this reply, I do not include the previous mail because the amount > of inline commentary has gone haywire over the past couple of days. > Let's re-iterate. > > But before I get to that, I'd like to offer a fresh perspective: > > Perhaps, if we all agree that term "vport" means an endpoint which > can stand for any "port" except for physical one, then it should > be possible to use term ANY_VPORTS rather than ANY_GUEST_PORTS. The opposite of "physical" is "virtual" indeed. > But that's tricky, of course. I don't have a way with naming, > so more opinions are welcome and very-very desirable here. > > So: > > 1) Do you agree that, in your proposal, the new "wire_orig" / "vf_orig" > primitives are in fact yet another match criteria? > > .. > > To me, it looks so. If they are match criteria, then they belong > in match pattern, that is, they should be expressed as new items. > > For "transfer" rules, the *existing* attributes are: "group" > and "priority". As you may note, these are clearly not match > criteria. They control the look-up order. So, to this day, > there're no match criteria in DPDK expressed as attributes. > > If these "wire_orig" / "vf_orig" are going to be introduced > as attributes, that should be backed with strong motivation. I prefer we keep matching in a single place, not in attributes. > 2) From your viewpoint, why items "ANY_PHYS_PORTS" and "ANY_VPORTS" > won't do? Or, which problems do you think they may inflict? > > .. > > Previously, you explained why REPRESENTED_PORT would not > fit your needs. And I understand your point: to async API, > two pattern templates which both have item REPRESENTED_PORT > in them cannot be clearly distinguished and are in fact the > same set of criteria (provided that all other items are also > the same and have the same masks). Templates are, well, > templates (or shapes) of the rules to come later and > do not include exact "spec" for the "ethdev_id". > Got it. > > But that's not going to be the case with items ANY_PHYS_PORTS and > ANY_VPORTS, is it? In one async table template, the user submits > item ANY_PHYS_PORTS (instead of table attribute "wire_orig"). > In another template, the user submits item ANY_VPORTS to > state that they want to match only traffic transmitted > software endpoints (DPDK ethdevs, guest VFs, etc.) > connected to the switch. > > In this example, the PMD will clearly see that the two templates > differ. So it will be able to allocate separate resources, each > one "cutting one half of traffic" (as per your concept). > > 3) In your most recent response, you suggested that one might have > had the attributes occupied for some other purposes. To me, > they're not. Neither me nor my closest colleagues have > any plans on them. When I advocate using item approach > over the attribute approach, I do this to ensure > a) clarity of the API contract and b) robustness. > > 4) Also, in your response, you suggested that I might have > confused item mask and spec. That is not the case. > If we agree, that switch domain ID is unneeded in > the new items, then these items will have no > fields in them (like item PF had not had any > before it was deprecated). > > No fields in new items => no field masks. > So what's the problem then? > > 5) With regard to our talk about identifying the relationship > between ethdevs and switch domains, you said that the user > could know the difference from the very beginning: > /sysfs/ .... /PF_BDF/sriov_num > > That is true for the user who starts the application, but > this knowledge is hard to obtain from the application > perspective = it's hard to automate. > > This is why ethdevs are able to advertise their domain IDs. > And, as I explained, looking at domain ID to understand namely rte_eth_dev_info.switch_info.domain_id > port relationship is valid, whilst looking at proxy IDs > to achieve the same goal is not. Proxy port IDs only > serve the purpose of finding an entry point for > managing flows. That has slightly different > meaning, but this subtle difference is important. There is also a concept of sibling ports to get all ports belonging to the same hardware. > 6) As for the confusion over the difference between fixing > bugs and making the code robust by extra checks: > > Yes, I agree that the programmer who writes the > application must be intelligent enough to use > flow primitives the proper way. Yes, the user > who starts the application also should thread > carefully. But that does not prevent some > mistakes in other parts of code from > corrupting various chunks of memory, > including, for example, flow attrs. > > You say that such mistakes have to be "just fixed" > as any other bugs. Right. But how much time will > the programmer spend to identify the bugs? > > If the PMDs do all the checks (as with attributes), > the hypothetical bug will manifest itself much > earlier. That will simplify debugging by a lot... > > So, my point is that it's still better to ensure > that new flow primitives have all necessary > checks in place. For attributes, it is > required to add them separately. If flow insertion is done in a fast path, such checks may be skipped. > For items, as I explained, it might not be necessary > in the majority of cases simply because of the > switch (item->type) { case } structure. > > So, these are some of my points to explain why the > attribute approach is untenable. To me, attributes > are something global, which demands checks in all > flow-capable PMDs. Items seem better because they > are don't cares to all PMDs which are unaware of > the async concept. So, even if someone does not > implement the async concept or does not like > the new item names, they can turn a blind > eye to this - with attributes, thay can't. > > Thank you.