Hello

   Thanks for the documentation, Ben.

   My ingress interface is eth0 but I was seeing no result related to rate
limit limiting the rate so I put on eth1 and after that on eth0 and also
eth1.

   Have someone tested if the rate limit works properly on OpenvSwitch
1.8.90, that is the version I have installed, or in other version?

   You said: "It's a feature of the Linux kernel.  Open vSwitch just
configures the feature." But I think openvSwitch implements token bucket
on source code because there are token-bucket.c and token-bucket.h.

   My procedures are: create a bridge br0 and I after add eth0 and eth1,
and after this I set the rate an burst. The interfaces eth0 and eth1 have
to be mandatory virtual interfaces? or can be normal physical interfaces?

   Regards
   Marco

   Citando Ben Pfaff <b...@nicira.com>:
On Mon, Aug 20, 2012 at 05:06:43PM +0100, mvpb...@iol.pt wrote:  > I
have apply first to eth0 after to eth1 and also in eth0 and eth1. I
   test with iper, with NetStress and also with an ftp file transference.
     But this is not limiting the rate, why?
  Did you read the documentation?

      Ingress Policing:
        These  settings  control  ingress policing for packets
received on this
        interface.  On a physical interface, this  limits  the 
rate  at  which
        traffic  is  allowed  into  the  system  from the outside;
on a virtual
        interface (one connected to a virtual machine), this limits
the rate at
        which the VM is able to transmit.

        Policing is a simple form of quality-of-service that simply
drops pack‐
        ets received in excess of the configured rate.  Due to its 
simplicity,
        policing  is  usually  less accurate and less effective than
egress QoS
        (which is configured using the QoS and Queue tables).

        Policing is currently implemented only on Linux.  The Linux
implementa‐
        tion uses a simple ``token bucket’’ approach:

               ·      The  size  of  the  bucket  corresponds to
ingress_polic‐
                      ing_burst.  Initially the bucket is full.

               ·      Whenever a packet is received,  its  size 
(converted  to
                      tokens)  is compared to the number of tokens
currently in
                      the bucket.  If the required number of tokens
are  avail‐
                      able, they are removed and the packet is
forwarded.  Oth‐
                      erwise, the packet is dropped.

               ·      Whenever it is not full,  the  bucket  is 
refilled  with
                      tokens at the rate specified by ingress_policing_rate.

        Policing  interacts  badly  with some network protocols, and
especially
        with fragmented IP packets.   Suppose  that  there  is 
enough  network
        activity to keep the bucket nearly empty all the time.  Then
this token
        bucket algorithm will forward a single packet every so
often, with  the
        period depending on packet size and on the configured rate. 
All of the
        fragments of an IP packets are normally transmitted
back-to-back, as  a
        group.   In  such  a  situation, therefore, only one of
these fragments
        will be forwarded and the rest will be dropped.  IP  does 
not  provide
        any  way for the intended recipient to ask for only the
remaining frag‐
        ments.  In such a case there are two likely possibilities
for what will
        happen next: either all of the fragments will eventually be
retransmit‐
        ted (as TCP will do), in which case the same problem will
recur, or the
        sender  will not realize that its packet has been dropped
and data will
        simply be lost (as some UDP-based protocols will do). 
Either  way,  it
        is possible that no forward progress will ever occur.

        ingress_policing_rate: integer, at least 0
               Maximum rate for data received on this interface, in
kbps.  Data
               received faster than this  rate  is  dropped.   Set 
to  0  (the
               default) to disable policing.

        ingress_policing_burst: integer, at least 0
               Maximum  burst  size for data received on this
interface, in kb.
               The default burst size if set to 0 is 1000 kb.  This 
value  has
               no effect if ingress_policing_rate is 0.

               Specifying  a  larger burst size lets the algorithm
be more for‐
               giving, which is important for protocols like TCP
that react se‐
               verely  to  dropped  packets.  The burst size should
be at least
               the size of the interface’s MTU.  Specifying  a 
value  that  is
               numerically  at  least  as large as 10% of
ingress_policing_rate
               helps TCP come closer to achieving the full rate.
Can someone tell me where rate-limit is done at source code level?
It's a feature of the Linux kernel.  Open vSwitch just configures thefeature.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to