>scenario like this:
>
> 1. In the OVS database, the manager (which could be a human admin
> or a program) sets an interface to use some particular QoS
> settings. OVS configures them on the interface.
>
> 2. Someone stops OVS.
>
> 3. The manager deletes the QoS settings from the OVS database.
>
> 4. Someone starts OVS again.
>
>Currently, following step 4, OVS clears the QoS settings, because it
>always believes that it owns them, but with this change it would
>preserve them.I have one question, while internal port is created by ovs-vsctl
>command,then when OVS stopped, why this internal port still exists? In this
>condition, I think it is rational to clear OVS QoS settings when DB settings
>changed,because we set the QoS by OVS command.
>Other possible changes in this area, with different tradeoffs:
>
> * Add a QoS type that says that OVS should leave the QoS
> settings alone for an interface. This would solve the problem
> but it seems user-unfriendly, since it is surprising that OVS
> changes the QoS settings at all if it isn't asked to do so.
I think it is a good idea. OVS configure egress QoS with this method.
when egress QoS is disabled, we set the QoS type to null, or just clear port
qos.
maybe we can coding just like egress QoS do:
in function iface_configure_qos():
if (!qos || qos->type[0] == '\0' || qos->n_queues < 1) {
netdev_set_qos(iface->netdev, NULL, NULL);
}
in function netdev_linux_set_qos():
if (new_ops == netdev->tc->ops) {
error = new_ops->qdisc_set ? new_ops->qdisc_set(netdev_, details) : 0;
} else {
...
}
so if egress QoS is already disabled, it will do nothing(if branch)
and if egress QoS is cleared, it will enter the else branch.
> * Make OVS record in the database when it changes the QoS
> settings (upon request only), so that it can change them back
> only if it set them up to begin with. This might be hard to
> do reliably across system reboots and deletions and creations
> of distinct network devices that have the same name.
If ingress QoS is set by linux tc, then the qdisc rule may more complicated
than OVS ingress policing,
and so there maybe not one-to-one mapping from linux QoS to OVS QoS._______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
