From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1177B1E7C10 for ; Fri, 21 Mar 2025 08:47:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742546833; cv=none; b=gbZc0twaLe0B1iW2cFAw7FhTkAhG+TNKw7mu9Vz/lsv693ema24FzsEMsO+C828EXFLXmzpuXQYTvSySCsnGcRna8KSNUd24HPLb/+EnL7XLOOQBUdi/IqWVktY1ugEiFvtKWtltLNFhSwMnUJTqprXiVEN8COU7aoirUJ3zMPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742546833; c=relaxed/simple; bh=M6FotxqtmdavVYyLKswlHnM+jqLmZsfU30b8Zccel+I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=P6jb1mcKheMVGws2lgyhwUceJDy0fgM/NEMqu+rQGA7bavlsfwTAUolpkMCECEzPFsyjk6f7rRHMAQbEUl7Zyxm9PZSkioccY+tl5h21DQWCHWwvEHLl7urJEDRvnbF3TW4Jgq7kVisyOOYjf4yBTGDaysl/5nLKXNMrb0lkrXc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall-org.20230601.gappssmtp.com header.i=@blackwall-org.20230601.gappssmtp.com header.b=PatojUrM; arc=none smtp.client-ip=209.85.128.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall-org.20230601.gappssmtp.com header.i=@blackwall-org.20230601.gappssmtp.com header.b="PatojUrM" Received: by mail-wm1-f67.google.com with SMTP id 5b1f17b1804b1-43ce71582e9so11593255e9.1 for ; Fri, 21 Mar 2025 01:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall-org.20230601.gappssmtp.com; s=20230601; t=1742546830; x=1743151630; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bIPyhC1mQXfhzrv4tuYQo78989Vt+LnaUDryQAFr0iA=; b=PatojUrMX0yrMKa8cUmLMJsvM3lS+MYNqLrk7SwQuBL6khw4v1lYJpj75RtnqhUaf3 EGflwNp9lWE/dg91KPRM6uEXEJ9wyrMJEmjxCJlv40bVLgggwTUMkhNGjptVUgacIWWP pkQ4/Ut8LgDy8W2hdEHNE1VR0cm0QnuFtslJ+w2gf3V99A9kIG31QLr+kOoo8xTqH5dK RiBXm+TI5CqaqWnOYogy37dbO8KiAnGmFMgCL4/urZ2LnH0zCfBCrehEkqZO+egCy9+E Woxu0T2ScTnRje2gUJHYTKs97+SG8sdb3cTkuY0Xp0fMZdhzoAxJl/Ro1sH9LyCqA0LP Cyuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742546830; x=1743151630; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bIPyhC1mQXfhzrv4tuYQo78989Vt+LnaUDryQAFr0iA=; b=ZVtSBlLh7zj1uBGp0eFE+wpB8rvJqzGG6yiY93mQCYkY6TDSm1r+YAv4STq0ikFtTs 7qmm/o8Qejofq2lXKI3YwxfnS5+B+ErHGQcKOHiM2DL36ZJPD4MlyIS4S51Cow7HhtyO eGy6FRJM6ERu1KVriVlMefv0OkYCQGbEEveieKQePtRSy+WoMOFnYV81LiKW4aDGmzX2 yrf8dqK9m30NORksZESkmH54dKICCcrE1MRr6LCbOGs9d5e2wGShkaPf492+bCQIkxzz /a902uBYwzT2NeBz7VRLVL9jNmT1rXmwI/JS3Wxius2T/yorWPO8oJ2VYLHymCZT7jpC JglA== X-Forwarded-Encrypted: i=1; AJvYcCWRevv2nAoSNIYEJOooV1BoLNkSdRYps3STrYmpYk4ycckwQuC65/t6h/ZzkqSnNblKwvF5sJ63tE+l2rs=@vger.kernel.org X-Gm-Message-State: AOJu0YwUqZ8fgNdintNU6neDrM48RL86AhlZ9cG3OdqZYxZG3fIYUPW6 RRoedpbcaF4JWhH/O+RBjC5fQQwVc+gicxLdOM/q6fbc1S/wdvPjfcDuvhOhWYiX4BiLXOJh6Dy OddlGIw== X-Gm-Gg: ASbGncu4SjWjaaP0daX0/KxCUgf+dyJ4RmbBaRttTnSfA9GHgyISwsjYYYJuh1OjYgO XTCv0yt78nHsSwSeSL2rWr/G1rFATyRyuMVd2NT/WflhETpH6k7f2UnTFBFdyTUWyeolQ3fisua kFB5zGjGUI+qSMO/t7kBzuA5Jyl299s5Rc0abUWuZCMl4EDlCKSi5KCgxy3MgPLuJnrKRSuueoH EeZ8AU/nFCKzI6+4y5/DemgmN9wOvUAzVnrlZlgo2P2FfS1QxZrZ08ROp+Z9IpyRuhEguFP6BDi AIKs9/+ZKrpBXPC53zbzy2HJ4E2P/glUM8+bCBKcS8Nwa7y+P/dLeZ13B5t9N+4yGe7XeVvkGTa v X-Google-Smtp-Source: AGHT+IF5uQ2yTshrsDrGp62So7nEjMJNwK5T0pG9RVDW3pCpQP0pC5/YcQGWJV4LHQkA8pXUbJCnBg== X-Received: by 2002:a05:600c:4684:b0:43c:eec7:eabb with SMTP id 5b1f17b1804b1-43d509eccf1mr17666555e9.8.1742546829899; Fri, 21 Mar 2025 01:47:09 -0700 (PDT) Received: from [192.168.0.205] (78-154-15-142.ip.btc-net.bg. [78.154.15.142]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3997f9a3f76sm1794946f8f.37.2025.03.21.01.47.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Mar 2025 01:47:09 -0700 (PDT) Message-ID: <5512ee47-37ea-41b0-86b6-efdb4a2e10c4@blackwall.org> Date: Fri, 21 Mar 2025 10:47:08 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch net-next 0/3] Add support for mdb offload failure notification To: Joseph Huang , Joseph Huang , netdev@vger.kernel.org Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Roopa Prabhu , Simon Horman , linux-kernel@vger.kernel.org, bridge@lists.linux.dev References: <20250318224255.143683-1-Joseph.Huang@garmin.com> <039a0673-6254-45a0-b511-69d2a15aa96d@blackwall.org> <52b437bc-3f0e-4a5e-ae18-aea6576eb1ad@gmail.com> Content-Language: en-US From: Nikolay Aleksandrov In-Reply-To: <52b437bc-3f0e-4a5e-ae18-aea6576eb1ad@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/20/25 23:14, Joseph Huang wrote: > On 3/20/2025 2:17 AM, Nikolay Aleksandrov wrote: >> On 3/19/25 00:42, Joseph Huang wrote: >>> Currently the bridge does not provide real-time feedback to user space >>> on whether or not an attempt to offload an mdb entry was successful. >>> >>> This patch set adds support to notify user space about successful and >>> failed offload attempts, and the behavior is controlled by a new knob >>> mdb_notify_on_flag_change: >>> >>> 0 - the bridge will not notify user space about MDB flag change >>> 1 - the bridge will notify user space about flag change if either >>>      MDB_PG_FLAGS_OFFLOAD or MDB_PG_FLAGS_OFFLOAD_FAILED has changed >>> 2 - the bridge will notify user space about flag change only if >>>      MDB_PG_FLAGS_OFFLOAD_FAILED has changed >>> >>> The default value is 0. >>> >>> A break-down of the patches in the series: >>> >>> Patch 1 adds offload failed flag to indicate that the offload attempt >>> has failed. The flag is reflected in netlink mdb entry flags. >>> >>> Patch 2 adds the knob mdb_notify_on_flag_change, and notify user space >>> accordingly in br_switchdev_mdb_complete() when the result is known. >>> >>> Patch 3 adds netlink interface to manipulate mdb_notify_on_flag_change >>> knob. >>> >>> This patch set was inspired by the patch series "Add support for route >>> offload failure notifications" discussed here: >>> https://lore.kernel.org/all/20210207082258.3872086-1-idosch@idosch.org/ >>> >>> Joseph Huang (3): >>>    net: bridge: mcast: Add offload failed mdb flag >>>    net: bridge: mcast: Notify on offload flag change >>>    net: bridge: Add notify on flag change netlink i/f >>> >>>   include/uapi/linux/if_bridge.h |  9 +++++---- >>>   include/uapi/linux/if_link.h   | 14 ++++++++++++++ >>>   net/bridge/br_mdb.c            | 30 +++++++++++++++++++++++++----- >>>   net/bridge/br_multicast.c      | 25 +++++++++++++++++++++++++ >>>   net/bridge/br_netlink.c        | 21 +++++++++++++++++++++ >>>   net/bridge/br_private.h        | 26 +++++++++++++++++++++----- >>>   net/bridge/br_switchdev.c      | 31 ++++++++++++++++++++++++++----- >>>   7 files changed, 137 insertions(+), 19 deletions(-) >>> >> >> Hi, >> Could you please share more about the motivation - why do you need this and >> what will be using it? > > Hi Nik, > > The API for a user space application to join a multicast group is write-only (and really best-efforts only), meaning that after an application calls setsockopt(), the application has no way to know whether the operation actually succeeded or not. Normally for soft bridges this is not an issue; however for switchdev-backed bridges, due to limited hardware resources, the failure rate is meaningfully higher. > > With this patch set, the user space application will now get a notification about a failed attempt to join a multicast group. The user space application can then have the opportunity to mitigate the failure [1][2]. > Thanks for the pointers. >> Also why do you need an option with 3 different modes >> instead of just an on/off switch for these notifications? >> >> Thanks, >>   Nik >> > > Some user space application might be interested in both successful and failed offload attempts (for example the application might want to keep an mdb database which is perfectly in sync with the hardware), while some other user space application might only be interested in failed attempts (so that it can retry the operation or choose a different group for example). > > This knob is modeled after fib_notify_on_flag_change knob on route offload failure notification (see https://lore.kernel.org/all/20210207082258.3872086-4-idosch@idosch.org/). The rationale is that "Separate value (read: 2) is added for such notifications because there are less of them, so they do not impact performance and some users will find them more important." > > Thanks, > Joseph > Can we please not add features that don't have actual users? It seems you're interested in failed attempts, so you can just add a bridge boolopt on/off switch to notify about those events, if anyone becomes interested in all then we can extend it. Also it can have a more specific name like mdb_offload_fail_notification instead, saying that we notify on mdb flags change is misleading because there are more flags which can change. Also please drop all of the switchdev ifdefs and just always have this option available it will actually be used only with switchdev enabled so setting it in other cases is a noop, these flags will never be seen anyway. Cheers, Nik