All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [SPDK] perf vs spdk_app_start()
@ 2018-10-30  9:59 Szwed, Maciej
  0 siblings, 0 replies; 6+ messages in thread
From: Szwed, Maciej @ 2018-10-30  9:59 UTC (permalink / raw)
  To: spdk

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

This is actually the case. I need to register poller for event handler and that is way I would like to use spdk_app_start. Creating own thread for poller is a bit overkill for example application.

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Stojaczyk, Dariusz
Sent: Tuesday, October 30, 2018 10:47 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] perf vs spdk_app_start()

Nvme perf example doesn't use the app framework by design. It doesn't use reactors, pollers, events, bdevs, or so. It's just a low-level app for benchmarking the NVMe driver directly. Refactoring it to use the app framework would add some extra overhead, which is not the way to go here.

Maybe you could try exposing some low level NVMe event handler API and then use it directly in perf?

D.

> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Szwed, 
> Maciej
> Sent: Tuesday, October 30, 2018 10:26 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: [SPDK] perf vs spdk_app_start()
> 
> Hi,
> I'm implementing NVMf event handler for initiator and I noticed that 
> perf
> (spdk\examples\nvme\perf) does not use spdk_app_start(). I'd like to 
> know if this was done on purpose? Or can I modify it so that it will 
> use spdk_app_start()?
> 
> Regards,
> Maciek
> 
> _______________________________________________
> 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [SPDK] perf vs spdk_app_start()
@ 2018-11-02 10:21 Szwed, Maciej
  0 siblings, 0 replies; 6+ messages in thread
From: Szwed, Maciej @ 2018-11-02 10:21 UTC (permalink / raw)
  To: spdk

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

I can leave it as it is and do it on main thread. The question is how much X is in ' every X number of I/O' to make it reasonable? Any suggestions here?

Thanks,
Maciek 

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Lance Hartmann ORACLE
Sent: Tuesday, October 30, 2018 7:44 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] perf vs spdk_app_start()


> On Oct 30, 2018, at 12:55 PM, Walker, Benjamin <benjamin.walker(a)intel.com> wrote:
> 
> On Tue, 2018-10-30 at 09:59 +0000, Szwed, Maciej wrote:
>> This is actually the case. I need to register poller for event 
>> handler and that is way I would like to use spdk_app_start. Creating 
>> own thread for poller is a bit overkill for example application.
> 
> The primary reason NVMe perf does not use the application framework is 
> because NVMe perf was written before the application framework 
> existed. You could definitely do a port to use it, but I kind of like 
> the independence. Any API you create in the NVMe driver should be 
> consumable without the application framework. Maybe just poll for events every X number of I/O?


I'd like to cast a vote for retaining nvme/perf as-is as well.  I found it very useful in learning the use of the SPDK nvme driver API without having to wade through the additional complexity of the app framework.

--
Lance Hartmann
lance.hartmann(a)oracle.com



_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [SPDK] perf vs spdk_app_start()
@ 2018-10-30 18:43 Lance Hartmann ORACLE
  0 siblings, 0 replies; 6+ messages in thread
From: Lance Hartmann ORACLE @ 2018-10-30 18:43 UTC (permalink / raw)
  To: spdk

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


> On Oct 30, 2018, at 12:55 PM, Walker, Benjamin <benjamin.walker(a)intel.com> wrote:
> 
> On Tue, 2018-10-30 at 09:59 +0000, Szwed, Maciej wrote:
>> This is actually the case. I need to register poller for event handler and
>> that is way I would like to use spdk_app_start. Creating own thread for poller
>> is a bit overkill for example application.
> 
> The primary reason NVMe perf does not use the application framework is because
> NVMe perf was written before the application framework existed. You could
> definitely do a port to use it, but I kind of like the independence. Any API you
> create in the NVMe driver should be consumable without the application
> framework. Maybe just poll for events every X number of I/O?


I'd like to cast a vote for retaining nvme/perf as-is as well.  I found it very useful in learning the use of the SPDK nvme driver API without having to wade through the additional complexity of the app framework.

