[ovs-discuss] OVS megaflows

Sara Gittlin sara.gittlin at gmail.com
Mon Aug 14 07:35:12 UTC 2017

I  understand that this citation refers to the kernel microflows  tables.
the kernel megaflows table *can be* pre-populated. Correct ?

On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin <sara.gittlin at gmail.com> wrote:
> Thanks you Joe
> the following citation is in a contradiction to the idea of
> pre-populating megaflows in kernel datapath .
> this is from  http://docs.openvswitch.org/en/latest/faq/design/
> "Q: Can OVS populate the kernel flow table in advance instead of in
> reaction to packets?
> A: No. There are several reasons:
> Kernel flows are not as sophisticated as OpenFlow flows, which means
> that some OpenFlow policies could require a large number of kernel
> flows. The “conjunctive match” feature is an extreme example: the
> number of kernel flows it requires is the product of the number of
> flows in each dimension.
> With multiple OpenFlow flow tables and simple sets of actions, the
> number of kernel flows required can be as large as the product of the
> number of flows in each dimension. With more sophisticated actions,
> the number of kernel flows could be even larger.
> Open vSwitch is designed so that any version of OVS userspace
> interoperates with any version of the OVS kernel module. This forward
> and backward compatibility requires that userspace observe how the
> kernel module parses received packets. This is only possible in a
> straightforward way when userspace adds kernel flows in reaction to
> received packets."
> Thanks in advance - Sara
> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer <joe at ovn.org> wrote:
>> On 23 July 2017 at 06:37, Sara Gittlin <sara.gittlin at gmail.com> wrote:
>>> Hello,
>>> I understand that there is a support for megaflows in the kernel and netlink.
>>> I also understand that there is no megaflow implementation in ofproto.
>>> i.e. there is no implementation of compressing (if possible) all flows
>>> in ofproto table to megaflows and installing it in the datapath. is
>>> that correct ?
>> That's right - rather than pre-populating a representation of the
>> entire OpenFlow state, the ofproto-dpif implementation uses an
>> "upcall" model where the datapath acts as a cache for forwarding
>> behaviour, and the cache is populated on-demand as traffic arrives.

More information about the discuss mailing list