[ovs-dev] [PATCH] utilities: Add new pipeline generator script.

[Ethan Jackson]

> This is useful and I think we would like to use it here. I have a few questions.

Great!  I really hope this moves the community in the direction of
more realistic test cases.

> How come the pipeline is set up with metadata instead of a chain of tables
> as I presume that would also work?

I would expect both approaches to produce the same megaflows and
perform the same in the slow path, so it shouldn't really matter
either way.  That said, there are some minor aesthetic reasons I
choose to go with metadata.  (1) there are only 256 tables, sounds
like a lot but when you start stringing simulated middleboxes together
in a service chain, it's easy to run out.  (2) our internal NSX
controller uses metadata instead of multiple tables, so I'm used to
it.

At any rate, doesn't matter much, if you feel strongly about it feel
free to change it.

> There are a lot of destination ip addresses. What is the use case this is simulating?
> I can't imagine there would be that many mac addresses on the hypervisor unless
> it was hosting containers?

When I wrote this test case, I was imagining OVS being used as more of
a firewall/router in the core of the datacenter, rather than as just
the hypervisor vswitch.  We commonly use OVS as a gateway between and
overlay network using network virtualization, and the WAN.  In this
case OVS is responsible for routing over many many IP addresses (1 per
VM in the datacenter typically).

That said, for the typical NFV case, perhaps it's a bit overkill.  We
can always add more test cases if you'd like.  Then again, I suspect
most NFV workloads would benefit greatly if basic routing/firewalling
were offloaded to OVS rather than done in VMs.

> You talk about network virtualization workloads but it doesn’t do any matching on,
> for example, vlan vid or vxlan tunnel ID?

Yep, it would make a lot of sense to add in tunneling support.  I
don't suspect it would matter much, but hard to say without testing it
=).

To be super clear, I don't consider this script the definitive best
case benchmark we could do.  I just wanted to take a step away from
trivial port to port forwarding tests.  I.E. I'm not claiming this is
realistic, just more realistic than what we were doing before.  I
really hope that as a community we can get behind it and evolve it
into something much more realistic as time goes on.

> This would be quite necessary! Can you give an idea what kind of flows
> we should be generating to test it or is it just random ip, mac addresses and l4 ports?

So for now I've been running through it a couple of packet traces I've
collected which, unfortunately, I can't share publicly.  I had been
planning to write a script which can generate "realistic" packet
traces for doing this sort of testing based on the types of things
I've seen in the traces I've collected, but I haven't quite gotten to
it yet.

Ethan