lkml.org 
[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] nvme-core: Fix subsystem instance mismatches


    On 2019-09-03 10:46 a.m., Keith Busch wrote:
    > On Tue, Sep 03, 2019 at 10:08:01AM -0600, Logan Gunthorpe wrote:
    >> On 2019-08-31 9:29 a.m., Keith Busch wrote:
    >>> On Fri, Aug 30, 2019 at 06:01:39PM -0600, Logan Gunthorpe wrote:
    >>>> To fix this, assign the subsystem's instance based on the instance
    >>>> number of the controller's instance that first created it. There should
    >>>> always be fewer subsystems than controllers so the should not be a need
    >>>> to create extra subsystems that overlap existing controllers.
    >>>
    >>> The subsystem's lifetime is not tied to the controller's. When the
    >>> controller is removed and releases its instance, the next controller
    >>> to take that available instance will create naming collisions with the
    >>> subsystem still using it.
    >>>
    >>
    >> Hmm, yes, ok.
    >>
    >> So perhaps we can just make the subsystem prefer the ctrl's instance
    >> when allocating the ID? Then at least, in the common case, the
    >> controller numbers will match the subsystem numbers. Only when there's
    >> random hot-plugs would the numbers get out of sync.
    >
    > I really don't know about a patch that works only on static
    > configurations. Connects and disconnects do happen on live systems,
    > so the numerals will inevitably get out of sync.

    Well this depends on how big a problem we think the number mismatch is.
    Right now it's pretty annoying because numbers aren't matching for
    non-CMIC controllers in simple setups on boot. I think having a small
    patch that makes it more consistent for the static would be worth it and
    if CMIC controllers with significant hot-plug events have mismatches
    that seems more understandable to me.

    > Could we possibly make /dev/nvmeX be a subsystem handle without causing
    > trouble for anyone? This would essentially be the same thing as today
    > for non-CMIC controllers with a device-per-controller and only affects
    > the CMIC ones.

    Well then we'd have to be able to do everything that's possible with a
    controller via the subsystem and it would have to multiplex all admin
    commands for CMIC ones, etc to a sensible controller. This might make
    sense in the long term but it sounds like a larger project than I have
    time to take on.

    Logan

    \
     
     \ /
      Last update: 2019-09-03 20:14    [W:5.076 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site