----- Original Message ----- | From: "Giuseppe Vallarelli" <[email protected]> | To: "Ofri Masad" <[email protected]> | Cc: [email protected], "Moti Asayag" <[email protected]>, "Mike Kolesnik" <[email protected]>, "Michal Privoznik" | <[email protected]>, "Doron Fediuck" <[email protected]> | Sent: Sunday, July 14, 2013 11:36:45 AM | Subject: Re: network and vnic qos | | ----- Original Message ----- | | From: "Ofri Masad" <[email protected]> | | To: "Giuseppe Vallarelli" <[email protected]> | | Cc: [email protected], "Moti Asayag" <[email protected]>, "Mike Kolesnik" | | <[email protected]>, "Michal Privoznik" | | <[email protected]>, "Doron Fediuck" <[email protected]> | | Sent: Sunday, July 14, 2013 9:22:16 AM | | Subject: Re: network and vnic qos | | | | Hi Giuseppe, | | Hi Ofri, | | | First of all, thanks for reviewing the design and the implementation. | | as for your comments, as I see it, we need to separate between what we can | | do | | (using libvirt) and what we would like to expose to the user. | | in my point of view, when a user is working with out engine (in appose to | | working directly with libvirt or vdsm) he expects different things. | | this is why we sometime take different choices from libvirt, to make the | | usage more simple/intuitive, to allow more complex abstraction | | or to get better control over the full system. | | I understand the need of taking different decisions or not being completely | tied to the underlying implementation. What I feel is that libvirt is much | more flexible and we're limiting the usage. If you feel this the right way to | go it's perfectly fine to me. In case users will have different expectations | than we might revise this decision in the future. | | | | | specific comment inline | | | | ----- Original Message ----- | | > From: "Giuseppe Vallarelli" <[email protected]> | | > To: [email protected] | | > Cc: "Ofri Masad" <[email protected]>, "Moti Asayag" <[email protected]>, | | > "Mike Kolesnik" <[email protected]>, | | > "Michal Privoznik" <[email protected]> | | > Sent: Thursday, July 11, 2013 6:14:59 PM | | > Subject: network and vnic qos | | > | | > Hi Ofri, me, Moti and Mike have been looking carefully through the design | | > spec of the vnic profiles[0] | | > and lately to the network traffic shaping [1] which is very closely | | > related. | | > A reason of concern is the current design of network qos table[2]. | | > | | > First issue is the one related to the attributes associated to the | | > traffic | | > shaping (either inbound | | > or outbound), I got the chance to talk with Michal (a libvirt developer | | > in | | > Brno) which confirmed me | | > that the only compulsory attribute is average both burst and peak are | | > optional, also he told me that | | > libvirt doesn't provide any default values in case those are missing | | > ones. | | > Looking at missingValue() | | > method in [3] seems that all 3 values are compulsory. | | | | By not defining the other two values, we actually leave the decision to | | libvirt. that means that the different libvirt releases | | may take different decision. when the user is setting a specific QoS for | | his | | network, he expect to see the same behavior over | | all of the VNICs using that QoS (even if they are running on different | | libvirt versions). | | I will let Michal answer to this specific concern, I'm not fully convinced | that libvirt might place default values for unspecified attributes in the | future. |
Giuseppe, you need to remember that a value may not necessarily be a number. It can also be a formula which will behave differently on overutilized VS underutilized hosts. Either way, undefined means exactly that. As a concept SLA cannot assume it, or we're loosing the upper bound capabilities. So for this reasoning we will start with as stable implementation as possible. Going forwards we may re-visit based on users feedback. | setting all three values in the engine | | allows us to force this unity. I will, however, add some default relations | | to | | the UI. so that when a user is setting the Average | | value, the Peak and Burst values will be automatically derived (but could | | be | | edited, of course). | | | | > | | > Second issue is mostly related to the decision of creating a single table | | > with traffic shaping | | > for both incoming and outgoing traffic (in table defined respectively as | | > inbound and outbound). | | > Incoming and outgoing traffic are independent and practically the same. | | > If | | > a | | > network admin defines | | > only incoming traffic, outgoing traffic attributes are nulls. | | > | | > An alternative approach that we discussed is the following one: a table | | > named | | > simply qos | | > or if you prefer qos_profile with the three attributes average (not | | > null), | | > burst and peak and an id. | | > In this case after the user creates a profile, that one can be | | > associated, | | > as | | > you defined in your spec, | | > to a vnic (and in the future to a network). I'm not sure if we need a | | > different attribute | | > to specify for convenience the traffic at which the qos profile is | | > applied | | > (incoming/inbound, ougoing/outbound). | | | | As for the difference between inbound and outbound, this is one of the most | | common use cases, i believe both your home and office | | networks have different inbound and outbound limits. | | As for the single table. first, in the future we plan on adding another | | attribute, "floor". which apply only to outbound. | | second, I don't really see in what way this is better than the current | | design | | For how you've conceived the traffic shaping, which means having the user | define all values and traffic type, my proposal is no better than yours | but I was looking from a different angle. | | | - and so I don't see why we should rewrite this | | feature from scratch one day before feature freeze. | | There's no need to do that, right now, as said previously. | | Thanks Giuseppe | | | | | > | | > Cheers, Giuseppe | | > | | > | | > [0]http://www.ovirt.org/Features/Network_QoS | | > [1]http://www.ovirt.org/Features/Network_traffic_shaping | | > [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql | | > [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java | | > | | | | thanks again, | | | | Ofri | | | _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
