From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Yigal Korman <yigal@plexistor.com>, Boaz Harrosh <boaz@plexistor.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
lsf-pc@lists.linux-foundation.org,
Dan Williams <dan.j.williams@intel.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Linux RDMA Mailing List <linux-rdma@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>, Ric Wheeler <rwheeler@redhat.com>
Subject: Re: [LSF/MM TOPIC/ATTEND] RDMA passive target
Date: Mon, 1 Feb 2016 12:36:06 +0200 [thread overview]
Message-ID: <56AF3516.8000909@dev.mellanox.co.il> (raw)
In-Reply-To: <CACTTzNaOChdWN2eS9_kzv6HO_LVib-JVdkmeUn0LDe2eKxPEgA@mail.gmail.com>
>>>> The almost is because:
>>>> 1. If the target is over a /dev/pmemX then all is fine we have 2M contiguous
>>>> memory blocks.
>>>> 2. If the target is over an FS, we have a proposal pending for an falloc_2M_flag
>>>> to ask the FS for a contiguous 2M allocations only. If any of the 2M allocations
>>>> fail then return ENOSPC from falloc. This way we guaranty that each 2M block can be
>>>> mapped by a single RDAM handle.
>>>
>>> Umm, you don't need the 2M to be contiguous in order to represent them
>>> as a single RDMA handle. If that was true iSER would have never worked.
>>> Or I misunderstood what you meant...
>>>
>>
>> OK I will let our RDMA guy Yigal Korman answer that, I guess you might be right.
>
> When Boaz says 'RDMA handle', he means the pair [rkey,remote_addr].
> AFAIK the remote_addr describes a continuous memory space on the target.
> So if you want to write to this 'handle' - it must be continuous.
> Please correct me if I'm wrong.
OK, this is definitely wrong. But let's defer this discussion to another
thread as it's not relevant to lsf folks...
WARNING: multiple messages have this Message-ID (diff)
From: Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
To: Yigal Korman <yigal-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>,
Boaz Harrosh <boaz-/8YdC2HfS5554TAoqtyWWQ@public.gmane.org>
Cc: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Dan Williams
<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Linux NFS Mailing List
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux RDMA Mailing List
<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
Ric Wheeler <rwheeler-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [LSF/MM TOPIC/ATTEND] RDMA passive target
Date: Mon, 1 Feb 2016 12:36:06 +0200 [thread overview]
Message-ID: <56AF3516.8000909@dev.mellanox.co.il> (raw)
In-Reply-To: <CACTTzNaOChdWN2eS9_kzv6HO_LVib-JVdkmeUn0LDe2eKxPEgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>>> The almost is because:
>>>> 1. If the target is over a /dev/pmemX then all is fine we have 2M contiguous
>>>> memory blocks.
>>>> 2. If the target is over an FS, we have a proposal pending for an falloc_2M_flag
>>>> to ask the FS for a contiguous 2M allocations only. If any of the 2M allocations
>>>> fail then return ENOSPC from falloc. This way we guaranty that each 2M block can be
>>>> mapped by a single RDAM handle.
>>>
>>> Umm, you don't need the 2M to be contiguous in order to represent them
>>> as a single RDMA handle. If that was true iSER would have never worked.
>>> Or I misunderstood what you meant...
>>>
>>
>> OK I will let our RDMA guy Yigal Korman answer that, I guess you might be right.
>
> When Boaz says 'RDMA handle', he means the pair [rkey,remote_addr].
> AFAIK the remote_addr describes a continuous memory space on the target.
> So if you want to write to this 'handle' - it must be continuous.
> Please correct me if I'm wrong.
OK, this is definitely wrong. But let's defer this discussion to another
thread as it's not relevant to lsf folks...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-02-01 10:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 21:19 [LSF/MM TOPIC] Remote access to pmem on storage targets Chuck Lever
2016-01-25 21:19 ` Chuck Lever
2016-01-26 8:25 ` [Lsf-pc] " Jan Kara
2016-01-26 8:25 ` Jan Kara
2016-01-26 15:58 ` Chuck Lever
2016-01-27 0:04 ` Dave Chinner
2016-01-27 15:55 ` Chuck Lever
2016-01-27 15:55 ` Chuck Lever
2016-01-28 21:10 ` Dave Chinner
2016-01-27 10:52 ` Sagi Grimberg
2016-01-27 10:52 ` Sagi Grimberg
2016-01-26 15:25 ` Atchley, Scott
2016-01-26 15:25 ` Atchley, Scott
2016-01-26 15:25 ` Atchley, Scott
2016-01-26 15:29 ` Chuck Lever
2016-01-26 15:29 ` Chuck Lever
2016-01-26 17:00 ` Christoph Hellwig
2016-01-26 17:00 ` Christoph Hellwig
2016-01-27 16:54 ` [LSF/MM TOPIC/ATTEND] RDMA passive target Boaz Harrosh
2016-01-27 17:02 ` [Lsf-pc] " James Bottomley
2016-01-27 17:02 ` James Bottomley
2016-01-27 17:27 ` Sagi Grimberg
2016-01-31 14:20 ` Boaz Harrosh
2016-01-31 14:20 ` Boaz Harrosh
2016-01-31 16:55 ` Yigal Korman
2016-02-01 10:36 ` Sagi Grimberg [this message]
2016-02-01 10:36 ` Sagi Grimberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56AF3516.8000909@dev.mellanox.co.il \
--to=sagig@dev.mellanox.co.il \
--cc=boaz@plexistor.com \
--cc=chuck.lever@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=rwheeler@redhat.com \
--cc=yigal@plexistor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.