lkml.org 
[lkml]   [2015]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t

    * Dan Williams <dan.j.williams@intel.com> wrote:

    > > That looks like a layering violation and a mistake to me. If we
    > > want to do direct (sector_t -> sector_t) IO, with no serialization
    > > worries, it should have its own (simple) API - which things like
    > > hierarchical RAID or RDMA APIs could use.
    >
    > I'm wrapped around the idea that __pfn_t *is* that simple api for
    > the tiered storage driver use case. [...]

    I agree. (see my previous mail)

    > [...] For RDMA I think we need struct page because I assume that
    > would be coordinated through a filesystem an truncate() is back in
    > play.

    So I don't think RDMA is necessarily special, it's just a weirdly
    programmed DMA request:

    - If it is used internally by an exclusively managed complex storage
    driver, then it can use low level block APIs and pfn_t.

    - If RDMA is exposed all the way to user-space (do we have such
    APIs?), allowing users to initiate RDMA IO into user buffers, then
    (the user visible) buffer needs struct page backing. (which in turn
    will then at some lower level convert to pfns.)

    That's true for both regular RAM pages and mmap()-ed persistent RAM
    pages as well.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2015-05-07 20:01    [W:2.465 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site