[dpdk-dev] [PATCH v5 1/3] app/testpmd: add GENEVE parsing

[Ferruh Yigit]

On 10/7/2020 3:52 PM, Ophir Munk wrote:
> Hi Ferruh,
> Please find comments inline.
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit at intel.com>
>> Sent: Tuesday, October 6, 2020 5:31 PM
>> To: Ophir Munk <ophirmu at nvidia.com>; dev at dpdk.org; Wenzhuo Lu
> <...>
>>>
>>>    uint16_t vxlan_gpe_udp_port = 4790;
>>> +uint16_t geneve_udp_port = RTE_GENEVE_DEFAULT_PORT;
>>>
>>
>> There is a testpmd command to configure the NIC for GENEVE port, "port
>> config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe
>> (udp_port)"
>>
>> You are adding support to testpmd to parse the GENEVE packets, but I think
>> these two commads should be consistent.
>>
>> What do you think "port config N add geneve X" update the
>> 'geneve_udp_port=X"?
>>
>> <...>
>>
> 
> It is not as simple as suggested.
> The command "port config N add geneve X" can be repeated several times - adding another geneve port to the NIC Hardware/Firmware to recognize. As a result the NIC is configured with multiple geneve ports. On the other hand geneve_udp_port is a single variable - so whenever a new "port config" command is executed - we will override the last geneve port and forget all the precedent ones.
> The port config command also has a "rm" option in addition to "add". So if we removed the last port - what will we assigned to geneve_udp_port? We need to have a small data base for managing geneve ports.
> testpmd also has an option " --geneve-port=N". It should be synched with the "port config" command.
> 
> Another issue to consider is if there is a need for the suggested feature. I think the "port config" is mainly targeted for offloading. So the NIC will probably encap/decap a packet with geneve - leaving testpmd paring unneeded.
> 
> My point is that your suggestion requires an RFC before implementation.
> 

I am not sure about adding database for geneve ports, I think no need to make it 
more complex.

Only when user set via "--geneve-port=N", it is the port for testpmd to parse 
(same for 'geneve_udp_port' global variable), but when user give command "port 
config N add geneve X" it is to configure the NIC to offload the parsing.
This is too confusing, user can't know (or remember) this without checking the 
source code.

Can we rename the command and variable to highlight that it is for testpmd to 
parse, I think that will be enough, instead of trying to merge them, which is 
hard as you described above.

What do you think for "--testpmd-geneve-port=N" parameter and 
'testpmd_geneve_udp_port' variable name?
We can also update the documentation to say this is only the port testpmd uses 
for parsing, HW may be configured to use another port.


>>
>>> @@ -865,9 +925,17 @@ pkt_burst_checksum_forward(struct fwd_stream
>> *fs)
>>>    				}
>>>    				parse_vxlan(udp_hdr, &info,
>>>    					    m->packet_type);
>>> -				if (info.is_tunnel)
>>> +				if (info.is_tunnel) {
>>>    					tx_ol_flags |=
>>>    						PKT_TX_TUNNEL_VXLAN;
>>> +					goto tunnel_update;
>>> +				}
>>> +				parse_geneve(udp_hdr, &info);
>>> +				if (info.is_tunnel) {
>>> +					tx_ol_flags |=
>>> +						PKT_TX_TUNNEL_GENEVE;
>>> +					goto tunnel_update;
>>> +				}
>>
>> Can you please update the "csum parse-tunnel" documentation to mention
>> "geneve"
>> protocol?
> 
> Done in v6. I added other missing tunnel protocols (in alphabetical order) such as "gtp". Since it is more than geneve I added it to the 3rd (cleanup) commit.
> 

Would you mind adding the 'geneve' with the patch adding 'geneve' support (1/3), 
and add the other missing ones in the patch 3/3 ?