[ovs-dev] [RFC 0/2] EMC load-shedding

Darrell Ball dball at vmware.com
Fri Sep 22 18:20:03 UTC 2017


Thanks for working on this Billy
One comment inline.

On 9/22/17, 6:47 AM, "Billy O'Mahony" <billy.o.mahony at intel.com> wrote:

    Hi All,
    
    Please find attached RFC patch for EMC load-shedding [1] as promised [2].
    
    This applies clean on 5ff834 "Increment ct packet counters..." It also uses
    Ilya's patch "Fix per packet cycles statistics." [3] so I've included that in
    the patch set as it wasn't merged when I started the RFC.
    
    The main goal for this RFC is only to demonstrate the outline of the mechanism
    and get feedback & advice for further work.
    
    However I did some initial testing with promising results. For 8K to 64K flows
    the cycles per packet drop from ~1200 to ~1100. For small numbers of flows
    (~16) the cycles per packet remain at ~900 which I beleive means no increase
    but I didn't baseline that situation.
    
    There are some TODOs commented in the patch with XXX.
    
    For one I think the mechanism should take into account the expected cycle-cost
    of EMC lookup and EMC miss (dpcls lookup) when deciding how much load to shed.
    Rather than the heuristic in this patch which is to keep the emc hit rate (for
    flow which have not been diverted from the EMC) between certain bounds.


[Darrell]
Could you expand on the description of the algorithm and the rational?
I know the algorithm was discussed along with other proposed patches, but I
think it be would be beneficial if the patch (boils down to a single patch) described it.

Probably the code could benefit from some expanded comments as well?

I see one comment in the code
+        /* As hit rate goes down shed thresh goes up (more is shed from EMC) */
+        /* XXX consider increment more if further out of bounds *

    
    Also we should decide on at least one flow distribution that would be useful
    (i.e. realistic) for EMC testing. The tests above have either been carried out
    with a random (uniform) flow distribution which doesn't play well with flow
    caching or else a round-robin flow distribution which is actually adverserial
    to flow caching. If I have an agreed flow distribution I can then figure out
    how to produce it for testing :).
    
    [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DAugust_336509.html&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=xyXl4Y7PjflJKH8RTjHev3uMh9JgQGiFk0aPezyN3Qc&s=dr9kNy7p3flCYC1W1AO02TRCvTHiazrQ9A5-Ssi4A7o&e= 
    [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DSeptember_338380.html&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=xyXl4Y7PjflJKH8RTjHev3uMh9JgQGiFk0aPezyN3Qc&s=OvsyuPzDlkZOk_fNXK380np29aySrXUeLKUUKqHCKjw&e= 
    [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DAugust_337309.html&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=xyXl4Y7PjflJKH8RTjHev3uMh9JgQGiFk0aPezyN3Qc&s=eDHE9eXgzl8wlJhJ_pCqqSIuJYM0EfxgejqgD8xHBZ0&e= 
    
    Billy O'Mahony (1):
      dpif-netdev: RFC EMC load-shedding
    
    Ilya Maximets (1):
      dpif-netdev: Fix per packet cycles statistics.
    
     lib/dpif-netdev.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++-----
     1 file changed, 108 insertions(+), 10 deletions(-)
    
    -- 
    2.7.4
    
    



More information about the dev mailing list