15:52:24 #startmeeting fdio vpp 15:52:24 Meeting started Tue Feb 28 15:52:24 2017 UTC. The chair is DaveBarach. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:52:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:52:24 The meeting name has been set to 'fdio_vpp' 16:02:15 #topic CSIT - Jan G. reporting 16:02:30 #info preparing tests on CentOS 16:03:15 #topic Honeycomb - Marek sent in status by email 16:03:31 #info Done proxy Arp/SNAT/DHCP updates 16:04:29 #info In progress: v3po.yang model split (follows vpe.api split); 16:04:32 https://rt.linuxfoundation.org/Ticket/Display.html?id=36808 16:04:36 #info In-progress: policer yang model discussion; 16:04:58 #info In-progress: BGP in HC discussion 16:05:49 #info Dave Wallace 16:08:17 #info In-progress: support for Yang model... 16:08:42 #topic NSH-SFC - no reporting 16:08:54 #topic LISP - Florin reporting 16:09:12 #info made API changes 16:10:39 #info will be completed with API changes by next week's freeze 16:10:57 #topic DPDK packaging - Tom H. reporting 16:11:20 #info making progress. merging patches to DPDK 17.02. 16:12:25 #info next step is to build vpp rpm.. so dependency is based on dpdk rpm 16:15:41 #topic Plugin API message numbering, tracing - Dave B 16:15:55 #info Please implement pretty-print / custom-dump fns in plugins! 16:16:25 #topic Loopback create API discussion - Dave B 16:16:38 #info important for control plane 16:16:42 #info Add config parameter to change loop%d to Loopback%d (interface naming) 16:16:58 #info Add new api ("create_loopback2" or some such) w/ instance number control 16:17:02 #info Deprecate current API in 17.07 16:18:55 #agreed group in agreement with oopback create API discussion 16:19:14 #agreed group in agreement with loopback create API discussion 16:26:16 #action DB to write-up a paragraph re loopback create API discussion and send to vpp-dev mailer 16:27:54 #topic Maintainers file - Damjan reporting 16:28:18 #link https://gerrit.fd.io/r/#/c/5547 16:30:52 #info starting file, not a file. folks can nominate themselves during commits 16:31:14 #action Damjan to send maintainers file gerrit to vpp-dev 16:31:34 #topic Infra - Vanessa reporting 16:32:50 #info 17.01 - Damjan 16:32:56 #topic 17.01 - Damjan 16:33:14 #info started the rebuild process for 17.01. will publish soon 16:33:17 Hey Jong: pls #endmeeting at some point, and add entries to the Meeting Minutes page 16:33:28 will do 16:34:41 #info VPP Jira dashboard aligned with maintainers file 16:35:04 #link https://jira.fd.io/secure/Dashboard.jspa?selectPageId=10700 16:36:36 #topic Coverity report 16:37:09 #link https://scan.coverity.com/projects/fd-io-vpp 16:37:20 #topic issues 16:45:17 #info doxygen issue/limitation wrt interpolated macros... there's work around (fixed string..) 16:46:17 #endmeeting 16:46:31 if dave didn't make you a chair, that won't work 16:46:48 ok... 16:47:07 also, there is already a jira for that issue 16:47:26 #info inerpolation issue recorded at https://jira.fd.io/browse/VPP-417 since september 19:11:51 * jdl blinks 20:04:35 * jdl blinks 20:40:34 oletroan: So, if there is a config flag to indicate "loop%d" or "Loopback%d" style names, would that flag be per-interface, or one global-ish for all loopback interface names? 22:40:39 JDL: Hmm… So these names are only visible and used through the debug CLI? This isn't something communicated across the API? Would you expect other interface names to follow the same generic style? 22:41:15 The names are more than just debug info. 22:41:35 They form expect user-level names for future commands. 22:41:50 That's why they need to be predictable and not dynamically allocated. 22:42:03 Right, but only for the debug CLI? 22:42:16 No. 22:42:24 This ha nothing to do with VAT. 22:42:30 Or vppctl. 22:42:44 Where are the names used? 22:42:53 In *my* CLI. 22:43:09 Aha, then it's up to you isn't it. ;-) 22:43:18 No, that is just it. 22:44:33 Dave suggests a single flag indicating the base name for all devices of a class. 22:45:40 In the same way that the bridge Ids can be specified, we need to have definite loopback instance names as well. 22:46:18 Pondering… If you are writing your own control plane on top of VPP, you can just use interface indices no? 22:46:30 And call "create loopback interface 15" 22:46:43 how you represent a name for "15" is your choice, no? 22:46:50 You can't specify 15. 22:47:07 right, today you can't, but that's what you need right? 22:47:20 as opposed to "create an interface, return me the if index" 22:47:20 Yes, that is half of it 22:48:03 Its not sw_if_index, though. 22:48:07 Please explain the other half again. I may be a little slow. 22:48:36 When a user types "interface loopback 4", the expected future name used is "Loopback4". 22:48:51 It has to show up in interface dumps as "Loopback4". 22:49:01 And it might be sw_if_index 20 22:50:04 Right but in the interface dump, you get 20, and you do the mapping in your control plane to the string, right? 22:50:10 Right now, one says "create loopback", and has to know that it will be "0". 22:50:27 And if you do "create loopback" again, it will be "1". With name "loop1". 22:50:39 Why do you care about the name is what I'm trying to get at? 22:50:55 Because future commands need to reliably reference it by name. 22:50:57 Assuming you are writing a new separate CLI that accesses VPP through the binary API.... 22:51:16 The binary API returns interface names in a "dump" request too. 22:51:30 True… 22:51:46 Perhaps not having that and making it a completely local to the control plane entity would have been cleanest. 22:52:03 DPDK prenames the IFs it finds. 22:53:01 Cause it would be unfortunate if we had to maintain multiple name representations inside of VPP. e.g. if you need loop%d and Loopback%d… 22:53:22 Yes. 22:54:07 Dave suggested a config flag to select one for this running instance of VPP... 22:54:21 Could come from vpp conf file, or API call. 22:55:09 How would you have solved your problem if VPP didn't expose interface names? Just interface properties / instance #? 22:55:43 I'd have to manage a separate name/index table, of course. 22:55:59 (It might be Dave's proposal is the best, and it isn't many lines of code either way, I was just wanting to explore the solution space). 22:56:18 Don't you need that anyway? Since most of the API calls require if index and not name. 22:56:21 But that would make DPDK named interfaces be different too. 22:56:36 True 22:56:51 Those translations are obtained via table dynamically built by "dump" results. 22:57:16 So not really a table I manage. :-) 22:57:31 You could certainly map those names into prettier names for your purpose. 22:58:02 Needless to say, the DPDK style names are IOS-ish, which is precisely what we need. 22:58:42 Or just do a s/loop/Loopback in the VPP code. ;-) 22:59:06 Sure -- but it will break existing code! 22:59:20 I'm happy to take the s/loop/Loopback and be done with it. 22:59:38 But it requires agreement from the entire VPP crew, code, and tests. 22:59:52 Does it also affect something external? Don't know. 22:59:55 In principle though, I'd really prefer no-one to deal programmatically with interface names. If index should be used. 23:00:27 totally agree in principle. 23:01:05 But I'd still need to be able to specify the user-level name for the interface. 23:01:13 Same for ACL sets too. 23:01:15 Yep 23:01:17 Same for bridges. 23:01:36 Is this written in a higher level language using one of the language bindings? 23:01:49 All C. 23:01:56 Poor you. ;-) 23:02:00 LOL 23:02:21 This is the highest level I've programmed in decades! 23:02:33 this is *user* space! 23:03:15 If the API gave you a set of classes of interface and then you mapped classes into names, e.g. loopback -> Loopback, 10base2 -> ThickYellowCable 23:04:06 Might work. 23:04:42 But I'd still have to specify the instance being created somehow. 23:05:14 You could make a local mapping of that too? 23:05:19 And the expected behavior is a number. So at the least that would impose a int->int mapping. 23:06:13 Cause you have a static configuration of Loopback4 and you connect that CP to VPP and want to recreate a loopback interface 4 23:07:10 I've not yet pried the rock off the tap-tun mechanism, but we will get there too. 23:07:22 And we'll have to agree with the Linux host at some level for sure. 23:07:51 It's not out of the question to need to agree with the FreeBSD host at some point as well. 23:08:27 oh… you want names that match whatever a local host representation is of those names? 23:08:27 Technically "local0" fits into this mess as well. 23:08:29 Whee! 23:08:55 Yeah, then I'd really like you to pretend that VPP doesn't have interface names. ;-) 23:09:11 LOL. RIght? 23:15:19 Good luck! Must get to bed. Have fun and let us know how it goes. 23:15:59 Thanks! 02:48:38 jong: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 02:48:54 #endmeeting