The FAQ is referring to megaflows as well, the reasons are the same. Neither microflows nor megaflows can be pre-populated.
On 14 August 2017 at 00:35, Sara Gittlin <sara.gitt...@gmail.com> wrote: > I understand that this citation refers to the kernel microflows tables. > the kernel megaflows table *can be* pre-populated. Correct ? > Sara > > On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin <sara.gitt...@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 <j...@ovn.org> wrote: >>> On 23 July 2017 at 06:37, Sara Gittlin <sara.gitt...@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. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
