Page tree
Skip to end of metadata
Go to start of metadata

Attendees

Joseph Gasparakis (Intel)

Paul Carver (AT&T)
Henry Fowler (AT&T)

Others also joined but did not enter their names

Agenda

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

4.        Review https://review.opencontrail.org/#/c/46677/

Minutes

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 p
oint 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:


Design Documents:

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.  

  • No labels