Dear Mr Justin! >As your sugestion, I can only set the queue for output port. But I think setting queue for output port is not good because the traffic has already entered the network. Is there any way to set queue for input port? so if the customer sends more traffic than the SLA, I can drop the packet before it can enter the network?
At first I think it's better to drop the packet before it enters the openvswitch so the openvswitch doesn't need to spend the resource to calculate and route the traffic to the outport. But based on your suggestion, my experiment network is not large so doesn't need inport SLA. >And to periodically change the queue rate, as I understand I have to periodically reconfigure the queue rate. How about the stability of this solution. I mean I don't know whether when I reconfigure the queue rate, there will be loss and if I change the queue rate frequently, there will be a lot of packet loss. But I think I will try to test it by myself. Thank you very much for your valuable suggestion! Trinh Minh Tri On Fri, Sep 2, 2011 at 5:31 PM, Justin Pettit <jpet...@nicira.com> wrote: > On Sep 1, 2011, at 5:35 AM, Trinh Minh Tri wrote: > > > As your sugestion, I can only set the queue for output port. But I think > setting queue for output port is not good because the traffic has already > entered the network. Is there any way to set queue for input port? so if the > customer sends more traffic than the SLA, I can drop the packet before it > can enter the network? > > I don't undertand your setup. The switch will receive packets on an > ingress port and send it on an egress one. The traffic will be dropped on > the egress port, but this is before it actually enters the network. There > can be reasons to want to drop based on the ingress port (such as wanting to > limit the total amount of traffic an ingress port can send across all egress > ports), but I'm not sure that's what you're describing. In any case, Linux > has pretty weak support for ingress traffic shaping, and we use the kernel's > native traffic control mechanisms . We support an ingress traffic policer, > but that is much harder to configure properly than an egress traffic shaper. > > > And to periodically change the queue rate, as I understand I have to > periodically reconfigure the queue rate. How about the stability of this > solution. > > What do you mean about the stability of the solution? > > > And is there any way to monitor that queue throughput? I mean the > actual traffic flowing through that queue? > > The ovs-ofctl "queue-stats" command should give you that information. It's > documented in the ovs-ofctl man page. You can do the same thing through > OpenFlow, as well. > > Glad to hear you're making progress! > > --Justin > > >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
