lkml.org 
[lkml]   [2021]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] /dev/ioasid uAPI proposal
    From
    Date

    在 2021/6/2 上午1:29, Jason Gunthorpe 写道:
    > On Tue, Jun 01, 2021 at 02:07:05PM +0800, Jason Wang wrote:
    >
    >> For the case of 1M, I would like to know what's the use case for a single
    >> process to handle 1M+ address spaces?
    > For some scenarios every guest PASID will require a IOASID ID # so
    > there is a large enough demand that FDs alone are not a good fit.
    >
    > Further there are global container wide properties that are hard to
    > carry over to a multi-FD model, like the attachment of devices to the
    > container at the startup.


    So if we implement per fd model. The global "container" properties could
    be done via the parent fd. E.g attaching the parent to the device at the
    startup.


    >
    >>> So this RFC treats fd as a container of address spaces which is each
    >>> tagged by an IOASID.
    >> If the container and address space is 1:1 then the container seems useless.
    > The examples at the bottom of the document show multiple IOASIDs in
    > the container for a parent/child type relationship


    This can also be done per fd? A fd parent can have multiple fd childs.

    Thanks


    >
    > Jason
    >

    \
     
     \ /
      Last update: 2021-06-02 10:59    [W:4.884 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site