Re: [SPDK] Transport

[Kumaraparameshwaran Rathnavel <krath at cloudsimple.com>]

[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]

Hey thanks for the detailed explanation. Did help me. 

Is Linux 4.8.1 compatible with SPDK. I tried building SPDK and build failed. Did u guys try it??
Regards,
Param

Sent from my iPhone

> On 26-Oct-2016, at 3:51 AM, Walker, Benjamin <benjamin.walker(a)intel.com> wrote:
> 
>> On Tue, 2016-10-25 at 23:52 +0530, Kumaraparameshwaran Rathnavel wrote:
>> Hey thanks for the reply.
>> 
>> Can you please briefly explain me about the listener cm_id for incoming
>> connections and active connection cm_id for incoming NVMe-OF  requests.
>> 
>> Does this mean that initially when there is no connection established it is
>> acceptor_poll and after the connection establishment it is connection cm_id.
> 
> Our NVMe-oF target has a generalized fabric transport layer (transport.h/.c)
> that abstracts away the RDMA parts from the rest of the code. This transport
> layer consists of a number of callbacks that the specific transports (i.e. RDMA)
> must implement. Two of the functions deal with listening for incoming
> connections:
> 
>    /**
>     * Check for new connections on the transport.
>     */
>    void (*acceptor_poll)(void);
> 
>    /**
>      * Instruct the acceptor to listen on the address provided. This
>      * may be called multiple times.
>      */
>    int (*listen_addr_add)(struct spdk_nvmf_listen_addr *listen_addr);
> 
> listen_addr_add() instructs the transport to accept connections on the address
> provided. The acceptor_poll() function should check each listen address
> previously specified for pending new connection requests. When the
> acceptor_poll() function discovers a new pending NVMe-oF connect capsule, it
> should allocate an spdk_nvmf_request and call spdk_nvmf_request_exec() to tell
> the general purpose library code to process it. Embedded in that request is a
> new connection object for the newly established connection. Each queue pair is a
> connection in NVMe-oF and the library will poll the transport for new requests
> on that queue pair by calling the conn_poll() function pointer. The listen
> addresses are static after start up and they persist indefinitely, polled at
> some lower frequency, to accept new connections. The connections that are
> created as part of new queue pairs are polled for new NVMe-oF request capsules
> to perform I/O.
> 
>> 
>> Thanking You,
>> Param
>>> 
>>> On 25-Oct-2016, at 10:26 PM, Walker, Benjamin <benjamin.walker(a)intel.com>
>>> wrote:
>>> 
>>>> On Tue, 2016-10-25 at 20:16 +0530, Kumaraparameshwaran Rathnavel wrote:
>>>> 
>>>> Hi Guys, 
>>>> 
>>>> Can you tell me the functionality difference between the aaceptor_poll and
>>>> conn_poll in the file rdma.c
>>> 
>>> The acceptor_poll function should check the listener cm_id for incoming
>>> connections. The conn_poll should check the active connection cm_id for
>>> incoming
>>> NVMe-oF requests.
>>> 
>>>> 
>>>> 
>>>> Thanking you
>>>> Param
>>>> 
>>>> Sent from my iPhone
>>>> _______________________________________________
>>>> SPDK mailing list
>>>> SPDK(a)lists.01.org
>>>> https://lists.01.org/mailman/listinfo/spdk
>>> _______________________________________________
>>> SPDK mailing list
>>> SPDK(a)lists.01.org
>>> https://lists.01.org/mailman/listinfo/spdk
>> 
>> _______________________________________________
>> SPDK mailing list
>> SPDK(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk