Re: [ovs-discuss] [ovs-dev] Question about supporting the OVS out-of-tree kernel drivers

2020-12-16 Thread Flavio Leitner
On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
> On 11/12/20 6:04 PM, Gregory Rose wrote:
> > 
> > 
> > On 11/12/2020 5:10 AM, Mark Gray wrote:
> >> On 30/10/2020 18:32, Gregory Rose wrote:
> >>>
> >>> The question is whether there is any interest in continuing to support
> >>> the OVS out-of-tree (OOT) kernel driver or should we deprecate it?  The
> >>> latest kernel support for the OOT driver is up to 5.8.x  There seems to
> >>> be little interest that I can tell in using the OOT driver.  The main
> >>> distros all include the kernel built-in OVS driver and those drivers
> >>> generally seem to support all the primary features required by user space.
> >>>
> >>> Most of the energy on this list seems to be directed toward DPDK and OVN
> >>> and it doesn't seem to me that either of those require the OOT driver.
> >>> If there's no one actually using the OOT driver I suggest we deprecate
> >>> it and save time and energy on keeping it up to date.
> >>>
> >>> Opinions, thoughts, comments?
> >>>
> >>
> >> I think it is good to raise this question. Thanks.
> >>
> >> It would certainly simplify development of kernel features and avoid the
> >> type of issue that I had recently with a patch in the OOT tree but not
> >> upstream. As I don't know who uses OOT, I can't comment beyond that.
> > 
> > I'm knee deep in some work at my day job but when I get a
> > chance I'm going to send a patch for the faq, NEWS, etc. and request
> > that we deprecate the OOT driver and end support for newer kernels
> > at the current 5.8.  After that we'll only take bug fixes.
> > 
> > I don't really believe there are any consumers for the OOT driver
> > on this list anymore.  Certainly the lack of response to this
> > question indicates that.
> 
> CC: ovs-discuss
> 
> Thanks for raising this question.
> 
> As far as the topic goes, the only thing that might get people to use
> the OOT module with kernels higher than 5.8 is SST or LISP support.
> On the other hand, there were reasons to reject patches to support these
> protocols in the mainline kernel.  And I have no idea if anyone is actually
> using them.  I never used them and I'm not even sure if they actually work
> taking into account that we have only 2 system tests for them that doesn't
> really check much.
> 
> Maybe we could also raise the question during the conference to get more
> attention.  I'd like to add a reference into my "community updates"
> presentation.
> 
> I know that it takes a lot of time to support OOT kernel module and it
> doesn't seem worth the effort.  I'd vote for deprecation and eventual
> removal.  Sending patches is a good idea, with them we could move forward
> if no strong objections will appear.  And thanks for all the work you did
> supporting kernel module all that time!

Since the conference already happened, have you decided something?

I suggest to follow "Feature Deprecation Guidelines" section in
Documentation/internals/contributing/submitting-patches.rst with
the addition of warning when building that code for extra
visibility.

Thanks,
-- 
fbl
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] BUG? hot upgrade with primary controllers

2020-12-16 Thread Johannes Naab
Hi,

I am trying to perform a hot upgrade
(https://docs.openvswitch.org/en/latest/intro/install/general/#hot-upgrading,
via `scripts/ovs-ctl`).
The upgrade/restart works as expected only if no primary controller is
configured. If a primary controller is configured, the flows are not
properly restored (more specific: they are restored but later seem to be
flushed again).

My current understanding on what happens:
- `ovs-ctl` dumps the flows somewhere in /tmp/
- `ovsdb-server` is restarted, `flow-restore-wait` is set
- `ovs-vswitchd` is restarted
  - `bridge_configure_remotes()` in `vswitchd/bridge.c` checks for
`flow-restore-wait` (currently set) and the configured primary
controllers are skipped for now.
This is expected and intentional as per
7ed73428a675a174d629d694e483f81358dc907e (bridge.c: prevent
controller connects while flow-restore-wait) in 2.11.
- the flows are restored via the management socket from /tmp/.
- `flow-restore-wait` is set to false/removed, signaling that the work
  is done
  - `brige_configure_remotes()` is triggered, and the configured primary
controllers are now considered for connection.
  - in `connmgr_set_controllers()` in `ofproto/connmgr.c`
`had_controllers` is false, since previously no (primary) controller
was configured.
But the controllers are now being configured.
Thus, the conditional for `had_controllers !=
connmgr_has_controllers(mgr)` will later be executed. This will
flush the (previously reinstalled) flows. This is to implement the
state transition between a standalone and a managed switch.

The combination of not directly connecting to the primary controllers
during flow restore, together with the standalone/managed state
transition seems to currently break any attempts for a consistent flow
restore.

Running ovs-vswitchd with 7ed73428a675a174d629d694e483f81358dc907e
(bridge.c: prevent controller connects while flow-restore-wait)
reverted, I am able to restore flows even if a primary controller is
configured.

Are there any obvious ways to get flow restore with primary controllers
working (again)?
So far I have only come up with the approach (not implemented) of
explicitly detecting the falling edge for `flow-restore-wait`, and
passing this information all the way through to
`connmgr_set_controllers`. But that seems a bit invasive...


Best Regards,
Johannes
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss