On 1/2/2020 12:27 PM, Ilya Maximets wrote:
On 20.12.2019 16:28, Emma Finn wrote:
Add an ovs-appctl command to iterate through the dpcls
and for each subtable output the miniflow bits for any
existing table.
$ ovs-appctl dpif-netdev/subtable-show
pmd thread numa_id 0
dpcls port 2:
subtable:
unit_0: 2 (0x5)
unit_1: 1 (0x1)
pmd thread numa_id 1
dpcls port 3:
subtable:
unit_0: 2 (0x5)
unit_1: 1 (0x1)
Signed-off-by: Emma Finn <[email protected]>
---
So, what about my suggestions and thoughts about alternative solutions
that I posted in reply to RFC? It's still unclear why we need to disturb
the running datapath to get this information, especially if we could get
it "offline" from the flow dump.
Hi Ilya,
apologies I've only spotted this post now.
I guess to my mind there are a few reasons why this is being added as a
new command and not a separate application to process/parse the flow
dumps of a datapath.
(i) Ease of implementation, it seems straight forward enough to follow
the existing commands structure such as dpif-netdev/pmd-rxq-show to
implement this command. It had the required elements (required data
structures etc.) so minimum plumbing was required to get access to that
info and it will be familiar to any other developers who have already
worked or will work in that area of the code in the future.
I agree this could be done offline without the need to lock the
datapath, but from my understanding I don't think the intention here is
to run this command at a frequent or high interval so I would think that
the lock should not be an issue unless the command is being executed
continually (again similar to pmd-rxq-show, it would be called when
needed only).
The concern of adding a new separate application for parsing the dump
flow as you suggested came down to it being another separate app within
OVS to maintain as well as the work required to plumb or parse all
required info.
After posting the RFC we had a number of users already applying the
patch and using it in their deployments, we spoke about it at the
conference and didn't hear any objections so I this is why the patch has
continued with this approach for the 2.13 release.
Best Regards
Ian
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
