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 2E9C5C43381 for ; Fri, 15 Feb 2019 22:32:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8565222D9 for ; Fri, 15 Feb 2019 22:32:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="GD0Tl3XW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391286AbfBOWcY (ORCPT ); Fri, 15 Feb 2019 17:32:24 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:46761 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390420AbfBOWcX (ORCPT ); Fri, 15 Feb 2019 17:32:23 -0500 Received: by mail-pl1-f195.google.com with SMTP id o6so5613136pls.13 for ; Fri, 15 Feb 2019 14:32:23 -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=hApAdnTtwvyFU8i4Oc8prSQR0gE4IH1ZlXZo94pntbU=; b=GD0Tl3XWc/jV/LrMtnLRKd/36FiHQrfIU2DdS/Un/WsApOKoYFRVQavgcBsTwrvBDM pPXIx98XzxEBkaERQRhKQ4GT0ownB2Xr8t+BZL+jRuvr5fZKYiRW6V8+InCs13mZpaE3 Ry+XwIKlQuxHuYaR5ulztopwJMY/z+gLjdiFEnz9qWBLzltXY73EhtXxd0nC/T5kMG8z gtSvxi75x+FNzunKFmf1f+CiwOmhaBG/OwQgDE7/qqZ2+eJcai8Uo/ZU/lZ8jxElbPWe 2U9LXgE6D7vX3KglMEGrmetaxrBzRi6/wzWrB1v9fOuS+wh/3gGRKsuQHRhoQxKiwepb zcpw== 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=hApAdnTtwvyFU8i4Oc8prSQR0gE4IH1ZlXZo94pntbU=; b=MkMOsE9WH1zAuu8YrrLAGXfcQwNmAF1z9Httvfpx1dJSLYggvimwuDeYd+NsAFLOjf EtI/qTWPaEgQbaSwA/V7nOLq0+/QtjRN0uFPZxwY8lVR0Mj6UxZGOLpaUyZqbmZVq6h/ VFSiOdAdbdW2gXLIhSruTQo1ztFIQR4BegKQ7vePjsUlJsbrmoGP8K/wlW4fM53AZVnC s1n6jvxFnciQEZeZ9kEh+xjdGpJ0zfOVi3eU0Rfzg9yGw0Dr93KHE+m03RNBaTi45PMy qMgaq9Z27OI/YOgIgbd8JElvGdZq8UARQCXTuOL9eyuyXxB9xTsCM1jdSGxFr7iKitEo UQPA== X-Gm-Message-State: AHQUAuaf+YG9v13ZO0YFSkHWOkzF1SDxJzvPgDQQgYN586FxM+83a+Po WCfLwqJdj4FmleMgdgj1qvfbJg== X-Google-Smtp-Source: AHgI3Ibi5SXCHrSaR8MYk2D90ftZ1YsCBrq/I4O//m3WTBs8lIN8Cp8YEPqArF1ojYe9NLKjH6hWww== X-Received: by 2002:a17:902:6948:: with SMTP id k8mr12402728plt.2.1550269943130; Fri, 15 Feb 2019 14:32:23 -0800 (PST) Received: from ziepe.ca (S010614cc2056d97f.ed.shawcable.net. [174.3.196.123]) by smtp.gmail.com with ESMTPSA id c4sm17005075pfm.151.2019.02.15.14.32.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Feb 2019 14:32:22 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1gum1t-0006bi-Ml; Fri, 15 Feb 2019 15:32:21 -0700 Date: Fri, 15 Feb 2019 15:32:21 -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 12/19] RDMA/irdma: Implement device supported verb APIs Message-ID: <20190215223221.GC8001@ziepe.ca> References: <20190215171107.6464-1-shiraz.saleem@intel.com> <20190215171107.6464-13-shiraz.saleem@intel.com> <20190215173539.GD30706@ziepe.ca> <20190215221902.GA7092@ssaleem-MOBL4.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190215221902.GA7092@ssaleem-MOBL4.amr.corp.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 04:19:02PM -0600, Shiraz Saleem wrote: > On Fri, Feb 15, 2019 at 10:35:39AM -0700, Jason Gunthorpe wrote: > > On Fri, Feb 15, 2019 at 11:10:59AM -0600, Shiraz Saleem wrote: > > > [..] > > > > + */ > > > +int irdma_register_rdma_device(struct irdma_device *iwdev) > > > +{ > > > + int ret; > > > + struct irdma_ib_device *iwibdev; > > > + > > > + ret = irdma_init_rdma_device(iwdev); > > > + if (ret) > > > + return ret; > > > + > > > + iwibdev = iwdev->iwibdev; > > > + rdma_set_device_sysfs_group(&iwibdev->ibdev, &irdma_attr_group); > > > + if (iwdev->rf->sc_dev.hw_attrs.hw_rev == IRDMA_GEN_1) > > > + /* backward compat with old user-space libi40iw */ > > > + iwibdev->ibdev.driver_id = RDMA_DRIVER_I40IW; > > > > Really? Then what is the problem in rdma-core? > > Let me try to explain. There are some assumptions here since we dont > know the timelines for how the removal of i40iw/libi40iw works. > > In the ideal scenario, if i40iw/libi40iw can be removed at the > point of irdma/libirdma submission, then we just rename driver_id enum > RDMA_DRIVER_I40IW to RDMA_DRIVER_IRDMA. Older rdma-core which contain libi40iw > will also continue to work. > > If its a staged approach in which irdma and i40iw will exist for a while before > deprecation of i40iw (which is what is assumed here) then we need a seperate > driver id RDMA_DRIVER_IRDMA. > > X722 device registration via irdma driver (only when i40iw is disabled) uses > RDMA_DRIVER_I40IW to work with existing libi40iw. > > E810 device registration uses RDMA_DRIVER_IRDMA. libirdma uses > RDMA_DRIVER_IRDMA and really only associates with E810 devs. I don't understand why you need two driver IDs. If this driver is fully ABI compatible with I40IW user space, then just use that ID. The new X722 features should be designed to extend the ABI already defined for I40IW, just like every other driver has done for new capabilities and features. Generally since our userspace is using PCI-ID probing to match drivers, a new chip (ie X722) will not bind to an old user space until that userspace knows the new chip id and thus knows how to support the extended ABI. The userspace should use the new ABI in a way that cause an old kernel to reject it for extra safety. Jason