----- Original Message ----- | From: "Doron Fediuck" <[email protected]> | To: "Giuseppe Vallarelli" <[email protected]> | Cc: "Ofri Masad" <[email protected]>, [email protected], "Moti Asayag" <[email protected]>, "Mike Kolesnik" | <[email protected]>, "Michal Privoznik" <[email protected]> | Sent: Sunday, July 14, 2013 11:16:02 AM | Subject: Re: network and vnic qos | | | | ----- 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.
Hi Doron, thanks for the explanation I wasn't aware of this concern. | So for this reasoning we will start with as stable implementation as | possible. | Going forwards we may re-visit based on users feedback. Ok, I'm going to update my proposal to conform with this choice. Thanks for the feedback! Cheers, Giuseppe | | | 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
