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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
