[ovs-dev] [v1] dpif-netdev: Add ovs-appctl dpif-netdev/subtable-show.

Stokes, Ian ian.stokes at intel.com
Tue Jan 7 10:51:57 UTC 2020

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 <emma.finn at intel.com>
>> ---
> 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

More information about the dev mailing list