Re: [ovs-dev] [PATCH] ovs-actions: Document normal pipeline.
On Wed, May 12, 2021 at 07:09:50PM +0200, Ilya Maximets wrote: > On 4/15/21 5:34 AM, Ben Pfaff wrote: > > Signed-off-by: Ben Pfaff > > --- > > lib/ovs-actions.xml | 288 +++- > > 1 file changed, 286 insertions(+), 2 deletions(-) > > > > Hi, Ben. Thanks for writing this down! > It looks good to me in general. Few comments inline. Thanks! Your comments make sense. I fixed them, and did a re-read of my own to find other ways the writing could be improved, and sent v2 for a second round of review: https://mail.openvswitch.org/pipermail/ovs-dev/2021-May/382963.html ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-actions: Document normal pipeline.
On 4/15/21 5:34 AM, Ben Pfaff wrote: > Signed-off-by: Ben Pfaff > --- > lib/ovs-actions.xml | 288 +++- > 1 file changed, 286 insertions(+), 2 deletions(-) > Hi, Ben. Thanks for writing this down! It looks good to me in general. Few comments inline. Best regards, Ilya Maximets. > diff --git a/lib/ovs-actions.xml b/lib/ovs-actions.xml > index a2778de4bcd6..de934a244de9 100644 > --- a/lib/ovs-actions.xml > +++ b/lib/ovs-actions.xml > @@ -509,7 +509,8 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > >Subjects the packet to the device's normal L2/L3 processing. This >action is not implemented by all OpenFlow switches, and each switch > - implements it differently. > + implements it differently. The section ``The OVS Normal Pipeline'' > + below documents the OVS implementation. > > > flood > @@ -582,7 +583,6 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > OpenFlow allows switches to reject such actions. > > > - > > >Output to the Input Port > @@ -664,6 +664,290 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > > > > +The OVS Normal Pipeline > + > + > + This section documents how Open vSwitch implements output to the > + normal port. The OpenFlow specification places no > + requirements on how this port works, so all of this documentation is > + specific to Open vSwitch. > + > + > + > + Open vSwitch uses the Open_vSwitch database, detailed in > + ovs-vswitchd.conf.db(5), to determine the details of the > + normal pipeline. > + > + > + > + The normal pipeline executes the following ingress stages for each > + packet. The result of the ingress stages is a set of output ports, > which > + is the empty set if some ingress stage drops the packet: > + > + > + > + > + > + Input port lookup: Looks up the OpenFlow > + in_port field's value to the corresponding > + Port and Interface record in the > database. > + > + > + > + The in_port is normally the OpenFlow port that the > + packet was received on. If set_field or another > actions > + changes the in_port, the updated value is honored. > This > + lookup will ordinarily succeed; if it fails, for example because > + in_port was changed to an unknown value, then the > normal > + pipeline exits. > + > + > + > + > +Drop malformed packet: If the packet is malformed enough that > it > +contains only part of an 802.1Q header, then the normal pipeline > exits > +error. Should it be "exits with error"? > + > + > + > +Drop packets sent to a port reserved for mirroring: If the > +packet was received on a port that is configured as the output port > for > +a mirror (that is, it is the output_port in some > +Mirror record), then the normal pipeline exits. Ports > +used as mirror outputs don't accept any packets. > + > + > + > + > + VLAN input processing: This stage determines what VLAN the > + packet is in. It also verifies that this VLAN is valid for the > port; > + if not, the normal pipeline exits. How the VLAN is determined and > + which ones are valid vary based on the vlan-mode in > the > + input port's Port record: > + > + > + > + trunk > + > +The packet is in the VLAN specified in its 802.1Q header, or in > +VLAN 0 if there is no 802.1Q header. The trunks > +column in the Port record lists the valid VLANs; if > it > +is empty, all VLANs are valid. > + > + > + access > + > +The packet is in the VLAN specified in the tag > column > +of its Port record. The packet must not have an > +802.1Q header with a nonzero VLAN ID; if it does, the pipeline > +exits. > + > + > + native-tagged > + native-untagged > + > +Same as trunk except that the VLAN of a packet > without > +an 802.1Q header is not necessarily zero; instead, it is taken > from > +the tag column. > + > + > + dot1q-tunnel > + > +The packet is in the VLAN specified in the tag > column > +of its Port record, which is a QinQ service VLAN > with > +the Ethertype specified by the Port's > +other_config : qinq-ethtype. If the > +packet has an 802.1Q header, then it specifies the customer VLAN. > +The cvlans column specifies the valid customer > VLANs; > +
Re: [ovs-dev] [PATCH] ovs-actions: Document normal pipeline.
This documentation-only patch could use a review. On Wed, Apr 14, 2021 at 08:34:46PM -0700, Ben Pfaff wrote: > Signed-off-by: Ben Pfaff > --- > lib/ovs-actions.xml | 288 +++- > 1 file changed, 286 insertions(+), 2 deletions(-) > > diff --git a/lib/ovs-actions.xml b/lib/ovs-actions.xml > index a2778de4bcd6..de934a244de9 100644 > --- a/lib/ovs-actions.xml > +++ b/lib/ovs-actions.xml > @@ -509,7 +509,8 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > >Subjects the packet to the device's normal L2/L3 processing. This >action is not implemented by all OpenFlow switches, and each switch > - implements it differently. > + implements it differently. The section ``The OVS Normal Pipeline'' > + below documents the OVS implementation. > > > flood > @@ -582,7 +583,6 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > OpenFlow allows switches to reject such actions. > > > - > > >Output to the Input Port > @@ -664,6 +664,290 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 > actions=mod_nw_src:1.2.3.4 > > > > +The OVS Normal Pipeline > + > + > + This section documents how Open vSwitch implements output to the > + normal port. The OpenFlow specification places no > + requirements on how this port works, so all of this documentation is > + specific to Open vSwitch. > + > + > + > + Open vSwitch uses the Open_vSwitch database, detailed in > + ovs-vswitchd.conf.db(5), to determine the details of the > + normal pipeline. > + > + > + > + The normal pipeline executes the following ingress stages for each > + packet. The result of the ingress stages is a set of output ports, > which > + is the empty set if some ingress stage drops the packet: > + > + > + > + > + > + Input port lookup: Looks up the OpenFlow > + in_port field's value to the corresponding > + Port and Interface record in the > database. > + > + > + > + The in_port is normally the OpenFlow port that the > + packet was received on. If set_field or another > actions > + changes the in_port, the updated value is honored. > This > + lookup will ordinarily succeed; if it fails, for example because > + in_port was changed to an unknown value, then the > normal > + pipeline exits. > + > + > + > + > +Drop malformed packet: If the packet is malformed enough that > it > +contains only part of an 802.1Q header, then the normal pipeline > exits > +error. > + > + > + > +Drop packets sent to a port reserved for mirroring: If the > +packet was received on a port that is configured as the output port > for > +a mirror (that is, it is the output_port in some > +Mirror record), then the normal pipeline exits. Ports > +used as mirror outputs don't accept any packets. > + > + > + > + > + VLAN input processing: This stage determines what VLAN the > + packet is in. It also verifies that this VLAN is valid for the > port; > + if not, the normal pipeline exits. How the VLAN is determined and > + which ones are valid vary based on the vlan-mode in > the > + input port's Port record: > + > + > + > + trunk > + > +The packet is in the VLAN specified in its 802.1Q header, or in > +VLAN 0 if there is no 802.1Q header. The trunks > +column in the Port record lists the valid VLANs; if > it > +is empty, all VLANs are valid. > + > + > + access > + > +The packet is in the VLAN specified in the tag > column > +of its Port record. The packet must not have an > +802.1Q header with a nonzero VLAN ID; if it does, the pipeline > +exits. > + > + > + native-tagged > + native-untagged > + > +Same as trunk except that the VLAN of a packet > without > +an 802.1Q header is not necessarily zero; instead, it is taken > from > +the tag column. > + > + > + dot1q-tunnel > + > +The packet is in the VLAN specified in the tag > column > +of its Port record, which is a QinQ service VLAN > with > +the Ethertype specified by the Port's > +other_config : qinq-ethtype. If the > +packet has an 802.1Q header, then it specifies the customer VLAN. > +The cvlans column specifies the valid customer > VLANs; > +if it is empty, all customer VLANs are valid. > + > + > +
[ovs-dev] [PATCH] ovs-actions: Document normal pipeline.
Signed-off-by: Ben Pfaff --- lib/ovs-actions.xml | 288 +++- 1 file changed, 286 insertions(+), 2 deletions(-) diff --git a/lib/ovs-actions.xml b/lib/ovs-actions.xml index a2778de4bcd6..de934a244de9 100644 --- a/lib/ovs-actions.xml +++ b/lib/ovs-actions.xml @@ -509,7 +509,8 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4 Subjects the packet to the device's normal L2/L3 processing. This action is not implemented by all OpenFlow switches, and each switch - implements it differently. + implements it differently. The section ``The OVS Normal Pipeline'' + below documents the OVS implementation. flood @@ -582,7 +583,6 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4 OpenFlow allows switches to reject such actions. - Output to the Input Port @@ -664,6 +664,290 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0 actions=mod_nw_src:1.2.3.4 +The OVS Normal Pipeline + + + This section documents how Open vSwitch implements output to the + normal port. The OpenFlow specification places no + requirements on how this port works, so all of this documentation is + specific to Open vSwitch. + + + + Open vSwitch uses the Open_vSwitch database, detailed in + ovs-vswitchd.conf.db(5), to determine the details of the + normal pipeline. + + + + The normal pipeline executes the following ingress stages for each + packet. The result of the ingress stages is a set of output ports, which + is the empty set if some ingress stage drops the packet: + + + + + + Input port lookup: Looks up the OpenFlow + in_port field's value to the corresponding + Port and Interface record in the database. + + + + The in_port is normally the OpenFlow port that the + packet was received on. If set_field or another actions + changes the in_port, the updated value is honored. This + lookup will ordinarily succeed; if it fails, for example because + in_port was changed to an unknown value, then the normal + pipeline exits. + + + + +Drop malformed packet: If the packet is malformed enough that it +contains only part of an 802.1Q header, then the normal pipeline exits +error. + + + +Drop packets sent to a port reserved for mirroring: If the +packet was received on a port that is configured as the output port for +a mirror (that is, it is the output_port in some +Mirror record), then the normal pipeline exits. Ports +used as mirror outputs don't accept any packets. + + + + + VLAN input processing: This stage determines what VLAN the + packet is in. It also verifies that this VLAN is valid for the port; + if not, the normal pipeline exits. How the VLAN is determined and + which ones are valid vary based on the vlan-mode in the + input port's Port record: + + + + trunk + +The packet is in the VLAN specified in its 802.1Q header, or in +VLAN 0 if there is no 802.1Q header. The trunks +column in the Port record lists the valid VLANs; if it +is empty, all VLANs are valid. + + + access + +The packet is in the VLAN specified in the tag column +of its Port record. The packet must not have an +802.1Q header with a nonzero VLAN ID; if it does, the pipeline +exits. + + + native-tagged + native-untagged + +Same as trunk except that the VLAN of a packet without +an 802.1Q header is not necessarily zero; instead, it is taken from +the tag column. + + + dot1q-tunnel + +The packet is in the VLAN specified in the tag column +of its Port record, which is a QinQ service VLAN with +the Ethertype specified by the Port's +other_config : qinq-ethtype. If the +packet has an 802.1Q header, then it specifies the customer VLAN. +The cvlans column specifies the valid customer VLANs; +if it is empty, all customer VLANs are valid. + + + + + +Drop reserved multicast addresses: If the packet is addressed to +a reserved Ethernet multicast address and the Bridge +record does not have other_config : +forward-bpdu set to true, the pipeline exits. + + + + + Check bond admissibility: If the input port is a member of a + bond, that is, a Port with more than one + Interface, then
