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

Samuel Ghinet sghinet at cloudbasesolutions.com
Fri Aug 22 16:27:01 UTC 2014


[QUOTE]
OVS 1.9.3 needed a trip to userspace for every new microflow.  But OVS
1.11 introduced megaflows, so that in many cases that is no longer
necessary.
[/QUOTE]
Yeah, the microflow is the kernel flow I was trying to say.
We can get to have quite many microflows created, for all kinds of cases of unicast dest eth addr, or multicast dest eth addr.
I am not sure how masks are being set on microflows when meeting a packet - is there everything masked, except eth addr and eth type? or, eth addr, eth type, and ip keys?

[QUOTE]
I'm really quite puzzled why you think "flood" is tricky or special.
[/QUOTE]
I believe the "flood" can be as much as special or tricky as the "normal", and that's because of microflows.

Anyway, I think this discussion is not going anywhere exactly.
In our implementation, we had some dbg prints macros & funcs that were used to print kernel (or, micro) flows as they were being created, set, deleted. This allowed for realtime view of how the userspace NORMAL action affects the kernel.
I remember there were very many micro flows being created and deleted and updated, when we had port NORMAL. Also, for our case, a packet queue of max 200 packets in kernel was not sufficient, at startup.

Perhaps we will simply need one day to do some examination on flows & packet queueing for NORMAL, after we have the netlink part ported, and bring this possible performance problems and / or issues only then.

Sam
________________________________________
From: Ben Pfaff [blp at nicira.com]
Sent: Friday, August 22, 2014 6:37 PM
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 03:24:47PM +0000, Samuel Ghinet wrote:
> What I was testing against was ovs 1.9.3 and ovs 1.11

OVS 1.9.3 needed a trip to userspace for every new microflow.  But OVS
1.11 introduced megaflows, so that in many cases that is no longer
necessary.

> 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".

I'm really quite puzzled why you think "flood" is tricky or special.  It
is trivial: the datapath actions merely list all of the ports in the
bridge except for the input port.  If ports are added or deleted,
userspace revises the actions.

For "normal", the datapath actions direct the packet to the port that
has been learned via MAC learning, or flood the packet (as above) if the
destination MAC hasn't been learned.  When the MAC learning entry
changes or appears or disappears, userspace revises the actions.  The
need for MAC learning makes the process of deciding where packets go a
little more complicated in userspace, but it doesn't require more trips
to userspace.



More information about the dev mailing list