From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 2EA4E58C5 for ; Mon, 5 Dec 2016 08:04:09 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 04 Dec 2016 23:04:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,303,1477983600"; d="scan'208";a="38979088" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga006.fm.intel.com with ESMTP; 04 Dec 2016 23:04:08 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 4 Dec 2016 23:04:08 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.96]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id 14.03.0248.002; Mon, 5 Dec 2016 15:04:06 +0800 From: "Tan, Jianfeng" To: Stephen Hemminger CC: "dev@dpdk.org" , "david.marchand@6wind.com" , "Yigit, Ferruh" Thread-Topic: [RFC] igb_uio: deprecate iomem and ioport mapping Thread-Index: AQHSA/bf/ZcZuT3Bo0mSw+jwmKNT6KD1XrwAgAQOFlA= Date: Mon, 5 Dec 2016 07:04:05 +0000 Message-ID: References: <1472696197-37614-1-git-send-email-jianfeng.tan@intel.com> <20161202154706.3676195c@xeon-e3> In-Reply-To: <20161202154706.3676195c@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] igb_uio: deprecate iomem and ioport mapping 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: , X-List-Received-Date: Mon, 05 Dec 2016 07:04:09 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Saturday, December 3, 2016 7:47 AM > To: Tan, Jianfeng > Cc: dev@dpdk.org; david.marchand@6wind.com; Yigit, Ferruh > Subject: Re: [RFC] igb_uio: deprecate iomem and ioport mapping >=20 > On Thu, 1 Sep 2016 02:16:37 +0000 > Jianfeng Tan wrote: >=20 > > Previously in igb_uio, iomem is mapped, and both ioport and io mem > > are recorded into uio framework, which is duplicated and makes the > > code too complex. > > > > For iomem, DPDK user space code never opens or reads files under > > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/maps/. Instead, > > /sys/pci/bus/devices/xxxx:xx:xx.x/resourceY are used to map device > > memory. > > > > For ioport, non-x86 platforms cannot read from files under > > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/portio/ directly, because > > non-x86 platforms need to map port region for access in user space, > > see non-x86 version pci_uio_ioport_map(). x86 platforms can use the > > the same way as uio_pci_generic. > > > > This patch deprecates iomem and ioport mapping in igb_uio kernel > > module, and adjusts the iomem implementation in both igb_uio and > > uio_pci_generic: > > - for x86 platform, get ports info from /proc/ioports; > > - for non-x86 platform, map and get ports info by pci_uio_ioport_map(= ). > > > > Note: this will affect those applications who are using files under > > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/maps/ and > > /sys/pci/bus/devices/xxxx:xx:xx.x/uio/uioY/portio/. > > > > Signed-off-by: Jianfeng Tan >=20 > What about people using older kernels with the new DPDK EAL and > vice versa?=20 There are two things planned in this proposal: (1) deprecating iomem mapping in igb_uio, which is not used in DPDK code an= yway. (2) deprecating ioport mapping in igb_uio, which has effect on ioport mappi= ng for x86 platforms. The way we use to make up is to leverage how uio_pci_= generic does, aka, based on /proc/ioports, and this proc file is available = at very early stage of Linux (Even before 2.6.32). So I don't see a problem there when running the new DPDK EAL on older kerne= ls. On the other way, running old DPDK EAL on new kernels, and using new igb_ui= o, right? Oops, this should have problem. Thank you for pointing out this. = So how about just removing iomem? And my motivation to clean igb_uio like t= his way is to fix a problem here: http://dpdk.org/dev/patchwork/patch/17495= /. > It makes sense to make igb_uio generic for non DPDK > usage, so it should probably follow the other UIO drivers. >=20 Then the problem would be backward compatibility. I might need to reconside= r this. Thank you for reviewing! Thanks, Jianfeng