Hi Eli,
On 01/06/2021 16:24, Eli Britstein wrote:
On 6/1/2021 3:10 PM, Ilya Maximets wrote:
External email: Use caution opening links or attachments
On 6/1/21 1:14 PM, Ivan Malov wrote:
By its very name, action PORT_ID means that packets hit an ethdev
with the
given DPDK port ID. At least the current comments don't state the
opposite.
That said, since port representors had been adopted, applications
like OvS
have been misusing the action. They misread its purpose as sending
packets
to the opposite end of the "wire" plugged to the given ethdev, for
example,
redirecting packets to the VF itself rather than to its representor
ethdev.
Another example: OvS relies on this action with the admin PF's ethdev
port
ID specified in it in order to send offloaded packets to the physical
port.
Since there might be applications which use this action in its valid
sense,
one can't just change the documentation to greenlight the opposite
meaning.
This patch adds an explicit bit to the action configuration which
will let
applications, depending on their needs, leverage the two meanings
properly.
Applications like OvS, as well as PMDs, will have to be corrected
when the
patch has been applied. But the improved clarity of the action is
worth it.
The proposed change is not the only option. One could avoid changes
in OvS
and PMDs if the new configuration field had the opposite meaning,
with the
action itself meaning delivery to the represented port and not to
DPDK one.
Alternatively, one could define a brand new action with the said
behaviour.
It doesn't make any sense to attach the VF itself to OVS, but only its
representor.
Sure. But that doesn't invalidate the idea of the patch.
For the PF, when in switchdev mode, it is the "uplink representor", so
it is also a representor.
No. According to the existing "port representors" documentation, the
admin PF port "represents itself", that is the PF, and by no means it
represents the underlying upstream port. And this makes really big
difference. One can indeed state that plugging VFs and not their
reprsentors to DPDK/OvS is useless, but the same statement is not
applicable to the admin's PF.
That said, OVS does not care of the type of the port. It doesn't matter
if it's an "upstream" or not, or if it's a representor or not.
From the high-level standpoint, indeed, the port type is a don't care
to OvS, but the truth is that DPDK offload path in OvS, being a
lower-level component, must respect all underlying DPDK primitives'
original meaning. Agreeing the top-level expectations (OvS) with the
lower-level means (DPDK flow library) *is* effectively the proper job of
app integration. And if for some reason the existing DPDK component
misreads the lower-level action real semantics, it cannot be justified
by high-level principles of OvS.
We had already very similar discussions regarding the understanding of
what
the representor really is from the DPDK API's point of view, and the last
time, IIUC, it was concluded by a tech. board that representor should be
a "ghost of a VF", i.e. DPDK APIs should apply configuration by
default to
VF and not to the representor device:
https://patches.dpdk.org/project/dpdk/cover/20191029185051.32203-1-tho...@monjalon.net/#104376
This wasn't enforced though, IIUC, for existing code and semantics is
still mixed.
I am not sure how this is related.
I still think that configuration should be applied to VF, and the same
applies
to rte_flow API. IMHO, average application should not care if device is
a VF itself or its representor. Everything should work exactly the same.
I think this matches with the original idea/design of the switchdev
functionality
in the linux kernel and also matches with how the average user thinks
about
representor devices.
Right. This is the way representors work. It is fully aligned with
configuration of OVS-kernel.
If some specific use-case requires to distinguish VF from the
representor,
there should probably be a separate special API/flag for that.
Best regards, Ilya Maximets.
--
Ivan M
