From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (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 BC3263C73FD for ; Fri, 13 Mar 2026 16:59:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773421172; cv=none; b=fBWKQrPzNfslTQtHPCUGuR/y9DoMWxaEYfcVeRfL1ViQ3M5ywHBo94wA+K9fXA7BkhAgA4c/m+zWKxMInJlJmG7oajQI5bmmUB4zXek8gLETCcpIuuS2BPJvuQaRISUtOJHKm5JZAG9TUVIvSlFrIcG8AQ5kOIhrXd4UCsVrmA4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773421172; c=relaxed/simple; bh=ZtCcl/BQGcxN/KUZGbuRltnqiIZdE1BNslevOQGWgSs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CWyZZA6H1K6dApRRB88PLQ+9MsUmGH6S3ImaZiV+r0hr3pVtjRY8C377hb298JjuJXZfB2i7TreNRrwk6Bq4TJJKPsfol3F9/42cqgLGX66tFgxA/scX11ROlb7yiKylwEvIs8Z4Q8F2ec5UTnzrWsRFFQFVEy5/Rg6BszwKcqY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=PehQkiI4; arc=none smtp.client-ip=209.85.219.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="PehQkiI4" Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-899e87b04d8so24043156d6.3 for ; Fri, 13 Mar 2026 09:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1773421170; x=1774025970; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=23vNKRuSFnFOzf5hO6ZBoQlegCCAZzuo2j5iFmnbc5A=; b=PehQkiI4M6Jd47dJdNiK4ZLpmpbRRoOAWmvfoehAtix64kyfPIt9T7FFN0IRc+ycUs n4vQbLjq+2guHsmefuI5RlDxSwngphyDF95e4Mt7gI3j2s+1ZffqdHV1xk1EMwHfbyAA qznKFepOXmTz82YsZVkgQgTMP9ljWjFXH4W3pFYk8o8TSJfQ5SMALHY28jOJp9fM9rx7 2ukcl66e05ePXuU+frU8gUxrJWbXkrZx7lMkCQgl0LwWMzFmHsHUivqZD26nwuOsO6wR 1T1V72GHAty9EA54Il2rQE1OP/m/+Y4Q9PhepBm6eU7DI6NIF8HlbT7aeXRRiwYsFivm UH5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773421170; x=1774025970; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=23vNKRuSFnFOzf5hO6ZBoQlegCCAZzuo2j5iFmnbc5A=; b=ISrRAo7jmW4JzcYgmhVBdV8s1PYe25NoaNORjMp8hgUMZyH25941E7tme1IJuW86EU Y909Wgv260VpG3E7PKw49X6HYKqQkQq4/HtcCBE07gfboeyz6V4kHCo5aiL4J/PtYVtb nSAf916KI89RjIhT9NnMCVsLA8vUmnNy8BOWVx45mnqbdhQicyZisQWMTZ6Ss2HHxJkb jns1b8GhnpvaKZaeqj02qPv+PItjtUfKUry3GgDsCahTfd1uAIGZjN6Auu3wqUrrt9Wi BcflSqcwsp3SiSNBAOod9t5YGrEggJvU3VLeRt7X7lSMYs9jywtiovFvgsH7v7t/6KrK Ulwg== X-Forwarded-Encrypted: i=1; AJvYcCX4D4c3+zOjMbk6BBbZoSRRxODMZANBbQImta4kxwOUK+8msGHMcvYce2Pt/IDv2GuqzeQYcPyWm317lxU=@vger.kernel.org X-Gm-Message-State: AOJu0YwfXbHTtrrGlErt8YQ+Fr4MgDBB6hoZqcfkkhpLSPOE6if/sb6H +I6pFO3CCOv5kFUoPaT7qXhVxuPu32QhfNF0jcYIRf7ZjuukHPlFqb3XDkEoK85hj5Q= X-Gm-Gg: ATEYQzwkl6R8/QBR86W3AU6MFVOnQx6kVhKGnrlPW7yHCqKEh4Z/QLrk76qJ1ZF8Bbb T6PbNpggTPdwMfAcVx5m8Z0nXWhzCfnqqa/hIVHE2tPqVT9g+QRK759OKkf752NjCi2Lszzt7ve 5F7HF8QYLkfSHEwsHz8bemGvy1h3HGYI54jw9v2PKagtsK9p2wh/yMBNEeNzpBaP5P3yfVf0Nxs GMvVAmkY+yQloe6sqi7g3wcayawvslYQFQh5aS1LCYOiZHjLCQ4cxLpose2oplHUm/32Hzu+dto VPqJTodhuM/dqBED1H2HBO0tKaNFgmszHbme+DzNzuuhAF4yStbySQNbKNl3qauu6XGq6mFi1lI XAqcz2x1ycxgSXxFFXsEB6u6sV0I/YNogEprwenrxnpoX2x4KLoDtnNNAiW8khATDZo+P/RCb6u Z1+gV1eRkNJ5hfl17FrBTFo3kELxUQOjye1H5Ka9cJIgjYWJHnTaHxgm2VcInnpLn9SXv1IjMct bXF9Bj+ X-Received: by 2002:a05:6214:c2d:b0:89a:622e:d334 with SMTP id 6a1803df08f44-89a81fe1ef3mr64802856d6.48.1773421169725; Fri, 13 Mar 2026 09:59:29 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89a65beb4besm60515486d6.15.2026.03.13.09.59.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2026 09:59:29 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1w15rE-00000007Jg3-2Wt2; Fri, 13 Mar 2026 13:59:28 -0300 Date: Fri, 13 Mar 2026 13:59:28 -0300 From: Jason Gunthorpe To: Leon Romanovsky Cc: Long Li , Konstantin Taranov , Jakub Kicinski , "David S . Miller" , Paolo Abeni , Eric Dumazet , Andrew Lunn , Haiyang Zhang , "K . Y . Srinivasan" , Wei Liu , Dexuan Cui , Simon Horman , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH rdma-next 0/8] RDMA/mana_ib: Handle service reset for RDMA resources Message-ID: <20260313165928.GH1704121@ziepe.ca> References: <20260307014723.556523-1-longli@microsoft.com> <20260307173814.GN12611@unreal> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260307173814.GN12611@unreal> On Sat, Mar 07, 2026 at 07:38:14PM +0200, Leon Romanovsky wrote: > On Fri, Mar 06, 2026 at 05:47:14PM -0800, Long Li wrote: > > When the MANA hardware undergoes a service reset, the ETH auxiliary device > > (mana.eth) used by DPDK persists across the reset cycle — it is not removed > > and re-added like RC/UD/GSI QPs. This means userspace RDMA consumers such > > as DPDK have no way of knowing that firmware handles for their PD, CQ, WQ, > > QP and MR resources have become stale. > > NAK to any of this. > > In case of hardware reset, mana_ib AUX device needs to be destroyed and > recreated later. Yeah, that is our general model for any serious RAS event where the driver's view of resources becomes out of sync with the HW. You have tear down the ib_device by removing the aux and then bring back a new one. There is an IB_EVENT_DEVICE_FATAL, but the purpose of that event is to tell userspace to close and re-open their uverbs FD. We don't have a model where a uverbs FD in userspace can continue to work after the device has a catasrophic RAS event. There may be room to have a model where the ib device doesn't fully unplug/replug so it retains its name and things, but that is core code not driver stuff. Jason