> 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.
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.
YAMAMOTO Takashi
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
