[02:34:49] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [07:54:49] pwodkowx: are you up for doing the DPDK 18.02 integration? [07:55:45] what do you mean "up" :P I'm awake :) [07:55:59] Are you asking if we tested 18.02 with SPDK ? [07:57:47] I am asking if you could do the patches to (1) create an spdk-18.02 branch in our dpdk repo and (2) add the SPDK patch to move to using that branch [07:58:19] or someone else from your team there [07:59:24] sure. I can do this on monday. [07:59:58] awesome - thanks! [08:18:38] about (1): I think somone (drv?) need to pull DPDK 18.02 to SPKD github, then I can do (2) [08:24:42] drv: can you take care of ^^^^^ ? [08:26:19] nice alignment ^ [08:54:49] looks off by one to me :) [09:01:04] ok, I've synced spdk/dpdk with the upstream repo, and I've created the spdk-18.02 branch [09:01:18] should be ready for reviews on gerrithub [09:08:17] thx [09:36:57] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Ping timeout: 264 seconds) [10:12:07] *** Joins: peluse_ (~peluse@2600:8800:1407:cb00:8c70:3de0:4498:a398) [10:12:29] *** Quits: peluse_ (~peluse@2600:8800:1407:cb00:8c70:3de0:4498:a398) (Client Quit) [10:29:02] *** Joins: Param (~Param@157.49.164.186) [11:15:28] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [11:17:03] Hey guys. Looking at the spdk.io/roadmap page, the contents of the CHANGELOG.md (which I'm editing), and a listing of the git tags, then noticed mention on here (the IRC) of 18.02. Can I get some insight about that? That is, do I understand correctly that there will be an 18.02 release prior to the roadmap'd 18.04 one? If so, I'd want to insert a 'v18.02' section in the CHANGELOG.md assuming my forthcoming changes are accepted and i [11:17:03] ncorporated in time. [11:17:22] the version numbers get a bit confusing, sorry :) [11:17:29] 18.02 is referring to DPDK 18.02 [11:17:37] the next SPDK release will be 18.04 [11:17:42] Oh, ok, gotcha. Thank you! [11:40:59] *** Joins: darsto- (dstojacx@nat/intel/x-bczabezhxcbwupme) [11:42:30] *** Joins: kjakimia_ (kjakimia@nat/intel/x-rickipsrswdxfvkp) [11:44:46] *** Quits: kjakimia (kjakimia@nat/intel/x-iofgfkeidnivqzet) (*.net *.split) [11:44:47] *** Quits: darsto (dstojacx@nat/intel/x-wmnfqsyaizfqgklj) (*.net *.split) [11:44:50] *** darsto- is now known as darsto [11:44:55] *** kjakimia_ is now known as kjakimia [11:45:25] *** darsto is now known as Guest60329 [12:18:33] I pushed a changeset, but inspection of the https://ci.spdk.io/status/ suggests that the TP is idle and yet my submitted code isn't being built. I thought once submitted, code was enqueued for automatic build/test. Does someone have to perform some kind of nudge to get it going? [12:29:56] lhodev: there's a whitelist for patch authors, and if the submitter isn't on the list, the patch needs to be manually reviewed and approved before it runs [12:29:59] I've approved your patch now [12:31:55] Thanks Daniel. Are such "whitelisted patch authors" the one and the same as those with +2 voting capabilities? Or are those intersecting sets? [12:40:11] Different type of list actually [13:22:16] *** Quits: Param (~Param@157.49.164.186) (Quit: Param) [13:22:46] *** Joins: Param (~Param@157.49.164.186) [13:24:04] *** Quits: Param (~Param@157.49.164.186) (Client Quit) [13:44:25] drv: there are two patches starting here that could use another review https://review.gerrithub.io/#/c/400201/ [13:45:03] if the names are OK with you, I'm happy with them [13:45:29] ok with me [13:48:29] there's one more here (or maybe you're still reviewing it) https://review.gerrithub.io/#/c/400928/ [13:50:58] yeah, sorry, I got sidetracked looking up the iSCSI spec to see if any of these names are from there [13:51:57] it does say "mutual authentication" rather than "mutual CHAP", but I guess in practice that is the only kind of authentication we care about [13:52:55] and I guess AuthGroup is our own invention, not part of the spec [14:07:13] Hey folks, can I get some input on the behavior of spdk_app_parse_args()? Currently, if one passes in a '-h', the routine will call exit(0), and there's at least one test that expects that behavior. I'm working on the effort of eliminating (wherever possible) calls to exit() with lib routines. Hence, on a '-h', instead of calling exit(0), I'd return a non-zero to indicate failure. That's interfering with the test of args, for examp [14:07:14] le, in test/vhost/other/negative.sh. Is this a special case where folks here think we might want to retain this behavior of spdk_app_parse_args() invoking exit()? Or, perhaps, shall I test for a special return value for this case and direct the callers to spdk_app_parse_args() to in turn exit(0) upon receipt of this special return value resulting from passing in a '-h'? [14:08:32] yeah, adding a new special return value to indicate "exit with success" might be the best way to go [14:09:00] maybe spdk_app_parse_args() should return < 0 for error, == 0 for success, and > 0 for "printed usage, exit with success"? [14:09:34] or maybe an enum with values for each of those cases would be clearer [14:13:15] drv: That was what I was thinking. Thanks. [14:13:43] it does mean that we need a little extra boilerplate in each app that calls it, but I think that's OK for this case [14:20:00] One additional fine point: the current implementation of spdk_app_parse_args() exit()'s with 0 for '-h' and 1 for '-?'. Is there precedence for that? In my mind, I've always equated the behavior of '-h' and '-?'. [14:25:10] that seems like an oversight - we should make them both return 0 [14:38:53] oh, just FYI, with a few ptrs from drv I'm able to build/ink the dpdk fw for crypto and call relevant APIs from my fledgling crypto vbdev... can't get a virtual pmd created yet but progress nonetheless ) [14:39:38] nice! [14:42:38] yeah, I'll be mixing up my bytes left and right before you know it... nothing new there! [15:21:13] *** Joins: ozcdchapm2 (~ucihk@186.64.126.146) [15:21:24] _ _ _ _ _ _ _______ _______ _______ _______ [15:21:29] ( ) ( ) ( ) ( ) ( \ ( \ ( ___ )( )( ___ )( ____ \ [15:21:35] _| |_| |_ _| |_| |_ | ( | ( | ( ) || () () || ( ) || ( \/ [15:21:37] (_ _ _)(_ _ _)| | | | | (___) || || || || (___) || (_____ [15:21:41] _| (_) |_ _| (_) |_ | | | | | ___ || |(_)| || ___ |(_____ ) [15:21:46] (_ _ _)(_ _ _)| | | | | ( ) || | | || ( ) | ) | [15:21:51] | | | | | | | | | (____/\| (____/\| ) ( || ) ( || ) ( |/\____) | [15:21:53] (_) (_) (_) (_) (_______/(_______/|/ \||/ \||/ \|\_______) [15:22:01] ##LLAMAS [15:22:08] kjakimia Guest60329 gila sethhowe lhodev sage___ pbshah1 pzedlews lgalkax klateck vermavis cunyinch jimharris pwodkowx pawelkax jkkariu ziyeyang qdai2 gangcao changpe1 pniedzwx darsto_ stefanha bwalker guerby drv nKumar jstern peluse mszwed ppelplin tsg [15:22:10] *** Quits: ozcdchapm2 (~ucihk@186.64.126.146) (Client Quit) [15:22:27] I agree [16:12:01] drv, looks like I need some new options when init'ing EAL. Should I start by just hacking what I need into struct spdk_env_opts? [16:14:21] probably ok to start [16:14:23] what kind of optionS? [16:17:31] see section 2.4 in http://dpdk.org/doc/guides-17.11/cryptodevs/aesni_mb.html [16:18:31] the example they show includes a mandatory one and a few others we'll want. This is how the PMD for AESNI is created for me to use [16:30:21] hmm, that kinda sucks - is there no way to create these programmatically? [16:32:29] oh, it looks like you can call rte_vdev_init("crypto_aesni_mb") - maybe that would be easier than adding it to the command line [16:33:05] yeah - surely you can pass those parameters to that call? the example just shows the string [16:34:33] http://dpdk.org/doc/guides-17.11/prog_guide/cryptodev_lib.html [16:35:11] rte_vdev_init("crypto_aesni_mb", [16:35:12] "max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0") [16:36:06] is this section in the aesni_mb doc still correct? you have to manually download and install https://github.com/01org/intel-ipsec-mb to get it to work? [16:38:08] drv, yeah I already did that [16:38:23] that's gonna be a mess to integrate into our build system [16:38:25] i thought that was a bummer [16:38:42] jimharris, that's what I tried and then asked on #dpdk why I was seeing an empty device list and was told that the EAL options needed this stuff for the PMD to be present [16:39:05] the init call you metion apparently initialized it but it's not present to init unless created when EAL was init'd [16:39:08] so they're saying rte_vdev_init doesn't work? [16:39:16] no [16:39:29] that sucks [16:39:29] they said "you need to init with these EAL options" first [16:39:32] yeah [16:39:57] hmmm [16:40:20] dunno, just tellin ya what I understand so far... [16:40:22] for testing, you could just unconditionally add that option to spdk_build_eal_cmdline(), but we'll have to come up with something better than that for the long term [16:40:32] agreed [16:40:34] once I pass those in to eal_init we'll see if I see a device [16:41:21] as of now when I call rte_dev_init() it returns -1, I stepped though it and the reason is because there's an internal device list that it's hunting through to find what I passed in, in my case there's nothing on the list [16:41:34] (apparently because I didn't init EAL with any devices) [16:42:04] if you call rte_vdev_init() before we do DPDK initialization, does that work? or if you could find out if that works, that would be nice [16:42:38] is that even possible? aren't all rte* calls DPDK calls? [16:43:22] yes - but i thought you said the #dpdk guys indicated if you want rte_vdev_init() to work that you have to call it before rte_eal_init()? [16:43:40] or do you have to do both - pass parameters to rte_eal_init() and later call rte_vdev_init()? [16:45:04] what you said last is how I understood it [16:46:59] but I haven't tried much of anything yet beyond just calling rte_vdev_init() so will mess around some more [16:49:27] looking at how rte_vdev_init() is called in dpdk test code [16:49:34] it is definitely called after rte_eal_init() [16:49:43] rte_eal_init() is the first thing called in their unit test main function [16:53:30] certainly looks like you should be able to just pass NULL as the second parameter too and use defaults [16:56:26] I'll let you know [17:03:23] bah... [17:03:24] Starting DPDK 17.11.0 initialization... [17:03:24] [ DPDK EAL parameters: hello_blob -c 0x1 --vdev=crypto_aesni_mb --file-prefix=spdk_pid72054 ] [17:03:24] EAL: Detected 88 lcore(s) [17:03:24] ERROR: failed to parse device "crypto_aesni_mb" [17:03:24] EAL: Unable to parse device 'crypto_aesni_mb' [17:03:25] Failed to initialize DPDK [20:17:54] *** Joins: Param (~Param@157.49.130.100) [21:21:53] *** Quits: Param (~Param@157.49.130.100) (Quit: Param) [22:10:54] *** Joins: Param (~Param@180.151.248.58)