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.ma...@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
