From patchwork Thu Mar 22 22:57:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Ahern X-Patchwork-Id: 889716 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=cumulusnetworks.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b="O1nNoefY"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 406hsg4dZwz9s0q for ; Fri, 23 Mar 2018 09:58:15 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751848AbeCVW6N (ORCPT ); Thu, 22 Mar 2018 18:58:13 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:44243 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbeCVW6M (ORCPT ); Thu, 22 Mar 2018 18:58:12 -0400 Received: by mail-pg0-f65.google.com with SMTP id v26so1345963pge.11 for ; Thu, 22 Mar 2018 15:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=from:to:cc:subject:date:message-id; bh=QL+qIc1db8koQOJI9eiO8OtlQ33PajbdjOuqd8GfGl8=; b=O1nNoefYHmwpjdpYE1Oiz0pzZNSfdQVlQnYGyOY+aL/4CiGDcZlTZp7Kf3NFZzaTxT 8K5krxEnoa++AS7fJPjXY6VBwKWzOTmoNlJPaUNwCswzxtC3M0FE6WIdBtsG0/LzzcOV W/px4BK3ne7fxgZnpOKdbPWMOXXUpV99RJxog= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=QL+qIc1db8koQOJI9eiO8OtlQ33PajbdjOuqd8GfGl8=; b=iUvWrIHZuaSrTmwaS1r8YhMjwZMoB+DLa1w9YcBLL0Wxb6rJ4GUEccagqZexVUP9/x 4C9jnqfaGpmrMM3iuta41IEjLDK0aLIex2TXn2llScYfNqtT/BxyMDl34u9FVaK6DAUl byuCsFZprVeE/0JInwjviSQDz5BNxQNWY8o1OQP1W5O71Ski3GjceJ9n+jfzRJR+8R1E xGxBZ6d8Z+cFG+BV8891kg76Ffpf78CwJgW+ZkwSuslvQviQkwRM1haHgQZXbE3z5OMx WxR7jNXrdMstq1u3x83X74ElpQKVGtcxbHEmUv7uFV5GnyOhrDybeNaQqPbxUVyRnpdw 8vfw== X-Gm-Message-State: AElRT7HnKKB82nY2+DnNxWppXa7esJU/jenQaaPb62J0bsvP4hIr97Et iRR6H25FBIv2n3gBHUMUV8qe0jUR X-Google-Smtp-Source: AG47ELv4IxolZ9mnRC/YV/F8bEH5o/Ms1pgHV4bOzs1Qn/0G5L6moC97xkPRbKdmQh4DonOwgm710Q== X-Received: by 10.98.234.22 with SMTP id t22mr21951556pfh.56.1521759491116; Thu, 22 Mar 2018 15:58:11 -0700 (PDT) Received: from kenny.it.cumulusnetworks.com. (fw.cumulusnetworks.com. [216.129.126.126]) by smtp.googlemail.com with ESMTPSA id b78sm15807767pfe.88.2018.03.22.15.58.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 15:58:10 -0700 (PDT) From: David Ahern To: netdev@vger.kernel.org Cc: davem@davemloft.net, roopa@cumulusnetworks.com, shm@cumulusnetworks.com, jiri@mellanox.com, idosch@mellanox.com, jakub.kicinski@netronome.com, David Ahern Subject: [PATCH RFC net-next 0/7] net: Allow FIB notifiers to fail add and replace Date: Thu, 22 Mar 2018 15:57:50 -0700 Message-Id: <20180322225757.10377-1-dsa@cumulusnetworks.com> X-Mailer: git-send-email 2.11.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org I wanted to revisit how resource overload is handled for hardware offload of FIB entries and rules. At the moment, the in-kernel fib notifier can tell a driver about a route or rule add, replace, and delete, but the notifier can not affect the action. Specifically, in the case of mlxsw if a route or rule add is going to overflow the ASIC resources the only recourse is to abort hardware offload. Aborting offload is akin to taking down the switch as the path from data plane to the control plane simply can not support the traffic bandwidth of the front panel ports. Further, the current state of FIB notifiers is inconsistent with other resources where a driver can affect a user request - e.g., enslavement of a port into a bridge or a VRF. As a result of the work done over the past 3+ years, I believe we are at a point where we can bring consistency to the stack and offloads, and reliably allow the FIB notifiers to fail a request, pushing an error along with a suitable error message back to the user. Rather than aborting offload when the switch is out of resources, userspace is simply prevented from adding more routes and has a clear indication of why. Patch 1 fixes call_fib_notifiers to extract the errno from the encoded response from handlers. Patches 2-5 allow the call to call_fib_notifiers to fail the add or replace of a route or rule. Patch 6 exports some devlink symbols. Patch 7 adds a simple resource controller to netdevsim to illustrate how a FIB resource controller can limit the number of route entries. David Ahern (7): net: Fix fib notifer to return errno net: Move call_fib_rule_notifiers up in fib_nl_newrule net/ipv4: Move call_fib_entry_notifiers up for new routes net/ipv4: Allow notifier to fail route repolace net/ipv6: Move call_fib6_entry_notifiers up for route adds devlink: Export methods to get and set namespace netdevsim: Add simple FIB resource controller via devlink drivers/net/netdevsim/Makefile | 4 + drivers/net/netdevsim/devlink.c | 281 ++++++++++++++++++++++++++++++++++++++ drivers/net/netdevsim/fib.c | 264 +++++++++++++++++++++++++++++++++++ drivers/net/netdevsim/netdev.c | 12 +- drivers/net/netdevsim/netdevsim.h | 42 ++++++ include/net/devlink.h | 2 + net/core/devlink.c | 6 +- net/core/fib_notifier.c | 5 +- net/core/fib_rules.c | 6 +- net/ipv4/fib_trie.c | 27 +++- net/ipv6/ip6_fib.c | 16 ++- 11 files changed, 652 insertions(+), 13 deletions(-) create mode 100644 drivers/net/netdevsim/devlink.c create mode 100644 drivers/net/netdevsim/fib.c