From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB5ABCA9EC9 for ; Mon, 4 Nov 2019 22:21:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9AF4420650 for ; Mon, 4 Nov 2019 22:21:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CZO6qmnC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389124AbfKDWV3 (ORCPT ); Mon, 4 Nov 2019 17:21:29 -0500 Received: from mail-vk1-f193.google.com ([209.85.221.193]:38014 "EHLO mail-vk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388233AbfKDWV2 (ORCPT ); Mon, 4 Nov 2019 17:21:28 -0500 Received: by mail-vk1-f193.google.com with SMTP id o82so2297985vka.5 for ; Mon, 04 Nov 2019 14:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qlHVggnYKU4yg6Aco9hLyLl36Ze/VmjU5mUbYlr/NoI=; b=CZO6qmnCPwuKWRuyF1lQ9cHFrsSh1v+TrfRjil+EkFmbzHAEBK5aT/BamIyt8KzG++ 9dZjCTjXSAOdb3msR7/rYSjY7us/Bv1xvL4En0xVLyI09kOpuyD0JXo48yS0LcLoWpD+ q1srBSPEr9Uy16ATjfImLzUtc7xE62QPP8RkXW0Q4P7JcKe6OUWPEybPiBVHSDJ5NSlW d0Pd9g2uMOYLHgslaw7+jlzK9RycM0EiJ+KUqzlEpfaMrc43U7p4btCsdzK4I2uak4yL +MF29+UFeZP+X5s28S8gQZKvK7t28tic7zJ2PvtaaquRsZdwNV9UPF9RVxwJHzofHuz5 KKrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qlHVggnYKU4yg6Aco9hLyLl36Ze/VmjU5mUbYlr/NoI=; b=OgPhJsaX6Uab87sns5yrqzA3+4i8UGgLJaBYh7aBnCipU1N1XWEFwWL3RyKQ1tQCWE vQq20BW6snu5FUSSeIYCqCxrTZTSrzUtx9TQq75M/RNWft/3N4Ab28eVkCQoLsrrVCq5 ZRHpkvu9Cnizy0qk62hLUhYgLpXcbk/VE1+uIdun0ahmXL/y6eZlAtfPIyQiAatrZueS 8us/kzdzw1GyxBaqXxQaIyKzcpJdE0Xah6k5TpL787xk07OxSK9tht97z8ZN+vXGkXZ7 8YVvfpQ7SVFNsmBQlh5S/HPrj6egI1titwKEDxpXFBgbFlKhQW3WKTyIG71ZH+NqvMxw NkvQ== X-Gm-Message-State: APjAAAUBaODXgiIiwXicdxgFMQ/YNG2Zm7u5TOX65/lr2RgsJM4aTVSE eBaHd7NT4VkT5NfH4V+Qn+PlZAugjWPNle3GQc/8Q4JcYRQ= X-Google-Smtp-Source: APXvYqwyLRwB8QPnGnFfW/sKyFh5vJFx0Ur1w+RDPFinWqOm8+HPiehJRA8QCgrFeBQGd7Z9YwD7VQwEIAujLuA+Ykw= X-Received: by 2002:a1f:41c4:: with SMTP id o187mr12614740vka.102.1572906086939; Mon, 04 Nov 2019 14:21:26 -0800 (PST) MIME-Version: 1.0 References: <1572618234-6904-1-git-send-email-xiangxia.m.yue@gmail.com> <1572618234-6904-6-git-send-email-xiangxia.m.yue@gmail.com> In-Reply-To: From: William Tu Date: Mon, 4 Nov 2019 14:20:50 -0800 Message-ID: Subject: Re: [ovs-dev] [PATCH net-next v6 05/10] net: openvswitch: optimize flow-mask looking up To: Pravin Shelar Cc: Tonghao Zhang , ovs dev , "David S. Miller" , Linux Kernel Network Developers Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Nov 4, 2019 at 2:10 PM Pravin Shelar wrote: > > On Mon, Nov 4, 2019 at 6:00 AM William Tu wrote: > > > > On Sat, Nov 2, 2019 at 11:50 PM Pravin Shelar wrote: > > > > > > On Fri, Nov 1, 2019 at 7:24 AM wrote: > > > > > > > > From: Tonghao Zhang > > > > > > > > The full looking up on flow table traverses all mask array. > > > > If mask-array is too large, the number of invalid flow-mask > > > > increase, performance will be drop. > > > > > > > > One bad case, for example: M means flow-mask is valid and NULL > > > > of flow-mask means deleted. > > > > > > > > +-------------------------------------------+ > > > > | M | NULL | ... | NULL | M| > > > > +-------------------------------------------+ > > > > > > > > In that case, without this patch, openvswitch will traverses all > > > > mask array, because there will be one flow-mask in the tail. This > > > > patch changes the way of flow-mask inserting and deleting, and the > > > > mask array will be keep as below: there is not a NULL hole. In the > > > > fast path, we can "break" "for" (not "continue") in flow_lookup > > > > when we get a NULL flow-mask. > > > > > > > > "break" > > > > v > > > > +-------------------------------------------+ > > > > | M | M | NULL |... | NULL | NULL| > > > > +-------------------------------------------+ > > > > > > > > This patch don't optimize slow or control path, still using ma->max > > > > to traverse. Slow path: > > > > * tbl_mask_array_realloc > > > > * ovs_flow_tbl_lookup_exact > > > > * flow_mask_find > > > > > > > > Signed-off-by: Tonghao Zhang > > > > Tested-by: Greg Rose > > > > --- > > > Acked-by: Pravin B Shelar > > > > Nack to this patch. > > > > It makes the mask cache invalid when moving the flow mask > > to fill another hole. > > And the penalty for miss the mask cache is larger than the > > benefit of this patch (avoiding the NULL flow-mask). > > > Hi William, > > The cache invalidation would occur in case of changes to flow mask > list. I think in general datapath processing there should not be too > many changes to mask list since a mask is typically shared between > multiple mega flows. Flow-table changes does not always result in mask > list updates. In last round Tonghao has posted number to to support > this patch. > If you are worried about some other use case can you provide > performance numbers, that way we can take this discussion forward. > I see, I don't have any use case to provide. Thanks, William