onvm_pkt_parse_ip fix#104
Conversation
CI MessageYour results will arrive shortly |
CI MessageRun successful see results: Linter Failedexamples/aes_decrypt/aes.h:176: #endif line should be "#endif // AES_H" [build/header_guard] [5] |
|
As briefly discussed don't overwrite the packet data, just use the function when you need to compare. |
Fixed, looking at other NF's doing the comparison and updating accordingly |
|
is your ordering now the same as in this code? https://github.com/FOXNEOAdvancedTechnology/MinimalDPDKExamples/blob/master/minimal_tx/minimal_tx.c#L68 |
Yes, it is the same. It follows what the IPv4 function is doing here: http://doc.dpdk.org/api/rte__ip_8h.html#a052e2a96de0562a034776fa758255650 |
There was a problem hiding this comment.
Tested, works as expected. Although missing a small change. Fix it and I'll merge/
load_balancer line 549 (this address is parsed using the affected onvm_pkt_parse_ip function)
change ip->dst_addr = lb->server[flow_info->dest].d_ip; to ip->dst_addr = rte_cpu_to_be_32(lb->server[flow_info->dest].d_ip;) (we have to send in bid endian)
|
Should be good to go |
|
Just in case @onvm |
CI MessageYour results will arrive shortly |
CI MessageRun successful see results: Linter Failedexamples/aes_decrypt/aes.h:176: #endif line should be "#endif // AES_H" [build/header_guard] [5] |
We've been parsing string based IP's in reverse order, this aims to fix that functionality and make modifications to NF's using this function as needed.
Summary:
Previously, we have been converting IP's in string form to IPv4 format in reverse order (IPv4(ip[3], ip[2], ip[1], ip[0]) this PR modifies this to parse in proper format (IPv4(ip[0], ip[1], ip[2], ip[3])
Usage:
Merging notes:
NF's seperate from nf_router use this functionality. We must assure those are modified to match this ordering of IPv4.
TODO before merging :
Test Plan:
Tested this with Pktgen with nf_router running. Assured that IP address being sent from Pktgen matched the properly parsed IP address in the route.conf file.
Review: