[05:56:18] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [06:13:04] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [06:34:56] *** Joins: karan (402f1639@gateway/web/freenode/ip.64.47.22.57) [06:38:03] HiEveryone, I believe the community wants to lay the iSCSI target in SPDK on top of TLDK (which provides network layer 4 in user space), which in turn will go on top of DPDK. Is there any time frame for this? [06:42:09] *** Joins: nKumar (uid239884@gateway/web/irccloud.com/x-gzlyhiprjieubqge) [06:43:25] Question for the channel about the SPDK blobid. Is it possible to assign this when the blob is created? After looking through the spdk example code and unit tests, it looks like the blob ID is set by the spdk during blob create as a call back. I would love to be able to assign this ID if possible. Thanks! [06:49:29] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [07:00:25] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [08:52:08] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [09:02:57] karan: no timeframe. We do have one person working on alternate TCP/IP stacks for the iSCSI target [09:05:53] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [09:07:29] *** Quits: tomzawadzki (~tzawadzk@192.55.55.37) (Ping timeout: 248 seconds) [09:11:30] nKumar: the blobid is actually the offset into the reserved metadata region [09:11:56] if we allow the user to set it instead, then we have to store a persistent map between user numbers and the offsets [09:12:24] and then we'd have to go through and figure out how to do that atomically and in a power-fail safe manner [09:12:42] basically, it's a huge amount of complication [09:12:58] are you able to share more details about why that would help you? [09:26:02] Ben, thanks for the response! It would help on our end for a similar reason as why you stated it would be complicated to store. Currently if we are creating blobs and assigning a "name" to them. Given that the create function generates a unique ID, this implies that we have to store the name as an xattr and also store the ID on our side. I was just looking to see if we could reduce our overhead by assigning the blobid [09:26:02] instead of us having to maintain a map on the program side that associates blobid to our internal blob name. [09:26:56] ok - basically someone has to implement the map [09:27:07] if you want different names [09:27:30] do you want a string name, or an integer? [09:29:32] because the blobfs layer does a string name to blobid map [09:29:49] today, it just puts the string names into xattrs [09:30:04] and on boot, iterates the list of all blobs, reads in the names [09:30:07] and holds them in memory [09:30:38] if that map takes too much memory for your use case, it would take something a bit more complicated [09:32:56] btw - while I'm very confident that the internal design of the blobstore is solid and generally correct, the public API the library exposes is not at all what I want it to be [09:33:17] it's confusing, especially regarding thread safety [09:33:30] it's at the top of our blobstore todo list [09:35:20] Awesome! The map implementation shouldnt be too tough to manage, was just asking for the sake of memory efficiency. I will probably be able to tackle the mapping soon. I will take a look at the blobfs layer to see how it handles the iteration and the map creation, this will hopefully work with our memory availability. [09:41:42] we'd love to collaborate on your use of the blobstore, so keep us in the loop [09:44:07] I'm giving a talk at Flash Memory Summit on Aug. 8th on the blobstore, and peluse is giving a talk at SDC in September too [09:47:44] Awesome, Will do! Thanks! [09:57:09] *** Quits: karan (402f1639@gateway/web/freenode/ip.64.47.22.57) (Ping timeout: 260 seconds) [11:44:38] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [11:45:38] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) [14:49:25] *** Joins: dw (Daniel@nat/ibm/x-dmtbdefhtgojhtnx) [14:49:44] *** dw is now known as Guest85866 [14:49:48] *** Quits: Guest85866 (Daniel@nat/ibm/x-dmtbdefhtgojhtnx) (Client Quit) [14:50:36] *** Joins: dwaddington (Daniel@nat/ibm/x-dpoivupoagzjzoio) [14:53:23] Like to make a comment to not remove "manual" DPDK intialization, i.e. using spdk_env_init should not be required if you are writing a program that uses both DPDK/SPDK. I just updated to 17.03 and had to manually call spdk_vtophys_register_dpdk_mem() after getting weird SEGVs. [14:56:30] hmm - there definitely needs to be more thought put into using SPDK in applications that are also using stock DPDK [14:56:49] most of the thought to date has been trying to make SPDK easier to use in applications that can't use DPDK at all [14:57:04] your workaround (call spdk_vtophys_register_dpdk_mem) is the right one [14:57:57] Thanks. Yes, I think SPDK has to be careful not to add too many layers of abstraction that just burrow down to DPDK. [14:59:37] I think a very large portion of our users today actually write their own "env" and don't use DPDK at all [15:00:19] I don't know what the actual percentage is, but the devs providing the most feedback do that [15:00:53] but we need to have a design that works seemlessly with more traditional DPDK applications too [15:01:30] I wonder if there is some way to detect whether DPDK is initialized already [15:01:33] I'll look around [15:08:27] *** Quits: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [15:09:38] so it looks like rte_eal_init already detects if you call it twice [15:09:57] and it turns out, that's the only way that the function can actually fail [15:10:03] every other error does an exit() [15:11:20] so how bad would it be to just continue on with spdk_env_init of rte_eal_init fails [15:11:36] so you just initialize DPDK however you want, then do spdk_env_init (which tries to do rte_eal_init but it fails) [16:16:13] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.36) [17:34:19] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.36) (Remote host closed the connection) [17:34:42] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.36) [19:07:18] *** Joins: guerby_ (~guerby@ip165.tetaneutral.net) [19:13:56] *** Quits: guerby (~guerby@april/board/guerby) (*.net *.split) [19:56:38] *** Joins: ziyeyang__ (ziyeyang@nat/intel/x-wulqcptpnijofjmr) [19:56:39] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.36) (Remote host closed the connection) [20:00:39] *** Joins: guerby__ (~guerby@ip165.tetaneutral.net) [20:00:44] *** Quits: guerby_ (~guerby@ip165.tetaneutral.net) (Remote host closed the connection) [21:07:13] *** Quits: ziyeyang__ (ziyeyang@nat/intel/x-wulqcptpnijofjmr) (Remote host closed the connection) [22:05:51] *** Joins: tomzawadzki (~tzawadzk@134.134.139.77) [22:33:51] *** Quits: guerby__ (~guerby@ip165.tetaneutral.net) (Changing host) [22:33:51] *** Joins: guerby__ (~guerby@april/board/guerby) [22:33:57] *** guerby__ is now known as guerby [23:11:13] *** Joins: gila (~gila@5ED4FE92.cm-7-5d.dynamic.ziggo.nl)