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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT 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 A2821C43381 for ; Fri, 15 Feb 2019 17:22:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 71B6621925 for ; Fri, 15 Feb 2019 17:22:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="NzJef6E6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728870AbfBORWf (ORCPT ); Fri, 15 Feb 2019 12:22:35 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:33454 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727661AbfBORWf (ORCPT ); Fri, 15 Feb 2019 12:22:35 -0500 Received: by mail-pl1-f195.google.com with SMTP id y10so5272880plp.0 for ; Fri, 15 Feb 2019 09:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=k6BDbOcac3LJtWiw5bgubYk7DK6J0OtjDLseAcK7UgE=; b=NzJef6E6DADxMPYor0w/gR9eR6fS/NMtuGqgBvNny+4AzVxkIo0KyLFtGtXgOjxV45 srUhwf+CnA8sLCml9qTM5TeOm/EPNlRXrToqWtz7DUC6J66S09WCSXnpz774y8NAZGYh M22/uzFkbaJIfb6YbxrUptmFO6jYZ2imJ+m8W3A5jRm5cd2mVcbqql9mKhimAwJmRLbI l89zXy0639/gmN0kkImYJD5sEFNhPvri2HDxU1gI6a9KU6VDvIT+pIPT0yPmvhzvH8Is bn8GRA55QHlL+kAcjpVIz1EvetFRxRGZWdkrMuPBH09SlepLV+NXtmTm5276VU6q35mY NxNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=k6BDbOcac3LJtWiw5bgubYk7DK6J0OtjDLseAcK7UgE=; b=k7bKW8scBl4wWuHgEr0vYRxui/QhMFKtsfcg2rrIcG/RGxQgSJtxNH3yPyDIwTKujd xVrp+s9BZ/zNEHzCnSUDuTTLiF/UbMxiFbnFwvc59I3+gP2gThIUUo2N6VUhqrNchjJS AiT47ERuL8LWVbXkXljkKF2sCi59z+R6mrZLVJ2QfCRhRvSpZ7eGh3wHBJbCmREQiJFY Vtc+d1/Aqw9XVCtXx9Cm2AYQjSpgVkso66XkpUPYUcE1AM07ttY35m7cwtCqnyIsS/Xr 6O9KliMpGkuJzK5OkQDCGsF6USN187Ni47fPVenwFERBvJxIS7qMrTumfVEDRKtMuSZc UioQ== X-Gm-Message-State: AHQUAuYTzUS/zQGjqx6b0RQE8vY4mAt1Djv0Mw/giYuToGKmI1dIyp3b kMc/MX2BBW3KQptajdFOFpvgcA== X-Google-Smtp-Source: AHgI3IYwPpt/6FE7L0pOvUzeMOxIFFQObcTtRSrkc8j0Gtx0EN6rcE4TJhCB6qaK+fu3Rc9CmRa4bg== X-Received: by 2002:a17:902:9b87:: with SMTP id y7mr11412680plp.336.1550251354968; Fri, 15 Feb 2019 09:22:34 -0800 (PST) Received: from ziepe.ca (S010614cc2056d97f.ed.shawcable.net. [174.3.196.123]) by smtp.gmail.com with ESMTPSA id t12sm16061250pgq.68.2019.02.15.09.22.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Feb 2019 09:22:34 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1guhC5-0000Il-QR; Fri, 15 Feb 2019 10:22:33 -0700 Date: Fri, 15 Feb 2019 10:22:33 -0700 From: Jason Gunthorpe To: Shiraz Saleem Cc: dledford@redhat.com, davem@davemloft.net, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, mustafa.ismail@intel.com, jeffrey.t.kirsher@intel.com Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv Message-ID: <20190215172233.GC30706@ziepe.ca> References: <20190215171107.6464-1-shiraz.saleem@intel.com> <20190215171107.6464-2-shiraz.saleem@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190215171107.6464-2-shiraz.saleem@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote: > Expose the register/unregister function pointers in the struct > i40e_netdev_priv which is accesible via the netdev_priv() interface > in the RDMA driver. On a netdev notification in the RDMA driver, > the appropriate LAN driver register/unregister functions are invoked > from the struct i40e_netdev_priv structure, Why? In later patches we get an entire device_add() based thing. Why do you need two things? The RDMA driver should bind to the thing that device_add created and from there reliably get the netdev. It should not listen to netdev notifiers for attachment. It would be excellent if you could make this more general as pretty much every single RDMA driver has some open coded (and often wrongly locked) version of this attachment process. This series is very big, so if you can see a way to make a general attachment scheme based around device_add/etc it would be a great pre-cursor series. Jason