On Tue, 23 Jul 2013 10:32:25 +0900 (JST) [email protected] (YAMAMOTO Takashi) wrote:
> > On Tue, 23 Jul 2013 08:08:08 +0900 (JST) > > [email protected] (YAMAMOTO Takashi) wrote: > > > >>> On Mon, 22 Jul 2013 09:14:38 +0900 (JST) > >>> [email protected] (YAMAMOTO Takashi) wrote: > >>> > >>>>> On Fri, 19 Jul 2013 15:32:05 +0900 > >>>>> YAMAMOTO Takashi <[email protected]> wrote: > >>>>> > >>>>>> this set includes of-wire json tests and > >>>>>> fixes for problems found by the test. > >>>>>> > >>>>>> changes from the previous post includes: > >>>>>> - bug fixes > >>>>>> - add missing tests for some messages > >>>>>> OFPTableFeaturesStatsReply > >>>>>> OFPPortDescStatsRequest > >>>>>> OFPPortDescStatsReply > >>>>> > >>>>> Hmm, looks like some json is odd. For example, OFPTableFeaturesStats > >>>>> doesn't have 'length' (_length instead). However, struct > >>>>> ofp_table_feature in the spec has length so OFPTableFeaturesStats > >>>>> should have too. > >>>> > >>>> i didn't include OFPTableFeaturesStats.length because > >>>> it's redundant and would be calculated by the serializer to match > >>>> with the actual size of properties anyway. > >>>> (well, once a real serializer is implemented for these messages. > >>>> as OFPMatch.length is calculated from its fields.) > >>> > >>> How about parser side? > >> > >> i think that what a consumer of these is interested in is > >> len(OFPTableFeaturesStats.properties), not OFPTableFeaturesStats.length. > > > > I think we had better convert the on-wire data strcuture strictly > > rather than guessing what someone is interested. > > it's redundant and merely a detail of encoding. > IMHO it just confuses users. but i can follow you... > > do you want other length/len fields too? > should they be named as per spec? ("length" for some and "len" for others) > > are other field omissions ok for you? (type, pad, reserved) I want to stick with the structures defined in the specs (IOW, C header files from ONF). This feature might be used for various purposes. I think that the best thing we can do is just dumping stuff between a controller and a switch. About serialize side, our serializer should calculate the length. Some our packet library protocols work in such way. > talking about on-wire strictness, do you want ofp_match parser preserve > the order of match fields? i'm proposing a new match field query api, > which is dict-like and thus loses the ordering infomation. It would be better if we could preserve the order. It would depends on how complicated this makes the implementation, I guess. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
