Skip to content

Commit

Permalink
ovs: fix wrong quote
Browse files Browse the repository at this point in the history 
Remove the coma character by using ' and " character.

Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
  • Loading branch information
@wyjwang @blp
wyjwang authored and blp committed Jul 6, 2021
1 parent 00c1bce commit 828d9cb
Show file tree
Hide file tree
Showing 3 changed files with 26 additions and 26 deletions.
4 changes: 2 additions & 2 deletions lib/dpif-netdev.c
View file
Expand Up @@ -7513,12 +7513,12 @@ dp_netdev_input__(struct dp_netdev_pmd_thread *pmd,

/* All the flow batches need to be reset before any call to
* packet_batch_per_flow_execute() as it could potentially trigger
* recirculation. When a packet matching flow ‘j’ happens to be
* recirculation. When a packet matching flow 'j' happens to be
* recirculated, the nested call to dp_netdev_input__() could potentially
* classify the packet as matching another flow - say 'k'. It could happen
* that in the previous call to dp_netdev_input__() that same flow 'k' had
* already its own batches[k] still waiting to be served. So if its
* ‘batch’ member is not reset, the recirculated packet would be wrongly
* 'batch' member is not reset, the recirculated packet would be wrongly
* appended to batches[k] of the 1st call to dp_netdev_input__(). */
for (i = 0; i < n_batches; i++) {
batches[i].flow->batch = NULL;
Expand Down
24 changes: 12 additions & 12 deletions lib/flow.h
View file
Expand Up @@ -595,20 +595,20 @@ struct mf_for_each_in_map_aux {
size_t unit; /* Current 64-bit unit of the flowmaps
being processed. */
struct flowmap fmap; /* Remaining 1-bits corresponding to the
64-bit words in ‘values’ */
64-bit words in 'values' */
struct flowmap map; /* Remaining 1-bits corresponding to the
64-bit words of interest. */
const uint64_t *values; /* 64-bit words corresponding to the
1-bits in ‘fmap’. */
1-bits in 'fmap'. */
};

/* Get the data from ‘aux->values’ corresponding to the next lowest 1-bit
* in ‘aux->map’, given that ‘aux->values’ points to an array of 64-bit
* words corresponding to the 1-bits in ‘aux->fmap’, starting from the
/* Get the data from 'aux->values' corresponding to the next lowest 1-bit
* in 'aux->map', given that 'aux->values' points to an array of 64-bit
* words corresponding to the 1-bits in 'aux->fmap', starting from the
* rightmost 1-bit.
*
* Returns ’true’ if the traversal is incomplete, ‘false’ otherwise.
* ‘aux’ is prepared for the next iteration after each call.
* Returns 'true' if the traversal is incomplete, 'false' otherwise.
* 'aux' is prepared for the next iteration after each call.
*
* This is used to traverse through, for example, the values in a miniflow
* representation of a flow key selected by non-zero 64-bit words in a
Expand All @@ -634,12 +634,12 @@ mf_get_next_in_map(struct mf_for_each_in_map_aux *aux,
*map -= rm1bit;
fmap = &aux->fmap.bits[aux->unit];

/* If the rightmost 1-bit found from the current unit in ‘aux->map’
* (‘rm1bit’) is also present in ‘aux->fmap’, store the corresponding
* value from ‘aux->values’ to ‘*value', otherwise store 0. */
/* If the rightmost 1-bit found from the current unit in 'aux->map'
* ('rm1bit') is also present in 'aux->fmap', store the corresponding
* value from 'aux->values' to '*value', otherwise store 0. */
if (OVS_LIKELY(*fmap & rm1bit)) {
/* Skip all 64-bit words in ‘values’ preceding the one corresponding
* to ‘rm1bit’. */
/* Skip all 64-bit words in 'values' preceding the one corresponding
* to 'rm1bit'. */
map_t trash = *fmap & (rm1bit - 1);

/* Avoid resetting 'fmap' and calling count_1bits() when trash is
Expand Down
24 changes: 12 additions & 12 deletions ovsdb/raft.c
View file
Expand Up @@ -1981,15 +1981,15 @@ raft_run(struct raft *raft)
* follower.
*
* Raft paper section 6.2: Leaders: A server might be in the leader
* state, but if it isn’t the current leader, it could be
* state, but if it isn't the current leader, it could be
* needlessly delaying client requests. For example, suppose a
* leader is partitioned from the rest of the cluster, but it can
* still communicate with a particular client. Without additional
* mechanism, it could delay a request from that client forever,
* being unable to replicate a log entry to any other servers.
* Meanwhile, there might be another leader of a newer term that is
* able to communicate with a majority of the cluster and would be
* able to commit the client’s request. Thus, a leader in Raft
* able to commit the client's request. Thus, a leader in Raft
* steps down if an election timeout elapses without a successful
* round of heartbeats to a majority of its cluster; this allows
* clients to retry their requests with another server. */
Expand Down Expand Up @@ -2733,8 +2733,8 @@ raft_become_leader(struct raft *raft)
* which those are. To find out, it needs to commit an entry from its
* term. Raft handles this by having each leader commit a blank no-op
* entry into the log at the start of its term. As soon as this no-op
* entry is committed, the leader’s commit index will be at least as
* large as any other servers’ during its term.
* entry is committed, the leader's commit index will be at least as
* large as any other servers' during its term.
*/
raft_command_unref(raft_command_execute__(raft, NULL, NULL, 0, NULL,
NULL));
Expand All @@ -2750,7 +2750,7 @@ raft_receive_term__(struct raft *raft, const struct raft_rpc_common *common,
/* Section 3.3 says:
*
* Current terms are exchanged whenever servers communicate; if one
* server’s current term is smaller than the other’s, then it updates
* server's current term is smaller than the other's, then it updates
* its current term to the larger value. If a candidate or leader
* discovers that its term is out of date, it immediately reverts to
* follower state. If a server receives a request with a stale term
Expand Down Expand Up @@ -3130,8 +3130,8 @@ raft_update_leader(struct raft *raft, const struct uuid *sid)
if (raft->role == RAFT_CANDIDATE) {
/* Section 3.4: While waiting for votes, a candidate may
* receive an AppendEntries RPC from another server claiming to
* be leader. If the leader’s term (included in its RPC) is at
* least as large as the candidate’s current term, then the
* be leader. If the leader's term (included in its RPC) is at
* least as large as the candidate's current term, then the
* candidate recognizes the leader as legitimate and returns to
* follower state. */
raft->role = RAFT_FOLLOWER;
Expand All @@ -3145,7 +3145,7 @@ raft_handle_append_request(struct raft *raft,
{
/* We do not check whether the server that sent the request is part of the
* cluster. As section 4.1 says, "A server accepts AppendEntries requests
* from a leader that is not part of the server’s latest configuration.
* from a leader that is not part of the server's latest configuration.
* Otherwise, a new server could never be added to the cluster (it would
* never accept any log entries preceding the configuration entry that adds
* the server)." */
Expand Down Expand Up @@ -3492,7 +3492,7 @@ raft_handle_append_reply(struct raft *raft,
* more quickly, including those described in Chapter 3. The simplest
* approach to solving this particular problem of adding a new server,
* however, is to have followers return the length of their logs in the
* AppendEntries response; this allows the leader to cap the follower’s
* AppendEntries response; this allows the leader to cap the follower's
* nextIndex accordingly." */
s->next_index = (s->next_index > 0
? MIN(s->next_index - 1, rpy->log_end)
Expand Down Expand Up @@ -3557,8 +3557,8 @@ raft_should_suppress_disruptive_server(struct raft *raft,
* election without waiting an election timeout. In that case,
* RequestVote messages should be processed by other servers even when
* they believe a current cluster leader exists. Those RequestVote
* requests can include a special flag to indicate this behavior (“I
* have permission to disrupt the leader--it told me to!”).
* requests can include a special flag to indicate this behavior ("I
* have permission to disrupt the leader--it told me to!").
*
* This clearly describes how the followers should act, but not the leader.
* We just ignore vote requests that arrive at a current leader. This
Expand Down Expand Up @@ -3613,7 +3613,7 @@ raft_handle_vote_request__(struct raft *raft,
}

/* Section 3.6.1: "The RequestVote RPC implements this restriction: the RPC
* includes information about the candidate’s log, and the voter denies its
* includes information about the candidate's log, and the voter denies its
* vote if its own log is more up-to-date than that of the candidate. Raft
* determines which of two logs is more up-to-date by comparing the index
* and term of the last entries in the logs. If the logs have last entries
Expand Down

0 comments on commit 828d9cb

Please sign in to comment.