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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED 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 DE6F4C282DC for ; Wed, 17 Apr 2019 16:34:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AE05C2173C for ; Wed, 17 Apr 2019 16:34:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="LQ43mq3t" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732862AbfDQQek (ORCPT ); Wed, 17 Apr 2019 12:34:40 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:42757 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732843AbfDQQej (ORCPT ); Wed, 17 Apr 2019 12:34:39 -0400 Received: by mail-qk1-f195.google.com with SMTP id b74so14723644qkg.9 for ; Wed, 17 Apr 2019 09:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=O4qELR4ahnQeGriuhQHTf9gcJkGtJj949YwimahAKgY=; b=LQ43mq3tBtACEM1hSdpuVHby8SyvxPH0n8B9vf7t4z/PFSV565nB9intc7iREdw4cK snCscnm/lOi+XuWkWPqGMHnkKYTdYImdpMLlKbs20sUcuwhFKFgUM0prCgjUwSPJU81o 2XZQ1L8LN7oecAQe9SAJlEZoE/6nP9XHOxG5X/F6uRZsMEagIqtNFq9nAkyATb0rGDe0 jmhoHqs5ff6PvhxiimmvPhFd3tZc4ByPShgyDoZseDuwyMg7UBKK07H6xmXWsscI7WDk E9/bjc+9dId+J/xeRrL/6czBnE2oQ+na5JION7PUz9GE23hjdZOiRteGYzEqYMHU6SLy yAbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=O4qELR4ahnQeGriuhQHTf9gcJkGtJj949YwimahAKgY=; b=F+QgIJnIkopHjlp1xmaMMNPBYf5a4imdym85IMkaQmMVBVeDJZpNAdooFqoHXNxOxj 4qDJOo6hCxPpNUcJODt22qbHgfbn3Joff/TFzqKX/sbseAFhOY3KowyDNt5WuSNLk0Qc bk8i+TLw4w4I39CUP5yKKe1KJJmicKBZ+FQDHhKcqxQtLx8eZHdSk9uFZrD0Qg8lsdDg zpUcwrMcsSCkVLBT3KT4Fk3Sp3pLqoPqWNdZpuY4Nc2IefFHptk9Xtjma9Q2qLBgWmmJ 2ITSYSOPlOdzaBOsUORh+ygUzKnR6SF2VS7m4UfZIP/hbxUPtNMW66dtnqUmUkoTMb6j M+2g== X-Gm-Message-State: APjAAAXl5jRPNEdy9NFCRGScpD+wZiCTx3M7vDb9k0iOau99eYoqZ1HN LMffVcNg/ZWwRv8njAKq153YbA== X-Google-Smtp-Source: APXvYqxMt9tG4emNJ/doVJn1f24fdE273lgCDHeHMx6DaFqInxk/8P8fcgU4PmWXJhQfVwvXWTlFnA== X-Received: by 2002:a37:4e4d:: with SMTP id c74mr69155949qkb.230.1555518878240; Wed, 17 Apr 2019 09:34:38 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id f93sm33787999qtb.16.2019.04.17.09.34.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 09:34:38 -0700 (PDT) Date: Wed, 17 Apr 2019 09:34:32 -0700 From: Jakub Kicinski To: Vlad Buslov Cc: "netdev@vger.kernel.org" , "jhs@mojatatu.com" , "xiyou.wangcong@gmail.com" , "jiri@resnulli.us" , "davem@davemloft.net" Subject: Re: [RFC PATCH net-next] net: sched: flower: refactor reoffload for concurrent access Message-ID: <20190417093432.495dcda6@cakuba.netronome.com> In-Reply-To: References: <20190410100014.784a7f9a@cakuba.netronome.com> <20190416142047.3453-1-vladbu@mellanox.com> <20190416144933.4ddb0e68@cakuba.netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 17 Apr 2019 07:29:36 +0000, Vlad Buslov wrote: > On Wed 17 Apr 2019 at 00:49, Jakub Kicinski wrote: > > On Tue, 16 Apr 2019 17:20:47 +0300, Vlad Buslov wrote: > >> @@ -1551,6 +1558,10 @@ static int fl_change(struct net *net, struct sk_buff *in_skb, > >> goto errout_mask; > >> > >> if (!tc_skip_hw(fnew->flags)) { > >> + spin_lock(&tp->lock); > >> + list_add(&fnew->hw_list, &head->hw_filters); > >> + spin_unlock(&tp->lock); > >> + > >> err = fl_hw_replace_filter(tp, fnew, rtnl_held, extack); > >> if (err) > >> goto errout_ht; > > > > Duplicated deletes should be fine, but I'm not sure same is true for > > adds. Won't seeing an add with the same cookie twice confuse drivers? > > > > There's also the minor issue of offloaded count being off in that > > case :) > > Hmmm, okay. Rejecting duplicate cookies should be a trivial change to > drivers though. Do you see any faults with this approach in general? Trivial or not it adds up, the stack should make driver authors' job as easy as possible. The simplest thing to do would be to add a mutex around the HW calls. But that obviously doesn't work for you, cause you want multiple outstanding requests to the FW for a single tp, right? How about a RW lock, that would take R on normal add/replace/del paths and W on replays? That should scale, no?