spdk.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [SPDK] Re: About SMA + IPU
@ 2022-06-27 15:20 Sztyber, Konrad
  0 siblings, 0 replies; 3+ messages in thread
From: Sztyber, Konrad @ 2022-06-27 15:20 UTC (permalink / raw)
  To: spdk

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

> -----Original Message-----
> From: Yibo Cai <Yibo.Cai(a)arm.com>
> Sent: Monday, June 27, 2022 8:01 AM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: [SPDK] Re: About SMA + IPU
>
> So, in cloud storage environment (e.g., kubernetes + csi), looks orchestrator
> is still responsible for most of the control plane rpcs that's not in current SMA
> scope.

Correct, the orchestrator is responsible for sending the RPCs to configure the target system.

> Do we want to support more commands in SMA? 

Yes, we do want to support more commands in SMA, although we're mostly thinking about the initiator side.

> Does it make sense to add a grpc method to transfer low level spdk rpc commands (json string)
> transparently, or we prefer higher level abstractions?

Ideally, we'd have a high-level abstraction for everything, but I can see how a passthrough method like that could be useful in some cases (e.g. to use the gRPC transport to send SPDK JSON-RPCs to configure the target). So, if there's a demand for it, I don't see any reason not to add it.

Konrad 

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

* [SPDK] Re: About SMA + IPU
@ 2022-06-27  6:00 Yibo Cai
  0 siblings, 0 replies; 3+ messages in thread
From: Yibo Cai @ 2022-06-27  6:00 UTC (permalink / raw)
  To: spdk

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

Hi Konrad,

Thanks for the explanation.
So, in cloud storage environment (e.g., kubernetes + csi), looks orchestrator is still responsible for most of the control plane rpcs that's not in current SMA scope.
Do we want to support more commands in SMA? Does it make sense to add a grpc method to transfer low level spdk rpc commands (json string) transparently, or we prefer higher level abstractions?

Yibo

-----Original Message-----
From: Sztyber, Konrad <konrad.sztyber(a)intel.com>
Sent: Friday, June 24, 2022 4:44 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] Re: About SMA + IPU

Hi Yibo,

The sequence you've listed is pretty close to how I understand it, except for this part:

> - IPU sends SPDK-RPC commands to some storage node through http proxy,
> to create bdev, export NVMe-oF target

I don't think IPU is responsible for configuring the target side. That should be done by some other external orchestrator prior to sending the CreateDevice/AttachVolume commands.

Konrad

> -----Original Message-----
> From: Yibo Cai <yibo.cai(a)arm.com>
> Sent: Friday, June 24, 2022 10:21 AM
> To: spdk(a)lists.01.org
> Subject: [SPDK] About SMA + IPU
>
> Hi,
>
> I'm struggling in understand use cases of SMA(Storage Management
> Agent) and IPU(Infrastructure Processing Unit). Would like to seek for help.
>
> Assume a host with IPU, connected to a remote storage node running
> SPDK service.
>
> If an app on host CPU needs storage resource, in my understanding,
> below steps will happen:
> - app (or orchestrator) sends SMA CreateDevice/AttachVolume commands
> to the SPDK service running on IPU
> - IPU sends SPDK-RPC commands to some storage node through http proxy,
> to create bdev, export NVMe-oF target
> - IPU runs NVMe initiator to connect to remote NVMe-oF target
> - IPU exposes the NVMe-oF target as a local NVMe device to host OS, so
> the app (or orchestrator) can make use of it
>
> Is that correct?
>
> Yibo
> _______________________________________________
> SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to
> spdk-leave(a)lists.01.org
_______________________________________________
SPDK mailing list -- spdk(a)lists.01.org
To unsubscribe send an email to spdk-leave(a)lists.01.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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

* [SPDK] Re: About SMA + IPU
@ 2022-06-24  8:43 Sztyber, Konrad
  0 siblings, 0 replies; 3+ messages in thread
From: Sztyber, Konrad @ 2022-06-24  8:43 UTC (permalink / raw)
  To: spdk

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

Hi Yibo,

The sequence you've listed is pretty close to how I understand it, except for this part:

> - IPU sends SPDK-RPC commands to some storage node through http proxy,
> to create bdev, export NVMe-oF target

I don't think IPU is responsible for configuring the target side. That should be done by some other external orchestrator prior to sending the CreateDevice/AttachVolume commands.

Konrad

> -----Original Message-----
> From: Yibo Cai <yibo.cai(a)arm.com>
> Sent: Friday, June 24, 2022 10:21 AM
> To: spdk(a)lists.01.org
> Subject: [SPDK] About SMA + IPU
> 
> Hi,
> 
> I'm struggling in understand use cases of SMA(Storage Management Agent)
> and IPU(Infrastructure Processing Unit). Would like to seek for help.
> 
> Assume a host with IPU, connected to a remote storage node running SPDK
> service.
> 
> If an app on host CPU needs storage resource, in my understanding, below
> steps will happen:
> - app (or orchestrator) sends SMA CreateDevice/AttachVolume commands to
> the SPDK service running on IPU
> - IPU sends SPDK-RPC commands to some storage node through http proxy,
> to create bdev, export NVMe-oF target
> - IPU runs NVMe initiator to connect to remote NVMe-oF target
> - IPU exposes the NVMe-oF target as a local NVMe device to host OS, so the
> app (or orchestrator) can make use of it
> 
> Is that correct?
> 
> Yibo
> _______________________________________________
> SPDK mailing list -- spdk(a)lists.01.org
> To unsubscribe send an email to spdk-leave(a)lists.01.org

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

end of thread, other threads:[~2022-06-27 15:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-27 15:20 [SPDK] Re: About SMA + IPU Sztyber, Konrad
  -- strict thread matches above, loose matches on Subject: below --
2022-06-27  6:00 Yibo Cai
2022-06-24  8:43 Sztyber, Konrad

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).