--
Lance Hartmann
lance.hartmann(a)oracle.com




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [SPDK] perf vs spdk_app_start()
@ 2018-10-30 17:55 Walker, Benjamin
  0 siblings, 0 replies; 6+ messages in thread
From: Walker, Benjamin @ 2018-10-30 17:55 UTC (permalink / raw)
  To: spdk

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

On Tue, 2018-10-30 at 09:59 +0000, Szwed, Maciej wrote:
> This is actually the case. I need to register poller for event handler and
> that is way I would like to use spdk_app_start. Creating own thread for poller
> is a bit overkill for example application.

The primary reason NVMe perf does not use the application framework is because
NVMe perf was written before the application framework existed. You could
definitely do a port to use it, but I kind of like the independence. Any API you
create in the NVMe driver should be consumable without the application
framework. Maybe just poll for events every X number of I/O?


> 
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Stojaczyk, Dariusz
> Sent: Tuesday, October 30, 2018 10:47 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: Re: [SPDK] perf vs spdk_app_start()
> 
> Nvme perf example doesn't use the app framework by design. It doesn't use
> reactors, pollers, events, bdevs, or so. It's just a low-level app for
> benchmarking the NVMe driver directly. Refactoring it to use the app framework
> would add some extra overhead, which is not the way to go here.
> 
> Maybe you could try exposing some low level NVMe event handler API and then
> use it directly in perf?
> 
> D.
> 
> > -----Original Message-----
> > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Szwed, 
> > Maciej
> > Sent: Tuesday, October 30, 2018 10:26 AM
> > To: Storage Performance Development Kit <spdk(a)lists.01.org>
> > Subject: [SPDK] perf vs spdk_app_start()
> > 
> > Hi,
> > I'm implementing NVMf event handler for initiator and I noticed that 
> > perf
> > (spdk\examples\nvme\perf) does not use spdk_app_start(). I'd like to 
> > know if this was done on purpose? Or can I modify it so that it will 
> > use spdk_app_start()?
> > 
> > Regards,
> > Maciek
> > 
> > _______________________________________________
> > 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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [SPDK] perf vs spdk_app_start()
@ 2018-10-30  9:46 Stojaczyk, Dariusz
  0 siblings, 0 replies; 6+ messages in thread
From: Stojaczyk, Dariusz @ 2018-10-30  9:46 UTC (permalink / raw)
  To: spdk

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

Nvme perf example doesn't use the app framework by design. It doesn't use reactors, pollers, events, bdevs, or so. It's just a low-level app for benchmarking the NVMe driver directly. Refactoring it to use the app framework would add some extra overhead, which is not the way to go here.

Maybe you could try exposing some low level NVMe event handler API and then use it directly in perf?

D.

> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Szwed, Maciej
> Sent: Tuesday, October 30, 2018 10:26 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: [SPDK] perf vs spdk_app_start()
> 
> Hi,
> I'm implementing NVMf event handler for initiator and I noticed that perf
> (spdk\examples\nvme\perf) does not use spdk_app_start(). I'd like to know
> if this was done on purpose? Or can I modify it so that it will use
> spdk_app_start()?
> 
> Regards,
> Maciek
> 
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [SPDK] perf vs spdk_app_start()
@ 2018-10-30  9:26 Szwed, Maciej
  0 siblings, 0 replies; 6+ messages in thread
From: Szwed, Maciej @ 2018-10-30  9:26 UTC (permalink / raw)
  To: spdk

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

Hi,
I'm implementing NVMf event handler for initiator and I noticed that perf (spdk\examples\nvme\perf) does not use spdk_app_start(). I'd like to know if this was done on purpose? Or can I modify it so that it will use spdk_app_start()?

Regards,
Maciek


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-11-02 10:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-30  9:59 [SPDK] perf vs spdk_app_start() Szwed, Maciej
  -- strict thread matches above, loose matches on Subject: below --
2018-11-02 10:21 Szwed, Maciej
2018-10-30 18:43 Lance Hartmann ORACLE
2018-10-30 17:55 Walker, Benjamin
2018-10-30  9:46 Stojaczyk, Dariusz
2018-10-30  9:26 Szwed, Maciej

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.