Thanks all for the helpful comments and interesting insights into the OF
protocol and its semantics.
It seems like a reasonable course of action for the monitoring component
I'm working on would be to focus on setting and retrieving the xid to at
least be aware of any stats reply losses or delays. Next steps include:
1) Parse the xid on Ofp_msg_event and export it to Python via swig so
that the monitoring component (and other python components) could
reference it. (this step involves patching NOX see NOX change
guesstimate below)
2) Add a python method to the monitoring module that constructs a stats
request message and sets the xid (so it can be referenced later to at
least detect whether any responses were lost/delayed)
3) Have the monitoring component send a barrier message (if the switches
support it) between stats requests destined for a switch to coerce
in-order processing/responses.
---begin guesstimate of NOX changes that I will make and test-----
re: patching NOX to export xid on Ofp_msg_event (not completely sure
about the "right" way to do this so I may be missing key steps but
here's a stab based on looking @ the code).
1) edit src/include/Port_stats_in_event.hh and add an uint32_t xid
variable there (or a get method for it) in the Port_stats_in_event struct:
struct Port_stats_in_event
: public Event,
public Ofp_msg_event
{
Port_stats_in_event(const datapathid& dpid, const ofp_stats_reply
*osr, std::auto_ptr<Buffer> buf);
// -- only for use within python
Port_stats_in_event() : Event(static_get_name()) { }
static const Event_name static_get_name() {
return "Port_stats_in_event";
}
//! ID of switch sending the port stats message
datapathid datapath_id;
//! Added xid - rean-g
uint32_t xid;
//! List of port statistics
std::vector<Port_stats> ports;
Port_stats_in_event(const Port_stats_in_event&);
Port_stats_in_event& operator=(const Port_stats_in_event&);
void add_port(uint16_t pn);
void add_port(struct ofp_port_stats *ops);
}; // Port_stats_in_event
2) modify the ctor implementation Port_stats_in_event(const datapathid&
dpid, const ofp_stats_reply *osr, std::auto_ptr<Buffer> buf);
to access to xid field in the ofp_msg structure inherited from
Ofp_msg_event (src/include/ofp-msg-event.hh)
inline
Port_stats_in_event::Port_stats_in_event(const datapathid& dpid,
const ofp_stats_reply *osr,
std::auto_ptr<Buffer> buf)
: Event(static_get_name()), Ofp_msg_event(&osr->header, buf)
{
datapath_id = dpid;
//! Copy xid from inherited ofp_msg_event rean-g
xid = this->ofp_msg->xid;
}
3) modify the event conversion to python (src/nox/coreapps/pyrt/pyrt.cc):
static void convert_port_stats_in(const Event& e, PyObject* proxy) {
const Port_stats_in_event& psi
= dynamic_cast<const Port_stats_in_event&>(e);
pyglue_setattr_string(proxy, "datapath_id", to_python(psi.datapath_id));
//! Added xid into conversion to python - rean-g
pyglue_setattr_string(proxy, "xid", to_python(psi.xid));
pyglue_setattr_string(proxy, "ports" ,
to_python<vector<Port_stats> >(psi.ports));
((Event*)SWIG_Python_GetSwigThis(proxy)->ptr)->operator=(e);
}
thanks,
Rean
kk yap wrote:
> Hi,
>
> I am taking the rest of this discussion off the list. Drinks with
> everyone on nox-dev is not very scalable, and I would like to keep
> this option open. :P
>
> Regards
> KK
>
> On 9 March 2010 09:43, Ben Pfaff <[email protected]> wrote:
>> On Tue, Mar 09, 2010 at 09:38:47AM -0800, kk yap wrote:
>>>> I'm not aware of wording that says a switch may simply ignore a
>>>> command. The transport is TCP (or SSL on TCP), so nothing is going to
>>>> get accidentally lost.
>>> We are saying the same thing. I said "there is nothing in OpenFlow
>>> that dictates reliable execution of commands received" and you are
>>> saying "there is nothing in OpenFlow that dictates unreliable
>>> execution". In that case, guess what is the minimum acceptable
>>> behavior? :)
>> I guess you read between the lines in a funny way. If I write a
>> specification that says "command A does B and returns C" and I don't
>> also write in that specification "command A always does B and returns
>> C", then I guess you would assume that it is OK for command A to do D
>> and return E or to not do anything at all?
>>
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
