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