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 1817AA32A2 for ; Fri, 25 Oct 2019 09:22:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BCA291E875; Fri, 25 Oct 2019 09:22:40 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0A39F1E86F for ; Fri, 25 Oct 2019 09:22:39 +0200 (CEST) Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5625385543 for ; Fri, 25 Oct 2019 07:22:38 +0000 (UTC) Received: by mail-vk1-f198.google.com with SMTP id i20so416683vkk.21 for ; Fri, 25 Oct 2019 00:22:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yGx12ZWXQdTQ4DA+CRwxn3Wgl8jiBGsaV9L7QOn8O5g=; b=FLPU769nKJrXweCFVM7NNRMImpbsh0rM4ougU340pktPS9iRUSHsVx1bDH8SSj35q5 TJqF984+vG2lhQopuczVRgkDifnDCsqxh+7fw4VyIlK1HK/yxZJabRRJbVmvrBxJYteV JYWpyrpn0KfXq0vZEDI1TfIivLA248xGzEqnkSdrINLkru3gYKLGtDms0p4cONTIpdZb 5tyXbmKN03mkRnOg0PLQPuwQA/9IfRtej/7xhYWQOhFpCXrvu4RMR2jjyYOcXHMP0OV2 coEJtrqOms/kXBQLbsTQf45NxjVPvBaiJhPmgrDxfxdJs26+h2yvaroT7UohDoAwhQbE rkwg== X-Gm-Message-State: APjAAAVM8jjB3p8XdAw807ZrYs92g8Ld9/wONlY/U7Ofh6W+aQiETrJI veHO8dav1o0pOM0jejIXhRwTisyYAMKFpZ3QqFI6UusYq/dXROmpbDdttr1O5mnxO3I9IbQoyCk CNMegv0/q1l+1G6Y0tw8= X-Received: by 2002:a67:e88b:: with SMTP id x11mr1105260vsn.180.1571988157506; Fri, 25 Oct 2019 00:22:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyjBybREs5A0r9G8gktZgx1qhMgOORE/7AJ6wX1rGtnapuOznF9GpGMK5EoSbv0WQ1Dt/wwosoSVba22N3EeVU= X-Received: by 2002:a67:e88b:: with SMTP id x11mr1105250vsn.180.1571988157178; Fri, 25 Oct 2019 00:22:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Marchand Date: Fri, 25 Oct 2019 09:22:26 +0200 Message-ID: To: Andy Lutomirski Cc: dev , Thomas Gleixner , Peter Zijlstra , LKML , Maxime Coquelin , Tiwei Bie , Thomas Monjalon 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" Hello Andy, On Fri, Oct 25, 2019 at 6:46 AM Andy Lutomirski wrote: > 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(). Thanks for reaching out. Copying our virtio maintainers (Maxime and Tiwei), since they are the first impacted by such a change. > 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: > > 1. Change pci_uio_ioport_read() and pci_uio_ioport_write() to use > read() and write() on resource0 in sysfs. > > 2. Use the alternative access mechanism in the virtio legacy spec: > there is a way to access all of these structures via configuration > space. > > 3. Use ioperm() instead of iopl(). And you come with potential solutions, thanks :-) We need to look at them and evaluate what is best from our point of view. See how it impacts our ABI too (we decided on a freeze until 20.11). > We are considering changes to the kernel that will potentially harm > the performance of any program that uses iopl(3) -- in particular, > context switches will become more expensive, and the scheduler might > need to explicitly penalize such programs to ensure fairness. Using > ioperm() already hurts performance, and the proposed changes to iopl() > will make it even worse. Alternatively, the kernel could drop iopl() > support entirely. I will certainly make a change to allow > distributions to remove iopl() support entirely from their kernels, > and I expect that distributions will do this. > > Please fix DPDK. Unfortunately, we are currently closing our rc1 for the 19.11 release. Not sure who is available, but I suppose we can work on this subject in the 20.02 release timeframe. Thanks. -- David Marchand