iscsi-target

[Ming Lei]

Hello ronnie sahlberg,

I saw you mentioned iscsi target in the following PR:

https://github.com/ublk-org/ublksrv/pull/83#issuecomment-2613510069

I guess you think it is one good feature to add?

I am thinking about the implementation, and the current ublk is capable
of building iscsi target, just one thing: host-wide tag isn't supported,
more than one LUN is supposed to share same tag space, but current ublk
driver doesn't support it, so ublk server has to handle it by itself.
This way works, just not perfect, and not super efficient.

And ublk driver side needs some(not much) work to support host-wide tag,
maybe two control commands(ADD_HOST, DEL_HOST) are enough, feel free to
share if we need to support it in driver side.

Thanks,
Ming

[ronnie sahlberg]

On Thu, 6 Mar 2025 at 18:31, Ming Lei <tom.l...@gmail.com> wrote:

Hello ronnie sahlberg,

I saw you mentioned iscsi target in the following PR:

https://github.com/ublk-org/ublksrv/pull/83#issuecomment-2613510069

I guess you think it is one good feature to add?

Yes, I think it would be a very nice thing to add.

But for the first target I think libnfs would be better. Libnfs has a very similar API

(non-blocking, event driven with callbacks) but it also has extensions for multithreading

to make it multithread safe.

Libiscsi so far is non-blocking and event driven but not yet threads safe.

(I consider multithreading somewhat orthogonal to event driven designs eventhough they both aim to solve the same problem, increased concurrency)

I have plans to add multithreading to libiscsi too, mostly just by copying the implementation from libnfs

but I have not had time to do it yet.

I plan to and want to add targets for all three of my libnfs/libsmb2/libsmb2 libraries but just do not have had time.

Lets build a ublk.nfs target first using libnfs.   After that the other two will be trivial to add.

If you want to build ublk.nfs, please be my guest. Otherwise I will get there at some stage.

[ronnie sahlberg]

Oh, I didn't read your mail properly first.

I was thinking about building an iscsi INITIATOR with ublk, to talk to a remote iscsi target. Not building a target.

It could be a useful alternative to the in-kernel iscsi target.

Here is some data that a guy from Mellanix got :

https://www.snia.org/sites/default/files/SDC/2016/presentations/storage_networking/Shterman-Grimberg_Greenberg_Performance%20Implications%20Libiscsi_%20RDMA_V6.pdf

libiscsi would provide VERY high performance   but as I said, I need to make it multi-thread safe first. Not difficult, just time consuming.

[Ming Lei]

On Thu, Mar 06, 2025 at 06:47:36PM +1000, ronnie sahlberg wrote:
> Oh, I didn't read your mail properly first.
>
> I was thinking about building an iscsi INITIATOR with ublk, to talk to a
> remote iscsi target. Not building a target.

Yeah, I meant initiator, and target needn't ublk for exporting block
device.

> It could be a useful alternative to the in-kernel iscsi target.
> Here is some data that a guy from Mellanix got :
> https://www.snia.org/sites/default/files/SDC/2016/presentations/storage_networking/Shterman-Grimberg_Greenberg_Performance%20Implications%20Libiscsi_%20RDMA_V6.pdf
>
> libiscsi would provide VERY high performance but as I said, I need to
> make it multi-thread safe first. Not difficult, just time consuming.

Great, I think I can work on kernel side to support host wide tag first
by adding ADD_HOST/DEL_HOST commands, then the usersapce implementation
can be super efficient.

Thanks,
Ming