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=-7.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 B49B7C0650E for ; Wed, 3 Jul 2019 08:17:18 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 58958218A4 for ; Wed, 3 Jul 2019 08:17:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 58958218A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F05AB1D9E; Wed, 3 Jul 2019 10:17:16 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 0F8803DC for ; Wed, 3 Jul 2019 10:17:15 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2019 01:17:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,446,1557212400"; d="scan'208";a="169054110" Received: from npg-dpdk-virtio-tbie-2.sh.intel.com (HELO ___) ([10.67.104.151]) by orsmga006.jf.intel.com with ESMTP; 03 Jul 2019 01:17:13 -0700 Date: Wed, 3 Jul 2019 16:15:50 +0800 From: Tiwei Bie To: David Marchand Cc: dev , "Burakov, Anatoly" Message-ID: <20190703081550.GA25721@___> References: <20190703054508.22824-1-tiwei.bie@intel.com> <20190703073314.GA18868@___> <20190703075657.GA20458@___> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jul 03, 2019 at 10:01:44AM +0200, David Marchand wrote: > On Wed, Jul 3, 2019 at 9:58 AM Tiwei Bie wrote: > > On Wed, Jul 03, 2019 at 09:36:26AM +0200, David Marchand wrote: > > On Wed, Jul 3, 2019 at 9:35 AM Tiwei Bie wrote: > > > > Hi David, > > > > On Wed, Jul 03, 2019 at 09:02:59AM +0200, David Marchand wrote: > > > Hello, > > > > > > On Wed, Jul 3, 2019 at 7:47 AM Tiwei Bie > wrote: > > > > > > The value 40 used in VFIO_GET_REGION_ADDR() is a private value > > > (VFIO_PCI_OFFSET_SHIFT) defined in Linux kernel source [1]. It > > > is not part of VFIO API, and we should not depend on it. > > > > > > [1] https://github.com/torvalds/linux/blob/6fbc7275c7a9/drivers > /vfio/ > > pci/ > > > vfio_pci_private.h#L19 > > > > > > > > > > > > I did not follow linux kernel changes, is there something that > would > > change > > > this offset? > > > It looks like a cleanup (did not look into the details yet), do we > need > > this > > > now? > > > > In VFIO/mdev [1], the offset can be something different. It depends > > on the parent device. It's not just a cleanup. It's a preparation > > for the mdev support in DPDK. > > > > [1] https://github.com/torvalds/linux/blob/master/Documentation/ > > vfio-mediated-device.txt > > > > > > > > Ok, thanks. > > So we can wait for mdev to be ready before working on this. > > What do you mean by "mdev to be ready"? RFC ready? I don't see > anything blocking the discussion on this now. > > PS. I already sent a RFC series of the mdev support in DPDK > to the mailing list 3 month ago. > > > If you need it and the mdev support has been posted already, why not send a n+1 > patchset with this patch in it? > > This patch alone looked odd to me. That series was using the old API which assumes the shift is 40 which may not work in some cases. And this patch is to fix the API. I think this patch is actually trying to fix a relatively independent issue -- i.e. switching to using the proper VFIO API to get the region offsets instead of depending on kernel code's internal value. > I want to understand if this is a fix we need now or something that can wait. > We have a really large backlog. I guess that's why I didn't get a lot of responses in that RFC series. :) Thanks, Tiwei > > > -- > David Marchand