[ovs-dev] [openflow-dev] [code] OFTest for OVS

Ben Pfaff blp at nicira.com
Fri Oct 26 18:28:36 UTC 2012


On Fri, Oct 26, 2012 at 09:24:54AM -0700, Dan Talayco wrote:
> I know there are still some rough edges with OFTest, but there are a number
> of changes that have improved things (the control-C issue is a lot better
> than it was, but still present in some situations) and we continue to make
> progress (especially with contributions like yours).

I hope that my message didn't sound too much like criticism of OFTest.
If I'm criticizing anything, it's that OFTest is a little hard to get
up and running, because of the specific issues that I'm trying to
address with the code that I've written.  Those issues are the main
reasons that we've never really even tried OFTest against OVS.

My goal here is to, from an OVS tree, be able to just type "make
check-oftest" and have OFTest run against the OVS build tree without
any further setup.  That's not much more work than I've already done.
If OFTest is this easy to run, then we (speaking mainly of myself)
will be more likely to run it.

> Locally, we've been working on a port virtualization tool that allows
> things like virtual connections across UDP sockets, etc.  What we have is
> not quite ready for prime time, but I expect your domain socket approach
> should provide some push forward in that.

What kind of protocol are you using?  (Or perhaps no protocol at all,
just raw Ethernet frames over UDP?)  My choice of Unix domain stream
sockets is not essential, although it's convenient on the OVS side,
but it does require a tiny protocol definition (each Ethernet frame is
preceded by a 2-byte length field).

> One more note:  We are also reviewing how to better compartmentalize and
> specify for execution sets of tests ("suites").  There are a number of
> things (like the "emergency flow cache" tests) that have been put in but
> generally aren't implemented by anyone (as the feature was mostly
> discredited before it went into 1.0 and then remove by 1.1).
>
> As the number of contributed tests is growing, there have been calls for a
> base set of "compliance" tests.  While defining compliance is not in the
> scope of OFTest, I'd like to have a default set of tests that maximally
> satisfies (1) as much coverage as possible; and (2) agreement that the
> tests cover implemented and useful features.
> 
> Easy definition, maintenance and selection of other test suites is the next
> goal.

All of that sounds like worthwhile goals.



More information about the dev mailing list