[ovs-dev] Agenda for IRC neeting for 8/13 (Nithin Raju)

[Samuel Ghinet]

What I was testing against was ovs 1.9.3 and ovs 1.11

The fact is that, even for the latest version of ovs, there is no kernel port type = NORMAL or FLOOD (see enum ovs_vport_type). OFPP_NORMAL and OFPP_FLOOD exist in userspace only.
Therefore, you cannot have exactly the same handling of a flow that says "actions=normal" as one that says "actions=output:1".

Ben, could you please provide more detail, of what you mean?

Thanks!
Sam
________________________________________
From: Ben Pfaff [blp at nicira.com]
Sent: Friday, August 22, 2014 8:12 AM
To: Samuel Ghinet
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] Agenda for IRC neeting for 8/13 (Nithin Raju)

On Fri, Aug 22, 2014 at 01:55:13AM +0000, Samuel Ghinet wrote:
> port NORMAL and port FLOOD, unlike physical (i.e. ports corresponding to specific VMs or to external) or logical (GRE / VXLAN / etc.) are a userspace concept only.
> This means that, when a "ovs-ofctl add-flow br0 actions=normal" is issued,
> a) no kernel flow is created yet
> b) when a packet1 is coming that must go somewhere, the packet is queued to the userspace: a kernel flow will need to be created from userspace to handle this very specific packet (with all its specific frame fields info as keys, as I remember).
> c) when a packet2 is coming from the same dp port, that must go somewhere, the kernel will have a flow missed, because this packet is different than the previous one, and so it doesn't know what to do with it.
> d) this second packet is queued to userspace:  a kernel flow will need to be created to handle this very specific packet (with all its specific frame fields info).
> and it goes on an on, for very many other packets.
>
> On ports such as a port to a VM, or external, or GRE / VXLAN / etc., it goes like this:
> a) set the flow in userspace - no kernel flow created yet
> b) packet miss in driver => queue to userspace
> c) kernel flow created: handle packets mentioned as <key & mask>
> d) any new packet whose <key & flow mask> matches the kernel flow in kernel => execute actions (no more queue to userspace).
>
> This is how it worked, from experimentation, time ago. If, by any chance, some of these details I mentioned on how flows are generated are wrong, corrections are welcomed :)

Either you worked with some very old version of Open vSwitch or you were
simply mistaken.  The process of handling "normal" and "flood" is
similar to that for other ports.  One would not ordinarily see such a
difference.