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 A5D8DA0C47; Thu, 7 Oct 2021 18:06:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F41740042; Thu, 7 Oct 2021 18:06:34 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id ABA3040040 for ; Thu, 7 Oct 2021 18:06:32 +0200 (CEST) Received: from [192.168.1.192] (unknown [188.242.181.57]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 2A15D7F53A; Thu, 7 Oct 2021 19:06:32 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2A15D7F53A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633622792; bh=zav91N4pOfj/2Ju1c1h0UCTCXr70cq6sZweOjJ7XxlM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gO7quQ2Y8cB1EwXrijRvL2+iVn7L5DEmp/zRSN+EMv1NYWUHcFjkhO/Rry+2eZqM9 e0uCdQd5/O3EexM1dtR53SEiEsed6j9SgB31HqBD1wnZdVZMzzkMc+WsB6gStL0Ah1 9aLa5GGGVi7NURXoq3iiG1kQ+8fg1Wmg8KZ3KYMI= To: Ivan Malov , Ori Kam , "dev@dpdk.org" Cc: NBU-Contact-Thomas Monjalon References: <7773f5df-9deb-dcda-4724-657daf2da2d0@oktetlabs.ru> <31947510-92f7-2870-62f6-d160d2160ef3@oktetlabs.ru> <34ebf43b-92a8-8728-49f4-eb801166cd34@oktetlabs.ru> <76c32bc6-2695-62fb-c88c-38046244e2b8@oktetlabs.ru> From: Andrew Rybchenko Message-ID: Date: Thu, 7 Oct 2021 19:06:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <76c32bc6-2695-62fb-c88c-38046244e2b8@oktetlabs.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v1 02/12] ethdev: add eswitch port item to flow API 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 Sender: "dev" Hi Ori, Ivan, On 10/7/21 5:35 PM, Ivan Malov wrote: > Hi Ori, > > On 07/10/2021 16:00, Ori Kam wrote: >> Hi Ivan, >> >>> -----Original Message----- >>> From: Ivan Malov >>> Subject: Re: [PATCH v1 02/12] ethdev: add eswitch port item to flow API >>> >>> Hi all, >>> >>> I apologise for sending more mail. In fact, yet another option comes >>> to mind. In >>> order to move away from confusion with "port mirroring" but preserve the >>> "symmetry" flavour in the new name, we can go for "SHADOW_PORT". >>> >>> So, to sum up, I propose the new diagram (see the previous letter) >>> and the new >>> naming scheme: items / actions ETHDEV_PORT and SHADOW_PORT. >>> >> >> I'm O.K with the suggested names Andrew what do you think? Acceptable. I think I like REMOTE_PORT more. But have no strong opinion. >> >>> I hope this will get us on the same page. >>> >>> On 06/10/2021 21:00, Ivan Malov wrote: >>>> BTW, one more alternative to "MIRROR_PORT" is "REMOTE_PORT". >>>> >>>> On 06/10/2021 18:30, Ivan Malov wrote: >>>>> Hi Ori, >>>>> >>>>> By the looks of it, we are starting to run into slight >>>>> misunderstanding. >> >> 😊 This I a confusing subject. > > Yes. Offloads tend to get more complex over time. So do network > adapters. But I hope that this work on PORT_ID replacement is leading us > toward the least confusing concept, little by little. > >> >>>>> >>>>> As I see it, the main consequence of our Sep 14 gathering in Jitsi >>>>> was understanding of the fact that the concept of item / action >>>>> PORT_ID is vague and needs a replacement. As a bare minimum, separate >>>>> items should be used: one for an ethdev port and another one for the >>>>> "represented entity". >>>>> >>>>> This "represented entity" can be network (via network port), or a >>>>> guest machine (via a PF / VF plugged to it), or another ethdev (in >>>>> the case when the ethdev we are looking at is a PF/VF representor and >>>>> this PF/VF is also plugged to the DPDK application). >>>>> >>>>> So, if I get this right, you don't object this summary. Very well. >> >> Good summery and I agree to it. > > Thank you. > >> Just one question, what happens if there is no represented entity? >> This will mean that there will be not use of the shadow_port item/action? >> Doesn't it break your diagram? > > In this case, item SHADOW_PORT is valid, for sure, but there's simply no > traffic to match. No packets enter the embedded switch FROM the entity. > > Action SHADOW_PORT pointing at non-existent entity should probably > drop the packets. Well, at least, this sounds logical to me. Even > if this is not the case for some vendors, such action can simply > be turned down by the PMD during parsing ("invalid destination"). IMHO it would be more logical to return an error on request. > By the way, we currently have action VF. What if this VF is not plugged > anywhere? What is supposed to happen to traffic sent to that VF? Yes, it is delivered to VF and since nobody is listening, traffic is dropped. > And action PHY_PORT? If the port in question is down (no cable > attached), are the packets going to be just dropped? Yes, of course. However, it is a big difference with non-existing SHADOW. >> >>>>> >>>>> But, in the current approach, we stick with term "ESWITCH_PORT" for >>>>> that "represented entity", and, as I see it, this term is not quite >>>>> descriptive when someone tries to understand which exact port of the >>>>> embedded switch is implied. Attempts to clarify it by virtue of terms >>>>> "external" or "the most remote" are not-so-successful. >>>>> >>>>> I fully understand that. >>>>> >>>>> But the good news is that the original diagram of the new concept can >>>>> be improved in a way that can allow to dispose of misleading words. >>>>> >>>>> >>>>>        [ A ]       <-- ethdev >>>>>          | >>>>>        [ B ]       <-- embedded switch (logical) port >>>>>          | >>>>>          | >>>>>          | >>>>> ===============  <-- plane of symmetry >>>>>          | >>>>>          | >>>>>          | >>>>>        [ C ]       <-- embedded switch (logical) port >>>>>          | >>>>>        [ D ]       <-- represented entity >>>>> >>>>> >>>>> 1. The application sees the ethdev (A) and can assume that this >>>>>      ethdev is served by some logical port (B) in the embedded >>>>>      switch. Precise nature of this port is vendor-specific. >>>>> >>>>>      For example, for a regular (non-representor) ethdev, >>>>>      this port can be a PF, or a VF. This is obvious to >>>>>      DPDK developers, but the application doesn't need >>>>>      to have this knowledge. It only sees the ethdev. >>>>> >>>>>      If this ethdev is a representor, port (B) can be a truly >>>>>      separate logical port or, alternatively, some vendors >>>>>      may use "PF + metadata" approach. This port (B) is >>>>>      just assumed to exist. The rest is vendor-specific. >>>>> >>>>> 2. The application fully understands that the "wire" plugged to >>>>>      the ethdev it sees has an opposite end. Over there, there's >>>>>      some "represented entity" (D). Once again, the application >>>>>      does not know the nature of that "represented entity". >>>>>      To it, this entity is just some traffic endpoint. >>>>> >>>>>      And the application understands that this "represented entity" >>>>>      is connected to the NIC by means of another logical port (C). >>>>>      The nature of this port is unknown. The application does not >>>>>      need to have this knowledge. To it, this port just exists. >>>>> >> >> My question from above what happens if there is no represented port? >> The concept of representors is relatively new. So some HW may not >> support representors. >> or you are assuming that if we have E-Switch by definition we have >> representors? > > The new items / actions ETHDEV_PORT + SHADOW_PORT are going to be > documented to say clearly that they can only be used in "transfer" > flows. And if the PMD can accept "transfer" flows, this means that we > indeed have the embedded switch. And these items / actions are OK. Ack