Thanks for the quick reply!

Just to clarify (maybe I wasn't clear enough), my cbench also causes
simple_switch.py
to throw the same error as cbench.py. I simply didn't write anything about
it because I thought it was natural.

Regarding the negotiated version, I think that in the hello message, I'm
using a bitmap that says "support all version from 1.0 to 1.4". From the OF
spec, the negotiated version is the highest possible that both the switch
and controller support, right? So maybe cbench.py only supports 1.0 and my
cbench will still continue to send OF 1.4 messages. I attached a wireshark
extract if you want to check.

Unfortunately I don't have time to update the cbench.py to support 1.4 for
now. I think using the simple_switch_14.py will be enough. I'm also curious
by the lower results from simple_switch_14.py. In floodlight i experience
the opposite (cbench 1.4 reports better results than the original cbench).

Victor Orlikowski <v...@duke.edu> escreveu no dia quinta, 19/05/2016 às
19:36:

> On May 19, 2016, at 2:03 PM, André Mantas <andremant...@gmail.com> wrote:
> >
> > I'm updating cbench to emulate OpenFlow 1.4 switches (instead of 1.0)
> and I just tested it against Ryu.
> > I noticed that there's a "cbench.py" app that I suppose it is to be used
> when benchmarking Ryu. As I'm new to Ryu, I would like to know if I'm doing
> things right.
> >
>
> <snip/>
>
> I can't really comment regarding your numbers; I don't have any against
> which to compare, in order to tell you if they are "weird."
> I will say that I wouldn't expect that the 1.4 version of simple_switch
> would be that much slower than the 1.0 version of simple_switch...
>
> Let's look at the relevant lines from your backtrace below...
>
> <snip/>
>
> >   File
> "/usr/local/lib/python2.7/dist-packages/ryu/controller/ofp_handler.py",
> line 205, in switch_features_handler
> >     datapath.ports = msg.ports
> > AttributeError: 'OFPSwitchFeatures' object has no attribute 'ports'
>
> Looking at the lines around line 205 of ryu/controller/ofp_handler.py:
>
>         # hacky workaround, will be removed. OF1.3 doesn't have
>         # ports. An application should not depend on them. But there
>         # might be such bad applications so keep this workaround for
>         # while.
>         if datapath.ofproto.OFP_VERSION < 0x04:
>             datapath.ports = msg.ports
>         else:
>             datapath.ports = {}
>
> Had I to guess, your updated cbench is still reporting itself as being
> capable of OpenFlow protocol version 1.3 or earlier - but isn't *actually*
> doing the right thing to negotiate down and offer the expected feature set.
> That's the only way you would have caused an exception in that location.
>
> Furthermore, if you look at cbench.py, you'll see the following line:
> OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION]
>
> As well as:
>
> match = datapath.ofproto_parser.OFPMatch(
>             ofproto_v1_0.OFPFW_ALL, 0, 0, 0,
>             0, 0, 0, 0, 0, 0, 0, 0, 0)
>
> Note the dependencies on version 1.0 of the OpenFlow protocol.
> You'll need to update the cbench.py sample application to support 1.4
> properly, for this to work.
>
> I'm sort of surprised you didn't get this same exception from the 1.0
> version of simple_switch, though; you *ought* to have.
>
> TL;DR?
> Your updated cbench appears to be negotiating down to the lowest "common"
> version of OF (1.0) with the sample cbench app.
> This suggests that the problem is that your updated cbench is not
> providing things that are expected ("ports") in an OF 1.0 OFPSwitchFeatures
> response, even though it negotiated down to supporting 1.0.
> I'm surprised that the 1.0 simple_switch isn't also throwing an exception.
> I'm surprised that the 1.0 simple_switch results are so much higher than
> the 1.4 results.
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> vjo@[cs.]duke.edu
>
>

Attachment: cbench14_vs_ryu-cbench.pcapng
Description: application/pcapng

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to