[ovs-dev] [PATCH v3 1/3] netdev: Dynamic per-port Flow API.

Roi Dayan roid at mellanox.com
Wed May 15 05:33:20 UTC 2019



On 14/05/2019 19:20, Ilya Maximets wrote:
> On 14.05.2019 18:24, Roi Dayan wrote:
>>
>>
>> On 14/05/2019 18:16, Roi Dayan wrote:
> 
> <snip>
> 
>>>
>>>
>>> Hi,
>>>
>>> I did a quick ping test between two ports and after this commit the
>>> command ovs-dpctl dump-flows doesn't show the flows that are in tc.
>>> which did work before the commit.
>>> ovs-appctl dpctl/dump-flows does show the flows fine.
>>>
>>> I didn't have time to help debug but I'll try to help tomorrow.
>>>
>>> Thanks,
>>> Roi
>>>
>>
>> could be ovs-dpctl which is a standalone doesn't ever call
>> netdev_run()->netdev_initialize()->netdev_register_flow_api_provider() ?
>>
> 
> Hi. Thanks for testing.
> 
> The issue is a bit different. Providers are registered, however flow API is
> not initialized because "netdev_flow_api_enabled" is always false in a
> separate standalone application like ovs-dpctl.
> 
> Actually, I'd consider the working "ovs-dpctl dump-flows" as a *bug on
> current master* that this patch intended to fix. It's a bug basically because
> ovs-dpctl uses flow API after netdev_init_flow_api() failure (returns EOPNOTSUPP)
> and even worse with globally disabled offloading.
> 
> I don't see the way how to make it work in these conditions because flow API
> initialization will be destructive for the running datapath. It'll be better
> to start thinking on how to document this properly.
> 
> Thoughts?
> 
> Best regards, Ilya Maximets.
> 

sure. i guess you're right as all config settings are at their default
when using ovs-dpctl and beside hw_offload they don't affect the dump.
Then maybe just a note about this in hw_offload info? that users should
use ovs-appctl for dump?


More information about the dev mailing list