ip_frag: fix order of key compare arguments
When using key compare function, it uses key length of the first argument to determine how long should be the keys that are compared. However, currently we are passing a key from the fragmentation table as first argument. the problem with this is that this key is potentially uninitialized (i.e. contains all zeroes, including key length). this leads to a nasty bug of comparing only the key id's and not keys themselves. Of course, a safer way would be to do RTE_MAX between key lengths, but since this compare is done per-packet, every cycle counts, so we just use the key whose length is guaranteed to be correct because it comes from an actual packet. Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This commit is contained in:
parent
148585ec29
commit
2505824261
@ -346,7 +346,7 @@ ip_frag_lookup(struct rte_ip_frag_tbl *tbl,
|
||||
max_cycles = tbl->max_cycles;
|
||||
assoc = tbl->bucket_entries;
|
||||
|
||||
if (tbl->last != NULL && ip_frag_key_cmp(&tbl->last->key, key) == 0)
|
||||
if (tbl->last != NULL && ip_frag_key_cmp(key, &tbl->last->key) == 0)
|
||||
return (tbl->last);
|
||||
|
||||
/* different hashing methods for IPv4 and IPv6 */
|
||||
@ -378,7 +378,7 @@ ip_frag_lookup(struct rte_ip_frag_tbl *tbl,
|
||||
p1, i, assoc,
|
||||
IPv6_KEY_BYTES(p1[i].key.src_dst), p1[i].key.id, p1[i].start);
|
||||
|
||||
if (ip_frag_key_cmp(&p1[i].key, key) == 0)
|
||||
if (ip_frag_key_cmp(key, &p1[i].key) == 0)
|
||||
return (p1 + i);
|
||||
else if (ip_frag_key_is_empty(&p1[i].key))
|
||||
empty = (empty == NULL) ? (p1 + i) : empty;
|
||||
@ -404,7 +404,7 @@ ip_frag_lookup(struct rte_ip_frag_tbl *tbl,
|
||||
p2, i, assoc,
|
||||
IPv6_KEY_BYTES(p2[i].key.src_dst), p2[i].key.id, p2[i].start);
|
||||
|
||||
if (ip_frag_key_cmp(&p2[i].key, key) == 0)
|
||||
if (ip_frag_key_cmp(key, &p2[i].key) == 0)
|
||||
return (p2 + i);
|
||||
else if (ip_frag_key_is_empty(&p2[i].key))
|
||||
empty = (empty == NULL) ?( p2 + i) : empty;
|
||||
|
Loading…
Reference in New Issue
Block a user