On Wed, Jun 12, 2019 at 08:46:06AM -0700, Darrell Ball wrote: > On Mon, Jun 10, 2019 at 9:51 AM Ben Pfaff <[email protected]> wrote: > > > On Sun, Jun 09, 2019 at 07:35:09AM -0700, Darrell Ball wrote: > > > This may be needed in some special cases, such as to support some > > > hardware offload implementations. > > > > > > Reported-at: > > https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359188.html > > > Signed-off-by: Darrell Ball <[email protected]> > > > --- > > > > > > v2: Per particular requirement, support 'no-tcp-seq-chk' rather than > > > 'liberal' mode. > > > > > > Add some debug counters. > > > > I'm not sure whether an ovs-appctl command is the best way for users to > > enable and disable this. It means that it is difficult for an OpenFlow > > controller to do it, since those commands aren't exposed via OpenFlow or > > OVSDB. > > > > Thanks for your comments > > For local controller usage, we are using ovs-appctl today in similar cases > for existing products. > > In the case of non-local controller usage, the remote controller would need > remote access. > > However, in this case, I don't expect the remote controller to be > involved; I was assuming > that a deployment script would be used to set the value to non-default > value (in needed cases) > when ovs-vswitchd is (re)started only. If this assumption cannot be > satisfied then we would > have to have to introduce a dependency on the database for these types of > commands.
This seems to be teetering toward the pre-SDN model of having to separately configure each switch. Do you have some rationale in mind why this should be a per-node decision rather than one made by the controller? I understand that we currently have other configuration done through ovs-appctl, but that doesn't necessarily mean we made the right decision there either. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
