From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=iwK6=QZ=vger.kernel.org=netdev-owner@kernel.org>
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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham
	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 CB154C43381
	for <netdev@archiver.kernel.org>; Mon, 18 Feb 2019 19:55:50 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id 9DFB5204EC
	for <netdev@archiver.kernel.org>; Mon, 18 Feb 2019 19:55:50 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AvzGJO//"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1727092AbfBRTzt (ORCPT <rfc822;netdev@archiver.kernel.org>);
        Mon, 18 Feb 2019 14:55:49 -0500
Received: from mail-pl1-f196.google.com ([209.85.214.196]:41391 "EHLO
        mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725535AbfBRTzt (ORCPT
        <rfc822;netdev@vger.kernel.org>); Mon, 18 Feb 2019 14:55:49 -0500
Received: by mail-pl1-f196.google.com with SMTP id y5so3656841plk.8
        for <netdev@vger.kernel.org>; Mon, 18 Feb 2019 11:55:49 -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=ZmBfwT6dV9ZMrOwWyUumqafwhugzGSZzaRxruZEKkZM=;
        b=AvzGJO//bUqE+glstsggksP8OAWzLs69oRf735qnqsRgZ7d9aC9fqeKPMkhk8EFwsx
         tFhtVnG3prpXtxF36Shn6/wdx1b/kh9uSPM9D7O0DG4ikIrwWN2YoTfCZ4m4qVMZy4wf
         oLN005XXptuCA1knTj/lMMdcUJ8THT0DpKRFSieqrjlIksUETLPDwfJgdY9mwpZpZ1GB
         DeYDOU8tSGv8HFs061zlUrzwyRjVjlQH9YMKUf01rJXG0Knxv2mM0u3wvGAkHITjud6/
         ng5fck2kdy/yedBWrorMVYCnnwI4X4GWkewlxTtmjiaUzzzeijMRXzbehgEC6Dv2zZ1l
         1pkQ==
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=ZmBfwT6dV9ZMrOwWyUumqafwhugzGSZzaRxruZEKkZM=;
        b=ds0o9aYcwnJdzZBl6usGC4ti0eQRKt8x2wGjKwPYSmIjEPFmPFpAXivbBtGqUoElPH
         2K8Bi4BtAHRClKsUQDPPISBU7AhCL8uZXCLS3xabujhNgjItCXiVEReOH+sFkY6shy0F
         LJVZliX1l5xHdZkQC2Ddxlrqf2yxyTtMjR0OByD0Diain0lt5VJLAIiROAMCFA4rbBoI
         Ez0Y//bCcB8ufIHFrJQSiy36mA5DZ18Amzl0F2Vd+iKn0XVstEVu3Fh7P2noAVnoZihz
         /00KE6wb1ursG6SgjNpaBxwd8yPbOJ0mCiGfMv8CKLzs1P4Zt8swr7WhRnS9zrC1GFBw
         3cig==
X-Gm-Message-State: AHQUAuaJ26FsbgMPLtL6UHpQId8HoOT/uQ/ZhKyZfcxbReWi60id404P
        C9DHZ+EOZOF5CMKSYqfPL2PGdx8/RdfgSELLbOI=
X-Google-Smtp-Source: AHgI3IaAlq8usEh9yKo3hjp+jLwv1XkyJ8YwB3R2ATtIXhIV8T8Nodsvf0LEjdUng8IzvPPNX65rkuKU/S4EVhv8W+g=
X-Received: by 2002:a17:902:8203:: with SMTP id x3mr1120177pln.159.1550519748713;
 Mon, 18 Feb 2019 11:55:48 -0800 (PST)
MIME-Version: 1.0
References: <20190211085548.7190-1-vladbu@mellanox.com> <20190211085548.7190-11-vladbu@mellanox.com>
 <CAM_iQpVdO5G9a+C4FecORHOuO7uKu6=fqKa-CUTyFMd_heyU+Q@mail.gmail.com> <vbfimxhqr7z.fsf@mellanox.com>
In-Reply-To: <vbfimxhqr7z.fsf@mellanox.com>
From:   Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon, 18 Feb 2019 11:55:37 -0800
Message-ID: <CAM_iQpU9x_SJ3xytqN6rBx_bpvc6KiqOHi3VddKOFcFGh+0eqw@mail.gmail.com>
Subject: Re: [PATCH net-next v4 10/17] net: sched: refactor tp insert/delete
 for concurrent execution
To:     Vlad Buslov <vladbu@mellanox.com>
Cc:     Linux Kernel Network Developers <netdev@vger.kernel.org>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Jiri Pirko <jiri@resnulli.us>,
        David Miller <davem@davemloft.net>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>
Content-Type: text/plain; charset="UTF-8"
Sender: netdev-owner@vger.kernel.org
Precedence: bulk
List-ID: <netdev.vger.kernel.org>
X-Mailing-List: netdev@vger.kernel.org

On Mon, Feb 18, 2019 at 3:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 15 Feb 2019 at 23:17, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> >> +static bool tcf_proto_is_empty(struct tcf_proto *tp)
> >> +{
> >> +       struct tcf_walker walker = { .fn = walker_noop, };
> >> +
> >> +       if (tp->ops->walk) {
> >> +               tp->ops->walk(tp, &walker);
> >> +               return !walker.stop;
> >> +       }
> >> +       return true;
> >> +}
> >> +
> >> +static bool tcf_proto_check_delete(struct tcf_proto *tp)
> >> +{
> >> +       spin_lock(&tp->lock);
> >> +       if (tcf_proto_is_empty(tp))
> >> +               tp->deleting = true;
> >> +       spin_unlock(&tp->lock);
> >> +       return tp->deleting;
> >
> > If you use this spinlock for walking each tp data structure,
> > why it is not needed for adding to/deleting filters from each
> > tp?
>
> This lock is intended to be used by unlocked classifiers and I use it in
> my following flower patch set extensively. Classifiers that do not set
> 'unlocked' flag continue to rely on rtnl lock for synchronization.

It is never late to add it when you seriously use it. The way you
split the patches is really annoying for reviewers...