Thanks for the patch I avoided duplicate comments from what Justin suggested
comments inline On Thu, Aug 1, 2019 at 3:08 PM Yi-Hung Wei <yihung....@gmail.com> wrote: > From: Justin Pettit <jpet...@ovn.org> > > From: Justin Pettit <jpet...@ovn.org> > > Signed-off-by: Justin Pettit <jpet...@ovn.org> > --- > vswitchd/vswitch.ovsschema | 43 +++++++- > vswitchd/vswitch.xml | 252 > ++++++++++++++++++++++++++++++++++++--------- > 2 files changed, 246 insertions(+), 49 deletions(-) > > diff --git a/vswitchd/vswitch.ovsschema b/vswitchd/vswitch.ovsschema > index f7c6eb8983cd..d215f4edfefa 100644 > --- a/vswitchd/vswitch.ovsschema > +++ b/vswitchd/vswitch.ovsschema > @@ -1,9 +1,14 @@ > {"name": "Open_vSwitch", > - "version": "8.0.0", > - "cksum": "3962141869 23978", > + "version": "8.1.0", > + "cksum": "1566974404 25483", > "tables": { > "Open_vSwitch": { > "columns": { > + "datapaths": { > + "type": {"key": {"type": "string"}, > Should 'type' be an enum something like: "type": {"key": {"type": "string", "enum": ["set", ["system", "netdev"]]}}, The schema can still be upgraded by adding new datapath types should more ever arise. > + "value": {"type": "uuid", > + "refTable": "Datapath"}, > + "min": 0, "max": "unlimited"}}, > accordingly: "min": 0, "max": "2"}}, > "bridges": { > "type": {"key": {"type": "uuid", > "refTable": "Bridge"}, > @@ -629,6 +634,40 @@ > "min": 0, "max": "unlimited"}, > "ephemeral": true}}, > "indexes": [["target"]]}, > + "Datapath": { > + "columns": { > + "datapath_version": { > + "type": "string"}, > + "ct_zones": { > + "type": {"key": {"type": "integer", > + "minInteger": 0, > + "maxInteger": 65535}, > + "value": {"type": "uuid", > + "refTable": "CT_Zone"}, > + "min": 0, "max": "unlimited"}}, > How about ? "min": 0, "max": "65535"}}, I don't think we can have multiple entries for the same zone and if we did, we don't handle it. > + "external_ids": { > + "type": {"key": "string", "value": "string", > + "min": 0, "max": "unlimited"}}}}, > + "CT_Zone": { > + "columns": { > + "timeout_policy": { > + "type": {"key": {"type": "uuid", > + "refTable": "CT_Timeout_Policy"}, > + "min": 0, "max": 1}}, > + "external_ids": { > + "type": {"key": "string", "value": "string", > + "min": 0, "max": "unlimited"}}}}, > + "CT_Timeout_Policy": { > + "columns": { > + "timeouts": { > + "type": {"key": "string", > + "value": {"type" : "integer", > + "minInteger" : 0, > + "maxInteger" : 4294967295}, > + "min": 0, "max": "unlimited"}}, > + "external_ids": { > + "type": {"key": "string", "value": "string", > + "min": 0, "max": "unlimited"}}}}, > "SSL": { > "columns": { > "private_key": { > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml > index 027aee2f523b..a0706c9c0fc1 100644 > --- a/vswitchd/vswitch.xml > +++ b/vswitchd/vswitch.xml > @@ -52,6 +52,13 @@ > one record in the <ref table="Open_vSwitch"/> table. > > <group title="Configuration"> > + <column name="datapaths"> > + Map of datapath types to datapaths. The > + <ref column="datapath_type"/> column of the <ref table="Bridge"/> > + table is used as a key for this map. The value points to a row in > + the <ref table="Datapath"/> table. > + </column> > + > <column name="bridges"> > Set of bridges managed by the daemon. > </column> > @@ -1192,53 +1199,11 @@ > </column> > > <column name="datapath_version"> > - <p> > - Reports the version number of the Open vSwitch datapath in use. > - This allows management software to detect and report > discrepancies > - between Open vSwitch userspace and datapath versions. (The <ref > - column="ovs_version" table="Open_vSwitch"/> column in the <ref > - table="Open_vSwitch"/> reports the Open vSwitch userspace > version.) > - The version reported depends on the datapath in use: > - </p> > - > - <ul> > - <li> > - When the kernel module included in the Open vSwitch source > tree is > - used, this column reports the Open vSwitch version from which > the > - module was taken. > - </li> > - > - <li> > - When the kernel module that is part of the upstream Linux > kernel is > - used, this column reports <code><unknown></code>. > - </li> > - > - <li> > - When the datapath is built into the <code>ovs-vswitchd</code> > - binary, this column reports <code><built-in></code>. A > - built-in datapath is by definition the same version as the > rest of > - the Open VSwitch userspace. > - </li> > - > - <li> > - Other datapaths (such as the Hyper-V kernel datapath) > currently > - report <code><unknown></code>. > - </li> > - </ul> > - > - <p> > - A version discrepancy between <code>ovs-vswitchd</code> and the > - datapath in use is not normally cause for alarm. The Open > vSwitch > - kernel datapaths for Linux and Hyper-V, in particular, are > designed > - for maximum inter-version compatibility: any userspace version > works > - with with any kernel version. Some reasons do exist to insist > on > - particular user/kernel pairings. First, newer kernel versions > add > - new features, that can only be used by new-enough userspace, > e.g. > - VXLAN tunneling requires certain minimal userspace and kernel > - versions. Second, as an extension to the first reason, some > newer > - kernel versions add new features for enhancing performance that > only > - new-enough userspace versions can take advantage of. > - </p> > + Reports the datapath version. This column is maintained for > + backwards compatibility. The preferred locatation is the > + <ref column="datapath_id" table="Datapath"/> column of the > + <ref table="Datapath"/> table. The full documentation for this > + column is there. > </column> > > <column name="other_config" key="datapath-id"> > @@ -5560,6 +5525,199 @@ ovs-vsctl add-port br0 p0 -- set Interface p0 > type=patch options:peer=p1 \ > </group> > </table> > > + <table name="Datapath"> > + <p> > + Configuration for a datapath within <ref table="Open_vSwitch"/>. > + </p> > + <p> > + A datapath is responsible for providing the packet handling in Open > + vSwitch. There are two primary datapath implementations used by > + Open vSwitch: kernel and userspace. Kernel datapath > + implementations are available for Linux and Hyper-V, and selected > + as <code>system</code> in the <ref column="datapath_type"/> column > + of the <ref table="Bridge"/> table. The userspace datapath is used > + by DPDK and AF-XDP, and is selected as <code>netdev</code> in the > + <ref column="datapath_type"/> column of the <ref table="Bridge"/> > + table. > + </p> > + <p> > + A datapath of a particular type is shared by all the bridges that > use > + that datapath. Thus, configurations applied to this table affect > + all bridges that use this datapath. > + </p> > + > + <column name="datapath_version"> > + <p> > + Reports the version number of the Open vSwitch datapath in use. > + This allows management software to detect and report discrepancies > + between Open vSwitch userspace and datapath versions. (The <ref > + column="ovs_version" table="Open_vSwitch"/> column in the <ref > + table="Open_vSwitch"/> reports the Open vSwitch userspace > version.) > + The version reported depends on the datapath in use: > + </p> > + > + <ul> > + <li> > + When the kernel module included in the Open vSwitch source tree > is > + used, this column reports the Open vSwitch version from which > the > + module was taken. > + </li> > + > + <li> > + When the kernel module that is part of the upstream Linux > kernel is > + used, this column reports <code><unknown></code>. > + </li> > + > + <li> > + When the datapath is built into the <code>ovs-vswitchd</code> > + binary, this column reports <code><built-in></code>. A > + built-in datapath is by definition the same version as the rest > of > + the Open VSwitch userspace. > + </li> > + > + <li> > + Other datapaths (such as the Hyper-V kernel datapath) currently > + report <code><unknown></code>. > + </li> > + </ul> > + > + <p> > + A version discrepancy between <code>ovs-vswitchd</code> and the > + datapath in use is not normally cause for alarm. The Open vSwitch > + kernel datapaths for Linux and Hyper-V, in particular, are > designed > + for maximum inter-version compatibility: any userspace version > works > + with with any kernel version. Some reasons do exist to insist on > + particular user/kernel pairings. First, newer kernel versions add > + new features, that can only be used by new-enough userspace, e.g. > + VXLAN tunneling requires certain minimal userspace and kernel > + versions. Second, as an extension to the first reason, some newer > + kernel versions add new features for enhancing performance that > only > + new-enough userspace versions can take advantage of. > + </p> > + </column> > + > + <column name="ct_zones"> > + Configuration for connection tracking zones. Each pair maps from a > + zone id to a configuration for that zone. Zone <code>0</code> > applies > + to the default zone (ie, the one used if a zone is not specified in > + connection tracking-related OpenFlow matches and actions). > + </column> > + > + <group title="Common Columns"> > + The overall purpose of these columns is described under <code>Common > + Columns</code> at the beginning of this document. > + > + <column name="external_ids"/> > + </group> > + </table> > + > + <table name="CT_Zone"> > + Connection tracking zone configuration > + > + <column name="timeout_policy"> > + Connection tracking timeout policy for this zone. If timeout policy > is > + not specified, defaults to the timeout policy in the system. > + </column> > + > + <group title="Common Columns"> > + The overall purpose of these columns is described under <code>Common > + Columns</code> at the beginning of this document. > + > + <column name="external_ids"/> > + </group> > + </table> > + > + <table name="CT_Timeout_Policy"> > + Connection tracking timeout policy configuration > + > + <group title="Timeouts"> > + <column name="timeouts"> > + The <code>timeouts</code> column contains key-value pairs used > + to configure connection tracking timeouts in a datapath. > + Key-value pairs that are not supported by a datapath are > + ignored. > + </column> > + > + <group title="TCP Timeouts"> > + <column name="timeouts" key="tcp_syn_sent"> > + TCP SYN sent timeout. > + </column> > + > + <column name="timeouts" key="tcp_syn_recv"> > + TCP SYN receive timeout. > + </column> > + > + <column name="timeouts" key="tcp_established"> > + TCP established timeout. > + </column> > + > + <column name="timeouts" key="tcp_fin_wait"> > + TCP FIN wait timeout. > + </column> > + > + <column name="timeouts" key="tcp_close_wait"> > + TCP close wait timeout. > + </column> > + > + <column name="timeouts" key="tcp_last_ack"> > + TCP last ACK timeout. > + </column> > + > + <column name="timeouts" key="tcp_time_wait"> > + TCP time wait timeout. > + </column> > + > + <column name="timeouts" key="tcp_close"> > + TCP close timeout. > + </column> > + > + <column name="timeouts" key="tcp_syn_sent2"> > + TCP syn sent2 timeout. > + </column> > + > + <column name="timeouts" key="tcp_retransmit"> > + TCP retransmit timeout. > + </column> > + > + <column name="timeouts" key="tcp_unack"> > + TCP unacknowledgment timeout. > + </column> > + </group> > + > + <group title="UDP Timeouts"> > + <column name="timeouts" key="udp_first"> > + First UDP packet timeout. > I want to be very specific about this one: "The timeout of the connection when only the first UDP packet has been seen by conntrack. This timeout is only supported by the userspace datapath." > + </column> > + > + <column name="timeouts" key="udp_single"> > + The timeout in the state that source host sends more than one > packet > + but the destination host has never sent one backs. > + </column> > + > + <column name="timeouts" key="udp_multiple"> > + UDP packets seen in both directions timeout. > + </column> > + </group> > + > + <group title="ICMP Timeouts"> > + <column name="timeouts" key="icmp_first"> > + First ICMP timeout. > + </column> > + > + <column name="timeouts" key="icmp_reply"> > + ICMP reply timeout. > + </column> > + </group> > + </group> > + > + <group title="Common Columns"> > + The overall purpose of these columns is described under <code>Common > + Columns</code> at the beginning of this document. > + > + <column name="external_ids"/> > + </group> > + </table> > + > <table name="SSL"> > SSL configuration for an Open_vSwitch. > > -- > 2.7.4 > > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev