[SPDK] Transport

[SPDK] Transport

[Kumaraparameshwaran Rathnavel]

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

Hi Guys, 

Can you tell me the functionality difference between the aaceptor_poll and conn_poll in the file rdma.c

Thanking you
Param

Sent from my iPhone

Re: [SPDK] Transport

[Walker, Benjamin]

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

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

Re: [SPDK] Transport

[Kumaraparameshwaran Rathnavel]

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

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.

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

Re: [SPDK] Transport

[Walker, Benjamin]

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

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

Re: [SPDK] Transport

[Kumaraparameshwaran Rathnavel]

[-- 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