Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Ertman, David M" <david.m.ertman@intel.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     "davem@davemloft.net" <davem@davemloft.net>,
        "yongxin.liu@windriver.com" <yongxin.liu@windriver.com>,
        "Saleem, Shiraz" <shiraz.saleem@intel.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>
Subject: RE: [PATCH net] ice: Correctly deal with PFs that do not support RDMA
Thread-Topic: [PATCH net] ice: Correctly deal with PFs that do not support
 RDMA
Thread-Index: AQHXpcR4A6Zxkkm/5kK6iDoPUIa3IqucQNUQ
Date:   Thu, 9 Sep 2021 22:02:13 +0000
Message-ID: <SJ0PR11MB497570D18E7F08AC4E4186F2DDD59@SJ0PR11MB4975.namprd11.prod.outlook.com>
References: <20210909085612.570229-1-david.m.ertman@intel.com>
 <20210909144833.2ca0069d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
In-Reply-To: <20210909144833.2ca0069d@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.200.16
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?IdJtKzHstfDvnTMuMXFMcX6dEzemCvkyAP83PIO+4qoBfvmk5AbY7Jx05OSM?=
 =?us-ascii?Q?tk0we+ITMaRfUycE0acfecc9pAu8Sh1uXITNKdWARFhtcMzDh3Sqm1ILNN82?=
 =?us-ascii?Q?MMUhBRFbpTT5EP5p0eRYkK/7pn7fk9Rb5IT9CoDYSqDG+kK3oOXWsulzVNa8?=
 =?us-ascii?Q?cFkcmPxxumspOJwQZRDv2kBidHRb7cHMJqdEffJ7/uWuiu+poD08/SgMlTlE?=
 =?us-ascii?Q?v6jLjZGWRp+RtZTVq1kBdnYZiUsX/ktZi/NgDe3HbBufmt2bxpMJnMabJ8P9?=
 =?us-ascii?Q?o7EDRzdGYkrBA6/aTzcSzjiq0M5Yn7SMLQFBhbEmnqQRdEyymThZivmglM8U?=
 =?us-ascii?Q?vP2Y0o3S25iQs2MwQO8PtuhrzxZSRxRlgPBBZVGUaxPejgTg9etw03LAobk9?=
 =?us-ascii?Q?+6CLjwhN79iTryG42GNFFpsL+B72Olp1bLx8cHhAbfQRG+PxhpjBQo6ba4bz?=
 =?us-ascii?Q?KnZWKtMlaZ4XfklS6twA6KXMXNztH+GA9AN3FG+zELrJa528sOhguZCslzDn?=
 =?us-ascii?Q?Rl1p3PzEt8RRKLAOCBO2PFbQHSCfWiwcfeoPcfZDQkN2m0amyC/wVdY5E16c?=
 =?us-ascii?Q?iKoN1pYzWPj0A3nI+nhrTBnYc4IoLPSEVv59dzfEtbL4NbbY4HUwXdAlGlLp?=
 =?us-ascii?Q?jSl+FTY6hnvOj0uvRogbtQkXgPz1xyHzz5dWiS/ewSPtNsPXIGUuJ+4wCRs7?=
 =?us-ascii?Q?N3vwAT/MKWsYRIEJYDgob0zorP7NPx8+WMu9FuzNf3LoQni6rJ+L/NqUBwLT?=
 =?us-ascii?Q?vs+tR42EI0JcdoMGb5Rs1uPkRTxb7hzXzPn3ArqcfvtLIwmPQ/0VWXAC7xTA?=
 =?us-ascii?Q?XTeTT2LUQjgIbLRGz7TnMM10bDIkseScDGgcBSsl5ef/Fq7EMx19QLjZNrlE?=
 =?us-ascii?Q?oUVxQ8aVsB0Nq2DBMy86+hVxCBR1V1nLgm11aQUZnjfhuLINKGLjLL9oMvBH?=
 =?us-ascii?Q?UJoWArEACkponpT7y5RCeH1CJGGxaaTwFm1mPV53ecyA3dDDwHVI1cAwprTA?=
 =?us-ascii?Q?qqYWllnHg3zOBIvZT2rwKU2VUxK+TL7pFsiTXD3Sl+Xoh41KJqG1HX8WwuLg?=
 =?us-ascii?Q?aAvz5T8aMDRoQVWA5Uj4fjc9dv5sm0rMPqY+YoHPyEBU/RCIyiYau7Jo2WMl?=
 =?us-ascii?Q?sEZ9zw13TKiEU1RQTUm1tz5cd7gqsJ75HEEIHgjXhTWGtnb0FceLwJAkqzdh?=
 =?us-ascii?Q?ZfWfIVKhUFK90P1MwkEvJv64bvW39Y9G7w4HPoeZe/VaYytOjgzGoFeP+opJ?=
 =?us-ascii?Q?U3nYuJHc/sduPNoLQbm/ZqNxrHDA07fXXnaTYxffgJfvpeeYFvVxOjIQL7s3?=
 =?us-ascii?Q?yFk=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4975.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eaf909d4-1003-43d8-f433-08d973dd7b0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2021 22:02:13.7553
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yzOZ4aeSyhCc02av295weiZeDikuCwoHihAd5xS0oO7ejkS7i4QN5bRmccalXoi4I4XUviLmr/TPjZrX61escrTA2N17mdwni8we/rTiKUg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4194
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Thursday, September 9, 2021 2:49 PM
> To: Ertman, David M <david.m.ertman@intel.com>
> Cc: davem@davemloft.net; yongxin.liu@windriver.com; Saleem, Shiraz
> <shiraz.saleem@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Brandeburg, Jesse <jesse.brandeburg@intel.com>;
> intel-wired-lan@lists.osuosl.org
> Subject: Re: [PATCH net] ice: Correctly deal with PFs that do not support
> RDMA
>=20
> On Thu,  9 Sep 2021 01:56:12 -0700 Dave Ertman wrote:
> > There are two cases where the current PF does not support RDMA
> > functionality.  The first is if the NVM loaded on the device is set
> > to not support RDMA (common_caps.rdma is false).  The second is if
> > the kernel bonding driver has included the current PF in an active
> > link aggregate.
> >
> > When the driver has determined that this PF does not support RDMA, then
> > auxiliary devices should not be created on the auxiliary bus.  Without
> > a device on the auxiliary bus, even if the irdma driver is present, the=
re
> > will be no RDMA activity attempted on this PF.
> >
> > Currently, in the reset flow, an attempt to create auxiliary devices is
> > performed without regard to the ability of the PF.  There needs to be a
> > check in ice_aux_plug_dev (as the central point that creates auxiliary
> > devices) to see if the PF is in a state to support the functionality.
> >
> > When disabling and re-enabling RDMA due to the inclusion/removal of the
> PF
> > in a link aggregate, we also need to set/clear the bit which controls
> > auxiliary device creation so that a reset recovery in a link aggregate
> > situation doesn't try to create auxiliary devices when it shouldn't.
> >
> > Fixes: f9f5301e7e2d ("ice: Register auxiliary device to provide RDMA")
> > Reported-by: Yongxin Liu <yongxin.liu@windriver.com>
> > Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
>=20
> Why CC lkml but not CC RDMA or Leon?

Oversight on my part - thought I had cut-n-pasted all of the address=20
in my git send-email command.  Will send again and correct issue