[ovs-dev] Documentation: Clarify connection tracking tutorial
diff mbox series

Message ID 1560545066-15722-1-git-send-email-gvrose8192@gmail.com
State Superseded
Headers show
Series
  • [ovs-dev] Documentation: Clarify connection tracking tutorial
Related show

Commit Message

Gregory Rose June 14, 2019, 8:44 p.m. UTC
The current documentation states that "all packets entering OVS for
the first time are "untracked"".  However there is a minor exception
to this in the case where a packet (re)enters the same datapath and
the namespace has not changed.  In that case there is no need to
scrub the packet and in this case the connection may already be
in the "tracked" state.

Reported-by: Quan Tian <qtian@vmware.com>
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
---
 Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Yifeng Sun June 14, 2019, 9:26 p.m. UTC | #1
Looks good to me, thanks for the fix.

Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>

On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com> wrote:
>
> The current documentation states that "all packets entering OVS for
> the first time are "untracked"".  However there is a minor exception
> to this in the case where a packet (re)enters the same datapath and
> the namespace has not changed.  In that case there is no need to
> scrub the packet and in this case the connection may already be
> in the "tracked" state.
>
> Reported-by: Quan Tian <qtian@vmware.com>
> Signed-off-by: Greg Rose <gvrose8192@gmail.com>
> ---
>  Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst
> index 27d6e04..5daffb6 100644
> --- a/Documentation/tutorials/ovs-conntrack.rst
> +++ b/Documentation/tutorials/ovs-conntrack.rst
> @@ -308,8 +308,14 @@ Let's add that flow::
>
>  A TCP syn packet sent from "left" namespace will match flow #1
>  because the packet is coming to OVS from veth_l0 port and it is not being
> -tracked.  (as the packet just entered OVS. All packets entering OVS for the
> -first time are "untracked")
> +tracked.  This is because the packet just entered OVS. All packets entering
> +OVS for the first time are "untracked" with a minor exception being
> +when a packet (re)enters the same datapath that it already belongs to
> +there is no need to discard the namespace and other information.  In this
> +case the connection will remain in the tracked state.  If the namespace
> +has changed then it is discarded and a new connection tracker is
> +created since connection tracking information is logically separate
> +for different namespaces.
>  The flow will send the packet to the connection tracker due to the action "ct".
>  Also "table=0" in the "ct" action forks the pipeline processing in two.  The
>  original instance of packet will continue processing the current action list
> --
> 1.8.3.1
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Darrell Ball June 14, 2019, 10:57 p.m. UTC | #2
Hi Greg

few comments inline.

On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com> wrote:

> The current documentation states that "all packets entering OVS for
> the first time are "untracked"".  However there is a minor exception
> to this in the case where a packet (re)enters the same datapath and
> the namespace has not changed.  In that case there is no need to
> scrub the packet and in this case the connection may already be
> in the "tracked" state.
>
> Reported-by: Quan Tian <qtian@vmware.com>
> Signed-off-by: Greg Rose <gvrose8192@gmail.com>
> ---
>  Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/tutorials/ovs-conntrack.rst
> b/Documentation/tutorials/ovs-conntrack.rst
> index 27d6e04..5daffb6 100644
> --- a/Documentation/tutorials/ovs-conntrack.rst
> +++ b/Documentation/tutorials/ovs-conntrack.rst
> @@ -308,8 +308,14 @@ Let's add that flow::
>
>  A TCP syn packet sent from "left" namespace will match flow #1
>  because the packet is coming to OVS from veth_l0 port and it is not being
> -tracked.  (as the packet just entered OVS. All packets entering OVS for
> the
> -first time are "untracked")
> +tracked.  This is because the packet just entered OVS. All packets
> entering
> +OVS for the first time are "untracked" with a


Maybe ?:
"When a packet enters a namespace for the first time, a new connection
tracker context is entered,
hence, the packet will be initially "untracked" in that namespace."


> minor exception being
> +when a packet (re)enters the same datapath

that it already belongs to
> +there is no need to discard the namespace and other information.


it might be helpful to expand on "other information" here ?


>   In this
> +case the connection will remain in the tracked state.


s/the connection will remain in the tracked state/the packet will remain in
the tracked state/


