[dpdk-dev] [PATCH v1 02/12] ethdev: add eswitch port item to flow API
Andrew Rybchenko
andrew.rybchenko at oktetlabs.ru
Thu Oct 7 18:06:31 CEST 2021
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 at 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
More information about the dev
mailing list