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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 DB8C7C282CE for ; Wed, 13 Feb 2019 15:38:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B2EC12175B for ; Wed, 13 Feb 2019 15:38:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392379AbfBMPi5 (ORCPT ); Wed, 13 Feb 2019 10:38:57 -0500 Received: from mga14.intel.com ([192.55.52.115]:62728 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726432AbfBMPi4 (ORCPT ); Wed, 13 Feb 2019 10:38:56 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2019 07:38:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,366,1544515200"; d="asc'?scan'208";a="134001029" Received: from jtkirshe-desk1.jf.intel.com ([134.134.177.96]) by orsmga002.jf.intel.com with ESMTP; 13 Feb 2019 07:38:56 -0800 Message-ID: <8612b6c404633f930de5ceb090647ae0910644b2.camel@intel.com> Subject: Re: [RFC 03/19] net/ice: Add support for ice peer devices and drivers From: Jeff Kirsher Reply-To: jeffrey.t.kirsher@intel.com To: Jason Gunthorpe , Shiraz Saleem Cc: dledford@redhat.com, davem@davemloft.net, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, mustafa.ismail@intel.com, Anirudh Venkataramanan Date: Wed, 13 Feb 2019 07:40:15 -0800 In-Reply-To: <20190213034104.GA8751@ziepe.ca> References: <20190212214402.23284-1-shiraz.saleem@intel.com> <20190212214402.23284-4-shiraz.saleem@intel.com> <20190213034104.GA8751@ziepe.ca> Organization: Intel Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-gywrvZWrBrW6eIhRnBov" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org --=-gywrvZWrBrW6eIhRnBov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-02-12 at 20:41 -0700, Jason Gunthorpe wrote: > On Tue, Feb 12, 2019 at 03:43:46PM -0600, Shiraz Saleem wrote: > > From: Anirudh Venkataramanan > >=20 > > The E800 series of Ethernet devices has multiple hardware blocks, > > of > > which RDMA is one. The RDMA block isn't interfaced directly to PCI > > or any other bus. The RDMA driver (irdma) thus depends on the ice > > driver to provide access to the RDMA hardware block. > >=20 > > The ice driver first creates a pseudo bus and then creates and > > attaches > > a new device to the pseudo bus using device_register(). This new > > device > > is referred to as a "peer device" and the associated driver (i.e. > > irdma) > > is a "peer driver" to ice. Once the peer driver loads, it can call > > ice driver functions exposed to it via struct ice_ops. Similarly, > > ice can > > call peer driver functions exposed to it via struct ice_peer_ops. >=20 > This seems quite big for this straightforward description.. > =20 > I was going to say I like the idea of using the driver model to > connect the drivers, but if it takes so much code ... Part of the reason why the ice driver patches are much larger than the i40e patch is because currently there is zero RDMA support for our ice driver. The ice developers wanted to wait for the new RDMA interface implementation before adding the RDMA support to the ice driver. >=20 > > + /* check for reset in progress before proceeding */ > > + pf =3D pci_get_drvdata(peer_dev->pdev); > > + for (i =3D 0; i < ICE_MAX_RESET_WAIT; i++) { > > + if (!ice_is_reset_in_progress(pf->state)) > > + break; > > + msleep(100); > > + } >=20 > Use proper locking, not loops with sleeps. --=-gywrvZWrBrW6eIhRnBov Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiTyZWz+nnTrOJ1LZ5W/vlVpL7c4FAlxkOl8ACgkQ5W/vlVpL 7c6w5Q//ZO+C7Ns4jwHTBW+xJQdT3BHMtGZZTNPZh6u94wWS+1+5kBlgkVvzsWCP xMayPkqX2vjcFdsTKC5mQec2cve64wTyGIqpkFMP6LtrET16qer4zv8d6lFK0Dbu i41GkMHvahSngIqQJgTzZ8mxbZlJQllilqv3tm2DoYODsnaLgqXJn3zH+osLGr/M 5thgItsvl4zg1YVhejWBnMiT51DfErhu2Yu5PgDCLugii+n0UhGdQacutpi40N0M xiZrCzFE9cWX6t+DJlVAa1+K6Tr2CMWwDLMAnZBPgfnhHFmCEjpZXmuHkHuWmjit BR37fB0IxicMMd9jyyk+r5GpXldfW7XhPKs4PNPTthQ0jyGz1tZ/y29L1Y4ilRh6 BlJmeSFYTKPOtZaklU/N3NgstLyl3JE+cJZlC4NFSID6+X6CHyWwTpxHKyAtvFa/ 4LMzcqJy7JuPNhveKXrkGgeZCKuz2hKvODRNXmzzeQCvt+ssXFgbF3/AaQxFL+FT UsSo5i8dgzPU3j2Pih5ytN+Q3iqczBKyo4rCr0a3ktVuY5BKf9yKTJQveqq/5TXi tydqQXkT/3paSDeJXCe8Cz/45N4NdF7NaCqiVeesBauziKr4oZotVBEX1iHRj5X+ +j7ntjHAn/dlkSVwPjC0+/5XP/EEGamDCc+GmzWcBusfuU9hnY8= =AlWg -----END PGP SIGNATURE----- --=-gywrvZWrBrW6eIhRnBov--