Re: [dpdk-dev] [PATCH v1 02/12] ethdev: add eswitch port item to flow API

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

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 <Ivan.Malov@oktetlabs.ru>
>>> 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