[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f69137e3-0f60-4f73-a0ff-8e57c79675d5@redhat.com>
Date: Wed, 2 Jun 2021 16:54:26 +0800
From: Jason Wang <jasowang@...hat.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: "Tian, Kevin" <kevin.tian@...el.com>,
Lu Baolu <baolu.lu@...ux.intel.com>,
Liu Yi L <yi.l.liu@...ux.intel.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Alex Williamson (alex.williamson@...hat.com)\"\""
<alex.williamson@...hat.com>, David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC] /dev/ioasid uAPI proposal
在 2021/6/2 上午1:31, Jason Gunthorpe 写道:
> On Tue, Jun 01, 2021 at 04:47:15PM +0800, Jason Wang wrote:
>
>> We can open up to ~0U file descriptors, I don't see why we need to restrict
>> it in uAPI.
> There are significant problems with such large file descriptor
> tables. High FD numbers man things like select don't work at all
> anymore and IIRC there are more complications.
I don't see how much difference for IOASID and other type of fds. People
can choose to use poll or epoll.
And with the current proposal, (assuming there's a N:1 ioasid to
ioasid). I wonder how select can work for the specific ioasid.
Thanks
>
> A huge number of FDs for typical usages should be avoided.
>
> Jason
>
Powered by blists - more mailing lists