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 B6931A32A4 for ; Fri, 25 Oct 2019 16:46:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 803581C1C7; Fri, 25 Oct 2019 16:46:03 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by dpdk.org (Postfix) with ESMTP id 2BFA01C1A2 for ; Fri, 25 Oct 2019 16:46:02 +0200 (CEST) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 28FB6222BE for ; Fri, 25 Oct 2019 14:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572014761; bh=c0TJ1mKs2s0GUD/wp9Pell6cGrl9NXu0zGJCItAHu+0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hkMaQ42BA+w+biTpZI2C7IZ7RMwTnWX4vcDPoqxZHjjbESTSKSYzawpMytL0ntVGa i9vII2WX5+UXdGA3Il7bt/ALNrsVari4gzY8bHMHwSelBbrDXh+vSMDZSBKaeJefT3 4jurLclJrpH+k2u/5euOwanrgR9VvrrxOWSpfYxo= Received: by mail-wm1-f50.google.com with SMTP id p21so2436995wmg.2 for ; Fri, 25 Oct 2019 07:46:01 -0700 (PDT) X-Gm-Message-State: APjAAAUdpJ6DprRsSYZOQumUDbhJjwNuFCw5WuK0lcNQ4TTHwJJDrNY8 EO9VfFfthZnKq7hkMHV/Aqx5HPVT0aDlXMOlceaAcw== X-Google-Smtp-Source: APXvYqySxeWX+EY+FBP3Gs6CKKYYkYGhBHt4AIRaXekHZ3n0SMLgmO7fY8ACrIziZjSJN87UsKzOKeQYLu0KvRLu1xI= X-Received: by 2002:a7b:c74a:: with SMTP id w10mr3616761wmk.173.1572014759511; Fri, 25 Oct 2019 07:45:59 -0700 (PDT) MIME-Version: 1.0 References: <20191025064225.GA22917@1wt.eu> In-Reply-To: <20191025064225.GA22917@1wt.eu> From: Andy Lutomirski Date: Fri, 25 Oct 2019 07:45:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Willy Tarreau Cc: Andy Lutomirski , dev@dpdk.org, Thomas Gleixner , Peter Zijlstra , LKML Content-Type: text/plain; charset="UTF-8" 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" On Thu, Oct 24, 2019 at 11:42 PM Willy Tarreau wrote: > > 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); Hmm. I have some memory of a /dev/ioport or similar, but now I can't find it. It does seem quite reasonable. But, for uses like DPDK, /sys/.../resource0 seems like a *far* better API, since it actually uses the kernel's concept of which io range corresponds to which device instead of hoping that the mappings don't change out from under user code. And it has the added benefit that it's restricted to a single device. --Andy