> If the namespace
> +has changed then it is discarded and a new connection tracker is
> +created since connection tracking information is logically separate
> +for different namespaces.
>  The flow will send the packet to the connection tracker due to the action
> "ct".
>  Also "table=0" in the "ct" action forks the pipeline processing in two.
> The
>  original instance of packet will continue processing the current action
> list
> --
> 1.8.3.1
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
Gregory Rose June 17, 2019, 8:36 p.m. UTC | #3
On 6/14/2019 3:57 PM, Darrell Ball wrote:
> Hi Greg
>
> few comments inline.

Thanks for the suggestions Darrell, let me work up a V2 and I'll repost 
then.

- Greg

>
> On Fri, Jun 14, 2019 at 1:44 PM Greg Rose <gvrose8192@gmail.com 
> <mailto:gvrose8192@gmail.com>> wrote:
>
>     The current documentation states that "all packets entering OVS for
>     the first time are "untracked"".  However there is a minor exception
>     to this in the case where a packet (re)enters the same datapath and
>     the namespace has not changed.  In that case there is no need to
>     scrub the packet and in this case the connection may already be
>     in the "tracked" state.
>
>     Reported-by: Quan Tian <qtian@vmware.com <mailto:qtian@vmware.com>>
>     Signed-off-by: Greg Rose <gvrose8192@gmail.com
>     <mailto:gvrose8192@gmail.com>>
>     ---
>      Documentation/tutorials/ovs-conntrack.rst | 10 ++++++++--
>      1 file changed, 8 insertions(+), 2 deletions(-)
>
>     diff --git a/Documentation/tutorials/ovs-conntrack.rst
>     b/Documentation/tutorials/ovs-conntrack.rst
>     index 27d6e04..5daffb6 100644
>     --- a/Documentation/tutorials/ovs-conntrack.rst
>     +++ b/Documentation/tutorials/ovs-conntrack.rst
>     @@ -308,8 +308,14 @@ Let's add that flow::
>
>      A TCP syn packet sent from "left" namespace will match flow #1
>      because the packet is coming to OVS from veth_l0 port and it is
>     not being
>     -tracked.  (as the packet just entered OVS. All packets entering
>     OVS for the
>     -first time are "untracked")
>     +tracked.  This is because the packet just entered OVS. All
>     packets entering
>     +OVS for the first time are "untracked" with a
>
>
> Maybe ?:
> "When a packet enters a namespace for the first time, a new connection 
> tracker context is entered,
> hence, the packet will be initially "untracked" in that namespace."
>
>     minor exception being
>     +when a packet (re)enters the same datapath
>
>     that it already belongs to
>     +there is no need to discard the namespace and other information.
>
>
> it might be helpful to expand on "other information" here ?
>
>       In this
>     +case the connection will remain in the tracked state. 
>
>
> s/the connection will remain in the tracked state/the packet will 
> remain in the tracked state/
>
>     If the namespace
>     +has changed then it is discarded and a new connection tracker is
>     +created since connection tracking information is logically separate
>     +for different namespaces.
>      The flow will send the packet to the connection tracker due to
>     the action "ct".
>      Also "table=0" in the "ct" action forks the pipeline processing
>     in two.  The
>      original instance of packet will continue processing the current
>     action list
>     -- 
>     1.8.3.1
>
>     _______________________________________________
>     dev mailing list
>     dev@openvswitch.org <mailto:dev@openvswitch.org>
>     https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>

Patch
diff mbox series

diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst
index 27d6e04..5daffb6 100644
--- a/Documentation/tutorials/ovs-conntrack.rst
+++ b/Documentation/tutorials/ovs-conntrack.rst
@@ -308,8 +308,14 @@  Let's add that flow::
 
 A TCP syn packet sent from "left" namespace will match flow #1
 because the packet is coming to OVS from veth_l0 port and it is not being
-tracked.  (as the packet just entered OVS. All packets entering OVS for the
-first time are "untracked")
+tracked.  This is because the packet just entered OVS. All packets entering
+OVS for the first time are "untracked" with a minor exception being
+when a packet (re)enters the same datapath that it already belongs to
+there is no need to discard the namespace and other information.  In this
+case the connection will remain in the tracked state.  If the namespace
+has changed then it is discarded and a new connection tracker is
+created since connection tracking information is logically separate
+for different namespaces.
 The flow will send the packet to the connection tracker due to the action "ct".
 Also "table=0" in the "ct" action forks the pipeline processing in two.  The
 original instance of packet will continue processing the current action list