Hello Andy, On Fri, Oct 25, 2019 at 6:46 AM Andy Lutomirski <l...@kernel.org> 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
