Joseph Gasparakis (Intel)
Paul Carver (AT&T)
Henry Fowler (AT&T)
Others also joined but did not enter their names
1. Argument --offloads -vs- --no-offloads
2. RTE Flow calls, specifically RSS –vs- RSS Pass thru actions
3. RTE Flow pattern: including a superset of all fields (as currently patches do) –vs- including the necessary fields
Currently the patches from Mellanox are introducing the --offloads argument to the (DPDK) vrouter. We discussed during the call about a concern that this will require:
1. The installers/bootstrapping tools/scripts to add this argument which might not be a big issue but...
2. It also seems like they need to know in advance if the server they are installing the vrouter on has any NICs installed with offloading capabilities
3. Finally it might be good to add some simple test when the vrouter enumerates the DPDK physical interfaces. It seems like a simple rte_flow_validate() should be enough. The expectation should be that supported NICs will return the right rte_flow_validate() return code (which will depend on how each vendor implements the stitching of their Poll Mode Drivers and RTE Flow API).
On top of that the current patches are using RSS action for rte_flow_add() calls. This might not be covering other smartNICs, currently it seems like intel's NICs would support RSS pass thru action. Maybe if we use rte_flow_validate() as per point 3. above, we could detect which NIC supports what action type and then store that action type in the etherdev structure of the port.
The above summary was sent out to the dev mailing list.
The Netronome patches (https://review.opencontrail.org/#/c/46677/) were not reviewed as engineers being currently involved are not quite in sync with previous efforts and asked the links of the two design documents previously generated in the TF community. These links are here:
Partial offload (Software Data Path + Assistance from the NIC for specific functionalities such as classification): https://docs.google.com/document/d/1gxzC6xz-qnTv5r6Gt5KZgNHER6eFI29DZkpKt4RxhY4/edit
- Full offload (Hardware Data Path): https://docs.google.com/document/d/1c8U8d3uCXNwbDMjMsmCOhIo-n3VnKPASRhhRH6HEGpE/edit
Finally attendees were reminded that we will need to get to the bottom of the proposed changes to the Linux Kernel TC in order to be able to have an open source TF full offload proposal.