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 E3A94A00BE; Wed, 30 Oct 2019 11:36:48 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE67F1BF55; Wed, 30 Oct 2019 11:36:47 +0100 (CET) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by dpdk.org (Postfix) with ESMTP id BA1C81BEBF for ; Mon, 28 Oct 2019 21:13:14 +0100 (CET) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x9SKDD4I027324; Mon, 28 Oct 2019 21:13:13 +0100 Date: Mon, 28 Oct 2019 21:13:13 +0100 From: Willy Tarreau To: Stephen Hemminger Cc: Andy Lutomirski , dev@dpdk.org, Thomas Gleixner , Peter Zijlstra , LKML Message-ID: <20191028201313.GA27316@1wt.eu> References: <20191025064225.GA22917@1wt.eu> <20191028094253.054fbf9c@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191028094253.054fbf9c@hermes.lan> User-Agent: Mutt/1.6.1 (2016-04-27) X-Mailman-Approved-At: Wed, 30 Oct 2019 11:36:46 +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 Stephen, On Mon, Oct 28, 2019 at 09:42:53AM -0700, Stephen Hemminger wrote: (...) > > 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 > > DPDK does not want to system calls. It kills performance. > With pure user mode access it can reach > 10 Million Packets/sec > with a system call per packet that drops to 1 Million Packets/sec. I know that it would cause this on the data path, but are you *really* sure that in/out calls are performed there, because these are terribly slow already ? I'd suspect that instead it's relying on read/write of memory-mapped registers and descriptors. I really suspect that I/Os are only used for configuration purposes, which is why I proposed the stuff above (otherwise I obviously agree that syscalls in the data path are performance killers). > Also, adding new system calls might help in the long term, > but users are often kernels that are at least 5 years behind > upstream. Sure but that has never been really an issue, what matters is that backwards compatibility is long enough to let old features smoothly fade away. Some people make fun of me because I still care a bit about kernel 2.4 and openssl 0.9.7 compatibility for haproxy, so yes, I am careful about backwards compatibility and smooth upgrades ;-) Willy