From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DBE90A00B8; Sun, 27 Oct 2019 23:36:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DE4BF1BEDF; Sun, 27 Oct 2019 23:36:34 +0100 (CET) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by dpdk.org (Postfix) with ESMTP id 57DE01D455 for ; Fri, 25 Oct 2019 08:42:26 +0200 (CEST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x9P6gPsq023039; Fri, 25 Oct 2019 08:42:25 +0200 Date: Fri, 25 Oct 2019 08:42:25 +0200 From: Willy Tarreau To: Andy Lutomirski Cc: dev@dpdk.org, Thomas Gleixner , Peter Zijlstra , LKML Message-ID: <20191025064225.GA22917@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Sun, 27 Oct 2019 23:36:29 +0100 Subject: Re: [dpdk-dev] Please stop using iopl() in DPDK 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" Hi Andy, On Thu, Oct 24, 2019 at 09:45:56PM -0700, Andy Lutomirski wrote: > Hi all- > > Supporting iopl() in the Linux kernel is becoming a maintainability > problem. As far as I know, DPDK is the only major modern user of > iopl(). > > After doing some research, DPDK uses direct io port access for only a > single purpose: accessing legacy virtio configuration structures. > These structures are mapped in IO space in BAR 0 on legacy virtio > devices. > > There are at least three ways you could avoid using iopl(). Here they > are in rough order of quality in my opinion: (...) I'm just wondering, why wouldn't we introduce a sys_ioport() syscall to perform I/Os in the kernel without having to play at all with iopl()/ ioperm() ? That would alleviate the need for these large port maps. Applications that use outb/inb() usually don't need extreme speeds. Each time I had to use them, it was to access a watchdog, a sensor, a fan, control a front panel LED, or read/write to NVRAM. Some userland drivers possibly don't need much more, and very likely run with privileges turned on all the time, so replacing their inb()/outb() calls would mostly be a matter of redefining them using a macro to use the syscall instead. I'd see an API more or less like this : int ioport(int op, u16 port, long val, long *ret); would take values such as INB,INW,INL to fill *, OUTB,OUTW,OUL to read from , possibly ORB,ORW,ORL to read, or with , write back and return previous value to , ANDB/W/L, XORB/W/L to do the same with and/xor, and maybe a TEST operation to just validate support at start time and replace ioperm/iopl so that subsequent calls do not need to check for errors. Applications could then replace : ioperm() with ioport(TEST,port,0,0) iopl() with ioport(TEST,0,0,0) outb() with ioport(OUTB,port,val,0) inb() with ({ char val;ioport(INB,port,0,&val);val;}) ... and so on. And then ioperm/iopl can easily be dropped. Maybe I'm overlooking something ? Willy