Re: [ovs-dev] [PATCH v1] Documentation: Fixing some minor spelling mistakes and consistent usage of certain keywords.
I think I got misled by the 's' in the flags. I will submit a v2 patch with this sentence reverted back to it's original version. Thanks for the review. On Tue, Nov 13, 2018 at 10:03 AM Mark Michelson wrote: > Thanks for the patch. I have one finding down below. > > On 11/12/2018 04:55 PM, Ashish Varma wrote: > > Signed-off-by: Ashish Varma > > --- > > Documentation/tutorials/ovs-conntrack.rst | 20 ++-- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > diff --git a/Documentation/tutorials/ovs-conntrack.rst > b/Documentation/tutorials/ovs-conntrack.rst > > index 07ea998..a86288f 100644 > > --- a/Documentation/tutorials/ovs-conntrack.rst > > +++ b/Documentation/tutorials/ovs-conntrack.rst > > @@ -31,7 +31,7 @@ etc., connections. (Connection tracking system > supports tracking of both > > statefull and stateless protocols) > > > > This tutorial demonstrates how OVS can use the connection tracking > system > > -to match on the TCP segments from connection setup to connection > teardown. > > +to match on the TCP segments from connection setup to connection tear > down. > > It will use OVS with the Linux kernel module as the datapath for this > > tutorial. (The datapath that utilizes the openvswitch kernel module to > do > > the packet processing in the Linux kernel) > > @@ -77,10 +77,10 @@ Possible values: > > - *snat* > > - *dnat* > > > > -Each of these flags is preceded by either a "+" for a flag that > > +Each of these flags are preceded by either a "+" for a flag that > > The original version of this sentence is correct. Or at least > traditionally, the original version is correct: > https://www.grammar.com/each-singular-or-plural/ > > There's an argument to be made that your version could also be > acceptable, but I think the original version of the sentence doesn't > need to be changed. > > > must be set, or a "-" for a flag that must be unset. > > Multiple flags can also be specified e.g. ct_state=+trk+new. > > -We will see the usage of some these flags below. For a detailed > > +We will see the usage of some of these flags below. For a detailed > > description, please see the OVS fields documentation at: > > http://openvswitch.org/support/dist-docs/ovs-fields.7.txt > > > > @@ -283,7 +283,7 @@ packets from "left" to "right" and from "right" to > "left":: > > Instead of adding these two flows, we will add flows to match on the > > states of the TCP segments. > > > > -We will send the TCP connections setup segments namely: > > +We will send the TCP connection setup segments namely: > > syn, syn-ack and ack between hosts 192.168.0.2 in the "left" namespace > and > > 10.0.0.2 in the "right" namespace. > > > > @@ -294,7 +294,7 @@ First, let's add a flow to start "tracking" a packet > received at OVS. > > To start tracking a packet, it first needs to match a flow, which has > action > > as "ct". This action sends the packet through the connection > tracker. To > > identify that a packet is an "untracked" packet, the ct_state in the > flow > > -match filed must be set to "-trk", which means it is not a tracked > packet. > > +match field must be set to "-trk", which means it is not a tracked > packet. > > Once the packet is sent to the connection tracker, then only we will > know about > > its conntrack state. (i.e. whether this packet represents start of a > new > > connection or the packet belongs to an existing connection or it is > > @@ -353,8 +353,8 @@ The conntrack module will now have an entry for this > connection:: > > Note: At this stage, if the TCP syn packet is re-transmitted, it will > again > > match flow #1 (since a new packet is untracked) and it will match flow > #2. > > The reason it will match flow #2 is that although conntrack has > information > > -about the connection, but it is not in established state, therefore it > matches > > -the "new" state again. > > +about the connection, but it is not in "ESTABLISHED" state, therefore it > > +matches the "new" state again. > > > > Next for the TCP syn-ack from the opposite/server direction, we need > > following flows at OVS:: > > @@ -418,7 +418,7 @@ conntrack entry:: > >reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024), \ > >protoinfo=(state=ESTABLISHED) > > > > -The conntrck state stays in "ESTABLISHED" state, but now since it has > received > > +The conntrack state stays in "ESTABLISHED" state, but now since it has > received > > the ack from client, it will stay in this state for a longer time even > without > > receiving any data on this connection. > > > > @@ -445,7 +445,7 @@ The acknowledgement for the data would hit flow #3 > and flow #4. > > > > TCP Connection Teardown > > ~~~ > > -There are different ways to teardown TCP connection. We will teardown > the > > +There are different ways to tear down TCP connection. We will tear down > the > >
Re: [ovs-dev] [PATCH v1] Documentation: Fixing some minor spelling mistakes and consistent usage of certain keywords.
Thanks for the patch. I have one finding down below. On 11/12/2018 04:55 PM, Ashish Varma wrote: Signed-off-by: Ashish Varma --- Documentation/tutorials/ovs-conntrack.rst | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst index 07ea998..a86288f 100644 --- a/Documentation/tutorials/ovs-conntrack.rst +++ b/Documentation/tutorials/ovs-conntrack.rst @@ -31,7 +31,7 @@ etc., connections. (Connection tracking system supports tracking of both statefull and stateless protocols) This tutorial demonstrates how OVS can use the connection tracking system -to match on the TCP segments from connection setup to connection teardown. +to match on the TCP segments from connection setup to connection tear down. It will use OVS with the Linux kernel module as the datapath for this tutorial. (The datapath that utilizes the openvswitch kernel module to do the packet processing in the Linux kernel) @@ -77,10 +77,10 @@ Possible values: - *snat* - *dnat* -Each of these flags is preceded by either a "+" for a flag that +Each of these flags are preceded by either a "+" for a flag that The original version of this sentence is correct. Or at least traditionally, the original version is correct: https://www.grammar.com/each-singular-or-plural/ There's an argument to be made that your version could also be acceptable, but I think the original version of the sentence doesn't need to be changed. must be set, or a "-" for a flag that must be unset. Multiple flags can also be specified e.g. ct_state=+trk+new. -We will see the usage of some these flags below. For a detailed +We will see the usage of some of these flags below. For a detailed description, please see the OVS fields documentation at: http://openvswitch.org/support/dist-docs/ovs-fields.7.txt @@ -283,7 +283,7 @@ packets from "left" to "right" and from "right" to "left":: Instead of adding these two flows, we will add flows to match on the states of the TCP segments. -We will send the TCP connections setup segments namely: +We will send the TCP connection setup segments namely: syn, syn-ack and ack between hosts 192.168.0.2 in the "left" namespace and 10.0.0.2 in the "right" namespace. @@ -294,7 +294,7 @@ First, let's add a flow to start "tracking" a packet received at OVS. To start tracking a packet, it first needs to match a flow, which has action as "ct". This action sends the packet through the connection tracker. To identify that a packet is an "untracked" packet, the ct_state in the flow -match filed must be set to "-trk", which means it is not a tracked packet. +match field must be set to "-trk", which means it is not a tracked packet. Once the packet is sent to the connection tracker, then only we will know about its conntrack state. (i.e. whether this packet represents start of a new connection or the packet belongs to an existing connection or it is @@ -353,8 +353,8 @@ The conntrack module will now have an entry for this connection:: Note: At this stage, if the TCP syn packet is re-transmitted, it will again match flow #1 (since a new packet is untracked) and it will match flow #2. The reason it will match flow #2 is that although conntrack has information -about the connection, but it is not in established state, therefore it matches -the "new" state again. +about the connection, but it is not in "ESTABLISHED" state, therefore it +matches the "new" state again. Next for the TCP syn-ack from the opposite/server direction, we need following flows at OVS:: @@ -418,7 +418,7 @@ conntrack entry:: reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024), \ protoinfo=(state=ESTABLISHED) -The conntrck state stays in "ESTABLISHED" state, but now since it has received +The conntrack state stays in "ESTABLISHED" state, but now since it has received the ack from client, it will stay in this state for a longer time even without receiving any data on this connection. @@ -445,7 +445,7 @@ The acknowledgement for the data would hit flow #3 and flow #4. TCP Connection Teardown ~~~ -There are different ways to teardown TCP connection. We will teardown the +There are different ways to tear down TCP connection. We will tear down the connection by sending "fin" from client, "fin-ack" from server followed by the last "ack" by client. @@ -507,7 +507,7 @@ conntrack entry:: Summary --- -Following table summarizes the TCP segments exhanged against the flow +Following table summarizes the TCP segments exchanged against the flow match fields +---+---+ ___ dev mailing list d...@openvswitch.org
[ovs-dev] [PATCH v1] Documentation: Fixing some minor spelling mistakes and consistent usage of certain keywords.
Signed-off-by: Ashish Varma --- Documentation/tutorials/ovs-conntrack.rst | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst index 07ea998..a86288f 100644 --- a/Documentation/tutorials/ovs-conntrack.rst +++ b/Documentation/tutorials/ovs-conntrack.rst @@ -31,7 +31,7 @@ etc., connections. (Connection tracking system supports tracking of both statefull and stateless protocols) This tutorial demonstrates how OVS can use the connection tracking system -to match on the TCP segments from connection setup to connection teardown. +to match on the TCP segments from connection setup to connection tear down. It will use OVS with the Linux kernel module as the datapath for this tutorial. (The datapath that utilizes the openvswitch kernel module to do the packet processing in the Linux kernel) @@ -77,10 +77,10 @@ Possible values: - *snat* - *dnat* -Each of these flags is preceded by either a "+" for a flag that +Each of these flags are preceded by either a "+" for a flag that must be set, or a "-" for a flag that must be unset. Multiple flags can also be specified e.g. ct_state=+trk+new. -We will see the usage of some these flags below. For a detailed +We will see the usage of some of these flags below. For a detailed description, please see the OVS fields documentation at: http://openvswitch.org/support/dist-docs/ovs-fields.7.txt @@ -283,7 +283,7 @@ packets from "left" to "right" and from "right" to "left":: Instead of adding these two flows, we will add flows to match on the states of the TCP segments. -We will send the TCP connections setup segments namely: +We will send the TCP connection setup segments namely: syn, syn-ack and ack between hosts 192.168.0.2 in the "left" namespace and 10.0.0.2 in the "right" namespace. @@ -294,7 +294,7 @@ First, let's add a flow to start "tracking" a packet received at OVS. To start tracking a packet, it first needs to match a flow, which has action as "ct". This action sends the packet through the connection tracker. To identify that a packet is an "untracked" packet, the ct_state in the flow -match filed must be set to "-trk", which means it is not a tracked packet. +match field must be set to "-trk", which means it is not a tracked packet. Once the packet is sent to the connection tracker, then only we will know about its conntrack state. (i.e. whether this packet represents start of a new connection or the packet belongs to an existing connection or it is @@ -353,8 +353,8 @@ The conntrack module will now have an entry for this connection:: Note: At this stage, if the TCP syn packet is re-transmitted, it will again match flow #1 (since a new packet is untracked) and it will match flow #2. The reason it will match flow #2 is that although conntrack has information -about the connection, but it is not in established state, therefore it matches -the "new" state again. +about the connection, but it is not in "ESTABLISHED" state, therefore it +matches the "new" state again. Next for the TCP syn-ack from the opposite/server direction, we need following flows at OVS:: @@ -418,7 +418,7 @@ conntrack entry:: reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024), \ protoinfo=(state=ESTABLISHED) -The conntrck state stays in "ESTABLISHED" state, but now since it has received +The conntrack state stays in "ESTABLISHED" state, but now since it has received the ack from client, it will stay in this state for a longer time even without receiving any data on this connection. @@ -445,7 +445,7 @@ The acknowledgement for the data would hit flow #3 and flow #4. TCP Connection Teardown ~~~ -There are different ways to teardown TCP connection. We will teardown the +There are different ways to tear down TCP connection. We will tear down the connection by sending "fin" from client, "fin-ack" from server followed by the last "ack" by client. @@ -507,7 +507,7 @@ conntrack entry:: Summary --- -Following table summarizes the TCP segments exhanged against the flow +Following table summarizes the TCP segments exchanged against the flow match fields +---+---+ -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
