[00:00:11] *** Quits: Param (~Param@223.227.43.178) (Quit: Param) [00:12:07] *** Joins: Param (~Param@223.227.43.178) [00:16:23] *** Quits: Param (~Param@223.227.43.178) (Read error: Connection reset by peer) [00:20:43] *** Joins: Param (~Param@223.227.43.178) [00:38:48] Hi Shuhei, [00:38:50] I previously tested libiscsi in my local machine. [00:38:52] There are about 172 failed when we test libiscsi tool with spdk iSCSI target. For example, use the following command: [00:38:55] iscsi-test-cu --test=SCSI iscsi://127.0.0.1/iqn.2013-06.com.intel.ch.spdk:disk1/0 (To test the scsi suit, attached shows the full log). [00:38:58] Run Summary: Type Total Ran Passed Failed Inactive [00:39:00] suites 47 47 n/a 0 0 [00:39:02] tests 214 214 185 29 0 [00:39:04] asserts 7142 7142 6970 172 n/a [01:12:48] *** Quits: Param (~Param@223.227.43.178) (Quit: Param) [02:01:06] *** Joins: Param (~Param@223.227.43.178) [03:18:16] *** Quits: Param (~Param@223.227.43.178) (Quit: Param) [03:33:20] *** Joins: Param (~Param@223.227.43.178) [04:56:27] *** Quits: Param (~Param@223.227.43.178) (Ping timeout: 240 seconds) [09:38:06] *** Joins: lhodev (~Adium@inet-hqmc04-o.oracle.com) [09:38:55] *** Parts: lhodev (~Adium@inet-hqmc04-o.oracle.com) () [09:57:33] ziyeyang - yes, I agree we should run both SCSI and iSCSI tests from libiscsi [09:59:05] yeah we should run all of the tests - libiscsi is great because it runs so quickly [09:59:59] in fact, we should consider contributing missing tests to the libiscsi project [10:00:27] the calsoft suite really focuses on iSCSI and not so much on SCSI itself - there is a Windows/WHQL SCSI compliance test but that's challenging (at best) to automate [10:01:18] the windows test is pretty solid, I like it. But the ideal long term for us is that libiscsi is a comprehensive test of both iscsi and scsi [10:01:33] libiscsi fits with SPDK perfectly [10:03:14] and it would be great if someone wrote the equivalent of the libiscsi unit tests for our NVMe-oF initiator [14:09:12] jimharris: I'm looking at a scenario and I need your opinion on what the behavior should be. It's a unit test you wrote [14:09:27] user calls spdk_bdev_reset(desc, io_channel, ...) [14:09:32] then before the reset finishes [14:09:39] spdk_put_io_channel(io_channel) [14:09:44] what should the behavior be? [14:10:06] same question if you call spdk_bdev_read(desc, io_channel, ...) really [14:10:22] and delete the io_channel before the read completes? [14:10:28] yep [14:10:36] basically, what should happen if you put the io_channel while I/O is outstanding [14:10:55] the generic io_channel code doesn't know that I/O is outstanding [14:11:39] yeah - i was rethinking whether we should keep the generic spdk_put_io_channel or have it more module-specific (i.e. spdk_bdev_put_io_channel) [14:11:53] should we make the channel destroy callback return an int and allow it to fail, then propagate that up to spdk_put_io_channel? [14:12:10] the challenge is that currently spdk_put_io_channel is actually a deferred operation [14:13:15] I think a new spdk_bdev_put_io_channel() function could return an error code [14:13:20] synchronously [14:16:12] jimharris: should [Rpc] section of the config file override the command line? [14:16:17] seems like that is how it works currently [14:16:50] hmmm - no, probably not [14:17:07] I feel like this came up during the code review though [14:17:31] ok, I can tweak that - working on fixing the nightly failure due to the running config function printing out "(null)" as the RPC address [14:18:13] I'm not sure if we want it to write out the RPC address provided via command line, or just not print out the RPC section if it wasn't already in the conf [14:19:27] https://review.gerrithub.io/#/c/386561/ [14:20:15] darsto mentioned this same issue - i kept it with conf file having priority because it deferred having to change all of the tests that used multiple processes each with rpc listening addresses [14:20:41] but i think a lot of those tests have been cleaned up - maybe we can just remove the Rpc config section altogether? [14:20:43] ah, OK, I think we fixed those now [14:20:50] I'm happy with that idea [14:21:09] vhost initiator and ip migration are the only tests still using it [14:21:14] looks like test/iscsi_tgt/ip_migration/iscsi.conf and test/vhost/initiator/bdev.conf.in still have [Rpc] sections [14:22:28] ha - you already fixed ip_migration to not use the config file [14:22:34] you just didn't remove the config file [14:22:43] or rather didn't remove the Rpc section from the config file [14:25:08] oops [14:25:16] I'll put together a series to clean up those two and remove conf support [14:27:25] oh - and fixing the vhost initiator one looks simple [14:27:53] just always pass a socket path to discover_bdevs [14:28:05] and use it to start bdev_svc and for the rpc get_bdevs call [14:28:46] e9ac7a7 (also yours) already adds command line rpc socket definition to bdev_svc [14:32:02] hmm, the changelog entry you wrote says that we are going to remove the configuration file section in 18.04 [14:32:09] so maybe we don't want to do that just yet [14:32:45] ok - well at least change all of our tests to stop using it now [14:32:56] yeah [14:55:21] jimharris: the wrapper function for putting the I/O channel in bdev doesn't work [14:55:38] because you could have two different chunks of code grabbing a reference to the same I/O channel [14:55:48] and you only want to fail the put if it is the final reference count [14:56:33] oh yeah [14:57:09] i forgot about that - i did run into that when thinking about this problem originally [14:57:42] so my proposed solution, which you probably don't like [14:57:52] make the channel destroy callback have a return value, let it fail [14:57:58] make put_io_channel synchronous [14:58:02] if it fails, propagate up to user [14:58:12] but then the failure check occurs after the reference count check [14:58:43] now that the pollers are in the io_channel library, I can intelligently wrap pollers and let you put io_channels within them [14:58:49] so I think that's the way to go [15:53:38] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:00:49] Hi Jim, this is not urgent. I will reply to the mailing list with the link that it looks calsoft was skipped. thank you. [16:49:21] sethhowe, drv: on the test/iscsi_tgt patch, I think we should modify the malloc bdev to do a bunch of smaller allocations instead of one huge allocation [16:49:50] the patch is fine and I pushed it - but I think using smaller allocations would eliminate this general problem once and for all [16:50:24] yeah, I think that's probably a good idea, but it does require some extra code to split I/Os that cross the allocations [17:24:06] looking at the iSCSI RPC names - ones like get_portal_groups should probably be iscsi_get_portal_groups [17:24:31] construct_target_node => iscsi_construct_target_node [17:25:15] Python 3.2 added subparser aliases, but those aren't available in 2.7 [17:25:43] so you could do change the rpc name to "iscsi_get_target_nodes", but still keep "get_target_nodes" around as an alias for now [17:36:38] yeah, if we want to do that, we should do a one-time renaming of all existing RPCs to make them consistent [17:47:24] *** Joins: sheng__ (d0b9d304@gateway/web/freenode/ip.208.185.211.4) [17:50:07] hi, i met a problem with spdk memory. when i start app using spdk_unaffinitize_thread(), the spdk_dma_free() may PANIC in rte_free(): Fatal error: Invalid memory [17:50:42] if not using spdk_unaffinitize_thread(), everything seems ok. May i ask what's likely the problem is? [18:19:26] *** Quits: sethhowe (~sethhowe@192.55.54.38) (Remote host closed the connection) [18:21:29] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.41) [18:30:08] *** Joins: ziyeyang__ (~ziyeyang@192.55.54.41) [18:30:09] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.41) (Remote host closed the connection) [18:33:58] *** Joins: sethhowe (sethhowe@nat/intel/x-bxzjbdpnxxwwsuui) [18:37:39] *** Quits: sethhowe (sethhowe@nat/intel/x-bxzjbdpnxxwwsuui) (Remote host closed the connection) [18:48:18] *** Joins: sethhowe (~sethhowe@192.55.54.38) [18:48:43] *** Quits: sethhowe (~sethhowe@192.55.54.38) (Remote host closed the connection) [18:59:29] *** Quits: sheng__ (d0b9d304@gateway/web/freenode/ip.208.185.211.4) (Quit: Page closed) [19:11:55] *** Joins: sethhowe (sethhowe@nat/intel/x-udfhtallpcbiejsb)