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

Ben Pfaff blp at nicira.com
Fri Aug 22 05:12:33 UTC 2014


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.



More information about the dev mailing list