On Thu, 25 Jul 2013 09:53:54 +0900 (JST) [email protected] (YAMAMOTO Takashi) wrote:
>> 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. > > what matters here is api, not implementation. > i can implement either way if you want. As we talked off-line, I like the former API. I meant the former API with the preserved order, that is, the order of fields can be accessed when necessary. > i guess unordered api is easier to use. (it's what i posted on this ML.) > > match = OFPMatch(in_port=1, eth_type=0x86dd) > assert match.get('in_port') == 1 > assert match.get('eth_type') == 0x86dd > > an api preserving order would look like the following, i guess. > > match = OFPMatch([('in_port', 1), ('eth_type', 0x86dd)]) > assert match[0] == ('in_port', 1) > assert match[1] == ('eth_type', 0x86dd) > > if it really matters, we can support both of the above apis. > i don't think it worth the effort, though. ------------------------------------------------------------------------------ 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
