Actually, during the CSIT weekly call yesterday there was mentioned a missing VPP api for "show run".
I think I even found a jira for it : https://jira.fd.io/browse/VPP-55 <https://jira.fd.io/browse/VPP-55> It seemed like no one was working on it, and so I had a look. In the ticket, Dave Barach suggested to add this to the get_node_graph api function which is why I went there. If you could add the infos from "show run" into your dev, this would be great. Otherwise I can work on it after you've finished. There's no rush. Regards, -- Gabriel Ganne ________________________________ From: Luke, Chris <chris_l...@comcast.com> Sent: Thursday, November 30, 2017 2:39:02 PM To: Gabriel Ganne; Ole Troan Subject: RE: [vpp-dev] api functions using shared memory What data for each node are you looking for? So I can make sure it ends up included. The existing get_node_graph is fairly limited in what it retrieves aside from the adjacencies and a handful of stats. My approach right now, to keep it simple, is to use the _dump/_details mechanism to return a list of items that encode the thread index and node index with the other details in a pretty flat structure; this should then be easily consumed by any binding. For Python I’ll also provide a way to reanimate the data into a fairly simple object model. You can see the first pass of my work at https://gerrit.fd.io/r/#/c/9222/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=xpknLc81XbQlb0xvMXmP6LdQAhC9C-WkmvMZX_MyITOJvHIiAsAxybY7ldR6DsgpJ5FCoNL3Jo2iG9YbBigZEerbiFmF2qB-jovMxvNhAjOt69WE34BtnoQEXB6493yuyST9yzhnu_Z63w0ImBcsUPpNN_mdDmLi0RcARoD6KR9aixyc9umJ7hxu3Q6Y-EsWzzp2V9LnUIzwkWhK1lR6fEK1F0gwkYO9hqjl_PyjipY> and the two patches leading up to it which exposed a mechanism to interpret the result_in_shmem from Python and dezerialize into an object model. Ole rightly objects to using shmem, though I think there is still merit in merging the basic shmem reader since, while the mechanism exists in the API, we should support it where we can. Otherwise we should remove it from the API altogether. My current work on this I expect to have cleaned up and usable in a few days, though I’m travelling next week (Kubecon) which may interrupt things if I don’t make enough progress this week. Chris. From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Thursday, November 30, 2017 7:47 AM To: Ole Troan <otr...@employees.org>; Luke, Chris <chris_l...@cable.comcast.com> Subject: Re: [vpp-dev] api functions using shared memory Great ! Thanks. -- Gabriel Ganne ________________________________ From: Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> Sent: Thursday, November 30, 2017 12:50 To: Gabriel Ganne Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] api functions using shared memory Gabriel, > I am looking at the get_node_graph() api function, for use in python. > It returns a u64 reply_in_shmem value which points to the shared memory and > must then be processed by vlib_node_unserialize() (as is done in vat) but I > only saw such a function in C. > Is there any way to do this in python ? (other languages should have the same > issue). > > Also, I had a look at the the cli api function (which works the same way) and > saw that it had an cli_inband version which apparently was designed to > replace the cli api function because it was using shared memory > (https://gerrit.fd.io/r/#/c/2575/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=9lLDLNFIPw66omxD7Xax5tRUJNBd1qBZ0kxnVJ1-awHNTm2422SYts4YSy-uiYv-sIkxnmVM_AUhU5ffVfWJwXzdtn-FQcePME2XF4G4td9Ry9_yZTXJOVLj-uUyvUQJOFHEKDnb-QuZgYoYAo5qN0hHRrE03NUG8B-FccnprFXO-5lHSBuhJXFJS2Burywj_iD1TCOzaF0ybCtKzKgSDgOjtP9XhQ51M3FpinXrAHg>) > Should the get_node_graph api function also get an *_inband version ? Yes. That's also a prerequisite for alternate transports like the socket API. I think Chris is working on it. Cheers, Ole
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
