[00:31:12] *** Joins: tkulasek (~tkulasek@134.134.139.75) [00:36:45] *** Joins: tzawadzki (~tomzawadz@134.134.139.76) [00:39:16] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-jetyqhpwgyavabzb) (Ping timeout: 248 seconds) [02:43:39] *** Quits: tkulasek (~tkulasek@134.134.139.75) (Remote host closed the connection) [03:22:29] *** Joins: alekseymmm (bcf3adf1@gateway/web/freenode/ip.188.243.173.241) [03:46:06] *** Quits: dlw (~Thunderbi@114.255.44.143) (Ping timeout: 248 seconds) [04:40:10] *** Quits: tzawadzki (~tomzawadz@134.134.139.76) (Ping timeout: 260 seconds) [04:48:35] *** Joins: tomzawadzki (~tomzawadz@192.55.54.38) [05:13:20] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) [05:22:57] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) (Ping timeout: 248 seconds) [05:39:04] *** Joins: lyan (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) [06:48:57] *** Quits: tomzawadzki (~tomzawadz@192.55.54.38) (Ping timeout: 260 seconds) [07:00:44] *** Joins: tomzawadzki (~tomzawadz@192.55.54.38) [07:03:04] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) [07:08:46] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) (Ping timeout: 264 seconds) [07:40:28] *** Quits: tomzawadzki (~tomzawadz@192.55.54.38) (Ping timeout: 256 seconds) [07:59:04] *** Joins: pwodkowx (pwodkowx@nat/intel/x-rllwvpqrswpdfasd) [08:09:10] I have a followup question regarding huge page memory usage: I have 2GB (the default) set up. I have two vhost apps running, both with -s 256. My expectation is that I now have 1.5GB of memory available. But in practice, qemu -m 1024 -object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on fails to start with "unable to map backing store for guest RAM: Cannot allocate memory". [08:10:08] Something does not quite add up here. There's a slight chance though (these are parallel tests) that there were more vhost processes. [08:16:48] you can have some garbage from previous host execution [08:18:42] try: ls -al /dev/hugepages/spdk_* [08:18:54] you can remove those files if any [08:31:18] pwodkowx: at which time are those files garbage? "setup.sh reset" seems to clean up everything, and then re-creates them. [08:31:58] Ooops, no, it doesn't. [08:32:18] That may indeed have been the problem. [08:32:49] Does vhost have to exit cleanly to remove its /dev/hugepages entries? [08:32:58] yes [08:33:49] these won't be cleaned up if you used kill -9 or so [08:41:28] *** Quits: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) [09:15:07] darsto: what happens when removing those entries while the process that is using them still runs> [09:15:07] ? [09:15:38] Sorry for the naive questions :-/ I have no clue how the huge pages API works. [09:16:40] i'm not sure actually [09:17:48] thos are pseudo files to express physical memory mapings. [09:17:50] i could guess nothing bad happens [09:18:39] the hugepage memory should be still locked up [09:19:50] I think, attaching another process using shared mmeory ID might not work [09:20:40] pwodkowx: is that something that needs to work for SPDK? [09:21:10] Because if it is fine to already delete the files while still in use, then spdk itself could do that and there would be no risk of leaking resources. [09:21:10] pwodkowx: there's that one file that hold primary process data, but it's not in /dev/hugepages [09:21:15] I depend what you need :) [09:21:41] * it [09:32:15] *** Joins: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) [09:32:15] (spdk/master) changelog: add note about -t to -L option rename (Daniel Verkamp) [09:32:15] Diff URL: https://github.com/spdk/spdk/compare/70df6cb890d2...6f8ab3953425 [09:32:15] *** Parts: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) () [09:34:52] *** Joins: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) [09:34:53] (spdk/master) test/vhost: change spdk and qemu masks to decimal format (Karol Latecki) [09:34:54] Diff URL: https://github.com/spdk/spdk/compare/6f8ab3953425...dfe497c27b94 [09:34:54] *** Parts: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) () [09:58:10] drv: unfortunately the dma buffers might consist of multiple buffers that were passed to hotplug callbacks separately [09:58:56] hmm, I suppose that is pretty good motivation to implement full SGL support in nvme_rdma then [09:58:57] (which we wanted to do anyway, but now it's more urgent) [09:59:56] DPDK has got all this nicely separated to raw memory management and malloc_elems [10:00:26] they were probably basing on linux [10:03:28] in theory, we could also try to coalesce our memory registration regions whenever we get a new hotplug cb by sending an unregister notification for the contiguous regions and then re-registering the combined region [10:03:28] but I'm not sure that's worth the trouble [10:03:58] the rdma memory registration is slow already [10:04:28] it's not that much of a big deal, only hotplugged memory won't work [10:05:00] no need to rush it [10:06:29] btw. we can still pass a DPDK command line flag to use legacy memory allocation [10:06:42] it doesn't support hotplug obviously [10:08:30] we could temporarily advise all RDMA users to use this flag [10:08:30] that's also an option [10:08:38] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:10:39] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:14:33] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:16:34] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:17:12] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:19:15] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:19:46] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:21:48] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:22:19] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:24:21] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:24:51] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:27:08] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:27:39] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:29:39] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:30:10] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:32:10] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:32:41] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:34:42] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [10:35:12] *** Joins: lhodev (~lhodev@inet-hqmc07-o.oracle.com) [10:37:58] Hmm, as far as I can tell from my test output, vhost was stopped via SIGINT and not SIGKILL, but nonetheless it left files in /dev/hugepages behind. [10:43:18] *** Joins: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) [10:43:19] (spdk/master) test/config: minor error fixes to vm_setup.sh (Seth Howell) [10:43:19] Diff URL: https://github.com/spdk/spdk/compare/dfe497c27b94...a33a7b44a307 [10:43:19] *** Parts: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) () [10:44:46] *** Joins: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) [10:44:46] (spdk/master) thread: send message for completion with no channels (Daniel Verkamp) [10:44:46] Diff URL: https://github.com/spdk/spdk/compare/a33a7b44a307...8e5eef8ebc0a [10:44:46] *** Parts: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) () [10:48:53] *** Joins: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) [10:48:54] (spdk/master) app/trace: update app name (Liang Yan) [10:48:54] Diff URL: https://github.com/spdk/spdk/compare/8e5eef8ebc0a...ddb3583b445e [10:48:54] *** Parts: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) () [10:50:49] *** Joins: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) [10:50:49] (spdk/master) bdev/nvme: update NS bdevs after NS attribute notice event (Changpeng Liu) [10:50:49] Diff URL: https://github.com/spdk/spdk/compare/ddb3583b445e...4c4e2b4d8029 [10:50:49] *** Parts: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) () [10:51:19] *** Joins: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) [10:51:19] (spdk/master) bdev: add null check to spdk_bdev_unregister: (Seth Howell) [10:51:19] Diff URL: https://github.com/spdk/spdk/compare/4c4e2b4d8029...dd7b90fac98e [10:51:19] *** Parts: travis-ci (~travis-ci@ec2-54-221-136-83.compute-1.amazonaws.com) () [10:51:21] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) [10:57:05] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) (Ping timeout: 240 seconds) [11:03:36] *** Joins: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) [11:03:37] (spdk/master) blobstore: Save the original size of the disk. (Piotr Pelplinski) [11:03:38] Diff URL: https://github.com/spdk/spdk/compare/dd7b90fac98e...2c91e91907e2 [11:03:38] *** Parts: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) () [11:13:29] *** Joins: bk_ (d0455522@gateway/web/freenode/ip.208.69.85.34) [11:14:07] *** Quits: bk_ (d0455522@gateway/web/freenode/ip.208.69.85.34) (Client Quit) [11:18:03] bwalker: did you see John Barnard's comment on https://review.gerrithub.io/#/c/spdk/spdk/+/416466/ ? [11:19:14] yeah - I'll review his patch that splits out the initialization [11:20:08] *** Joins: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) [11:20:09] (spdk/master) bdev: Make an internal version of spdk_bdev_io_type_supported (Ben Walker) [11:20:09] Diff URL: https://github.com/spdk/spdk/compare/253c61be4ecf...a4d22f7bdcf6 [11:20:09] *** Parts: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) () [11:21:07] *** Joins: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) [11:21:07] (spdk/master) scripts/rpc.py: pass named args to iscsi.py (heluwei) [11:21:07] Diff URL: https://github.com/spdk/spdk/compare/2c91e91907e2...253c61be4ecf [11:21:07] *** Parts: travis-ci (~travis-ci@ec2-54-205-233-51.compute-1.amazonaws.com) () [11:23:08] *** Joins: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) [11:23:08] (spdk/master) bdev/iscsi: Add unmap support for iscsi initiator (Chunyang Hui) [11:23:08] Diff URL: https://github.com/spdk/spdk/compare/a4d22f7bdcf6...8b38468db444 [11:23:08] *** Parts: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) () [11:25:19] if the transport is capable of doing zcopy to buffers allocated by the bdev module [11:25:39] then it can certainly use a common buffer pool for admin commands too [11:25:39] so I don't know if I agree [11:26:09] I do agree that the patches conflict, and that we need to do explicit transport initialization where each transport can have different options [11:27:23] one thing we need to decide is whether a single controller (network session) can actually span transports [11:30:55] this paragraph from the NVMe-oF 1.0 spec seems to indicate that it can't: [11:31:12] "While an association exists between a host and a controller, only that host may establish connections with [11:31:12] I/O Queues of that controller by presenting the same Host NQN, Host Identifier, NVM Subsystem NQN and [11:31:12] Controller ID in subsequent Connect command(s) using the same NVM subsystem port, NVMe Transport [11:31:12] type, and NVMe Transport address." [11:31:48] "same NVM subsystem port" [11:31:55] does that go one step further then? [11:32:12] yeah, we should probably enforce that [11:32:12] and say you can't actually span a controller across two ports of the same transport type? [11:32:18] right [11:32:53] so all multipathing scenarios require at least two controllers [11:33:13] I don't know if that part is changed at all in the latest NVMe-oF draft [11:33:13] they may or may not be in the same subsystem [11:33:43] when we create a controller, we need to store the host NQN and the listen addr it originated on [11:33:43] and then enforce [11:33:51] that does make things much simpler [12:29:07] *** Quits: pohly (~pohly@p5484976F.dip0.t-ipconnect.de) (Quit: Leaving.) [13:42:47] *** Quits: lhodev (~lhodev@inet-hqmc07-o.oracle.com) (Remote host closed the connection) [14:20:28] *** Joins: lhodev (~lhodev@66-90-218-190.dyn.grandenetworks.net) [15:49:09] *** Quits: alekseymmm (bcf3adf1@gateway/web/freenode/ip.188.243.173.241) (Ping timeout: 260 seconds) [16:40:36] *** Joins: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) [16:40:37] (spdk/master) test: set norandommap to be a variable in fio.py (Liang Yan) [16:40:37] Diff URL: https://github.com/spdk/spdk/compare/8b38468db444...58b02f47a001 [16:40:37] *** Parts: travis-ci (~travis-ci@ec2-54-224-239-115.compute-1.amazonaws.com) () [16:41:30] *** Joins: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) [16:46:17] *** Joins: travis-ci (~travis-ci@ec2-54-162-149-177.compute-1.amazonaws.com) [16:46:33] (spdk/master) shared_lib: add libspdk_thread to libspdk.so (Daniel Verkamp) [16:46:33] Diff URL: https://github.com/spdk/spdk/compare/58b02f47a001...b5ed37ed0ec8 [16:46:33] *** Parts: travis-ci (~travis-ci@ec2-54-162-149-177.compute-1.amazonaws.com) () [17:36:58] *** Quits: lyan (~lyan@2605:a000:160e:2124:4a4d:7eff:fef2:eea3) (Quit: Leaving) [17:39:57] *** Quits: philipp-sk (~Philipp@ktnron0916w-lp140-04-65-92-69-234.dsl.bell.ca) (Ping timeout: 260 seconds) [18:34:25] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [18:39:24] *** Joins: dlw (~Thunderbi@114.255.44.143) [22:57:14] *** Joins: pohly (~pohly@p5484976F.dip0.t-ipconnect.de) [23:38:16] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-lzwewpyfdjlspvbw)