On Tue, Mar 29, 2016 at 1:09 AM, Iwase Yusuke <[email protected]> wrote: > Hi, > > > On 2016年03月29日 05:44, Jason Kölker wrote: >> >> Paramaterizes type converions in function to allow calling code to >> specify if responses should be converted to user friendly display >> (strings) or type perserved. >> >> Signed-off-by: Jason Kölker <[email protected]> >> --- >> ryu/lib/ofctl_v1_3.py | 296 >> ++++++++++++++++++++++++++++++++++++-------------- >> 1 file changed, 212 insertions(+), 84 deletions(-) >> >> diff --git a/ryu/lib/ofctl_v1_3.py b/ryu/lib/ofctl_v1_3.py >> index 9c72c1e..09bb549 100644 >> --- a/ryu/lib/ofctl_v1_3.py >> +++ b/ryu/lib/ofctl_v1_3.py >> @@ -434,7 +434,14 @@ def match_vid_to_str(value, mask): >> return value >> >> >> -def get_desc_stats(dp, waiters): >> +def wrap_dpid_dict(dp, value, to_user=True): >> + if to_user: >> + return {str(dp.id): value} >> + >> + return {dp.id: value} >> + >> + >> +def get_desc_stats(dp, waiters, to_user=True): >> stats = dp.ofproto_parser.OFPDescStatsRequest(dp, 0) >> msgs = [] >> ofctl_common.send_stats_request(dp, stats, waiters, msgs, LOG) >> @@ -447,11 +454,11 @@ def get_desc_stats(dp, waiters): >> 'sw_desc': stats.sw_desc, >> 'serial_num': stats.serial_num, >> 'dp_desc': stats.dp_desc} >> - desc = {str(dp.id): s} >> - return desc > > > (This is a scope of the existing code though.) > > I wonder if users want to get the dpid in the response. > I guess users already know the dpid because the dpid is required in the > request parameters. > > What do you think about it?
From a REST api perspective I like having the result wrapped in a dict keyed off the dpid, from other applications that would call into it, having it wrapped in a dict like this will also allow us to support batched requests for multiple dpids at a time. Although that's a bit of a stretch, as I would assume that calling code would prefer it to run in multiple threads for each dpid. Currently we have an app whose api unrolls the wraped dict, automatically. The manager for it is a subclass of ofctl_rest.RestStatsApi that just disables the write operations, as we want all modifications of the member switches to go though our own api so we can limit the entry points into switch modifications. The only other modification is using our event register handlers that force spawning handlers in events. Here is a gist of it currently: https://gist.github.com/jkoelker/5881419aa6a1ad4f5251 My eventual goal is to decouple the datapath stat gathering from ofctl_rest into a new app, so that any app that needs to read items from the datapath can have a reusable entrypoint to do so. But as that is a much larger refactor, and this diff already was pretty large, I decided to send it out as is now to get some of the groundwork reviewed. Happy Hacking! 7-11 ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
