@@ -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;
@@ -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
@@ -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
@@ -1981,7 +1981,7 @@ 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
@@ -1989,7 +1989,7 @@ raft_run(struct raft *raft)
* 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. */
@@ -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));
@@ -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
@@ -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;
@@ -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)." */
@@ -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)
@@ -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
@@ -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