|
69 | 69 | * |
70 | 70 | * By design there should only be *one* "controlling" process. In practice |
71 | 71 | * multiple write accesses gives unpredictable result. Understood by "write" |
72 | | - * to /proc gives result code thats should be read be the "writer". |
| 72 | + * to /proc gives result code that should be read be the "writer". |
73 | 73 | * For practical use this should be no problem. |
74 | 74 | * |
75 | 75 | * Note when adding devices to a specific CPU there good idea to also assign |
@@ -2371,11 +2371,11 @@ static void get_ipsec_sa(struct pktgen_dev *pkt_dev, int flow) |
2371 | 2371 |
|
2372 | 2372 | if (pkt_dev->spi) { |
2373 | 2373 | /* We need as quick as possible to find the right SA |
2374 | | - * Searching with minimum criteria to archieve this. |
| 2374 | + * Searching with minimum criteria to achieve, this. |
2375 | 2375 | */ |
2376 | 2376 | x = xfrm_state_lookup_byspi(pn->net, htonl(pkt_dev->spi), AF_INET); |
2377 | 2377 | } else { |
2378 | | - /* slow path: we dont already have xfrm_state */ |
| 2378 | + /* slow path: we don't already have xfrm_state */ |
2379 | 2379 | x = xfrm_stateonly_find(pn->net, DUMMY_MARK, 0, |
2380 | 2380 | (xfrm_address_t *)&pkt_dev->cur_daddr, |
2381 | 2381 | (xfrm_address_t *)&pkt_dev->cur_saddr, |
@@ -3838,8 +3838,8 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname) |
3838 | 3838 | pkt_dev->ipsmode = XFRM_MODE_TRANSPORT; |
3839 | 3839 | pkt_dev->ipsproto = IPPROTO_ESP; |
3840 | 3840 |
|
3841 | | - /* xfrm tunnel mode needs additional dst to extract outter |
3842 | | - * ip header protocol/ttl/id field, here creat a phony one. |
| 3841 | + /* xfrm tunnel mode needs additional dst to extract outer |
| 3842 | + * ip header protocol/ttl/id field, here create a phony one. |
3843 | 3843 | * instead of looking for a valid rt, which definitely hurting |
3844 | 3844 | * performance under such circumstance. |
3845 | 3845 | */ |
|
0 commit comments