Re: [ovs-discuss] OVS megaflows
I took a look at the datapath code - saw only single table, which its entries are microflows and megaflows the megaflows are indicated by non-zero mask fields Sara On Wed, Aug 16, 2017 at 9:59 AM, Sara Gittlin wrote: > Thank you Joe > Few questions: > 1. Are there 2 separate flow tables in the kernel data-path ? for > microflows and megaflows ? > > 2. If the answer is yes : >- When pkt arrives, is it first checked against the microflows > table and if there is no match, then it checked against the megaflows > table ? > >- Then if the pkt matches a megaflow - a new microflow will be > generated by the kernel for this pkt ? this make sense to improve > performance. > > > Sara > > > On Tue, Aug 15, 2017 at 7:16 PM, Joe Stringer wrote: >> On the first point - it's a little more subtle than that. A traffic >> flow (eg, a connection) must arrive at OVS, the first packet is sent >> through userspace, which causes userspace to install a megaflow into >> the datapath. Subsequently, if any traffic which matches that megaflow >> arrives, it will directly 'hit' the megaflow entry and execute the >> associated actions without going to userspace. Typically we use >> "microflow" to refer to a packet headers description which >> exact-matches all known fields, while "megaflow" allows a mask to be >> applied in addition to this, which allows the traffic which would >> otherwise be handled by multiple microflows to instead be handled by a >> single megaflow. There is no dependency between megaflows and >> microflows. >> >> Cheers, >> Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS megaflows
Thank you Joe Few questions: 1. Are there 2 separate flow tables in the kernel data-path ? for microflows and megaflows ? 2. If the answer is yes : - When pkt arrives, is it first checked against the microflows table and if there is no match, then it checked against the megaflows table ? - Then if the pkt matches a megaflow - a new microflow will be generated by the kernel for this pkt ? this make sense to improve performance. Sara On Tue, Aug 15, 2017 at 7:16 PM, Joe Stringer wrote: > On the first point - it's a little more subtle than that. A traffic > flow (eg, a connection) must arrive at OVS, the first packet is sent > through userspace, which causes userspace to install a megaflow into > the datapath. Subsequently, if any traffic which matches that megaflow > arrives, it will directly 'hit' the megaflow entry and execute the > associated actions without going to userspace. Typically we use > "microflow" to refer to a packet headers description which > exact-matches all known fields, while "megaflow" allows a mask to be > applied in addition to this, which allows the traffic which would > otherwise be handled by multiple microflows to instead be handled by a > single megaflow. There is no dependency between megaflows and > microflows. > > Cheers, > Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS megaflows
On the first point - it's a little more subtle than that. A traffic flow (eg, a connection) must arrive at OVS, the first packet is sent through userspace, which causes userspace to install a megaflow into the datapath. Subsequently, if any traffic which matches that megaflow arrives, it will directly 'hit' the megaflow entry and execute the associated actions without going to userspace. Typically we use "microflow" to refer to a packet headers description which exact-matches all known fields, while "megaflow" allows a mask to be applied in addition to this, which allows the traffic which would otherwise be handled by multiple microflows to instead be handled by a single megaflow. There is no dependency between megaflows and microflows. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS megaflows
Can i summarize: 1. Once N microflows are installed in the kernel cache: we can install a megaflow/s in kernel datapath, if it possible to generate a megaflow/s for them 2. These megaflow/s remain in the kernel megaflow cache as long as the associated flows are in userspace openflow tables, regardless of microflows eviction from kernel cache. Thanks in advance Sara On Mon, Aug 14, 2017 at 8:47 PM, Joe Stringer wrote: > 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 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 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 wrote: On 23 July 2017 at 06:37, Sara Gittlin 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
Re: [ovs-discuss] OVS megaflows
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 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 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 wrote: >>> On 23 July 2017 at 06:37, Sara Gittlin 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
Re: [ovs-discuss] OVS megaflows
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 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 wrote: >> On 23 July 2017 at 06:37, Sara Gittlin 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
Re: [ovs-discuss] OVS megaflows
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 wrote: > On 23 July 2017 at 06:37, Sara Gittlin 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
Re: [ovs-discuss] OVS megaflows
On 23 July 2017 at 06:37, Sara Gittlin 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