Hi Aaron, Thanks for your feedback.
Aaron Conole, Mar 07, 2023 at 19:57: > I'm concerned about this - this is a negative interference with rte_flow > offload. And rte_flow offload would also just alleviate these problems, > yes? Maybe we should encourage a user to just turn on flow offloading? Indeed this feature will not get along with rte_flow offload, but as you said, if your hardware and flow pipeline are compatible with rte_flow offload, then, you probably don't need this feature since your PMD threads will only handle a limited portion of the data plane traffic. The CP protection flows are very basic (for LACP, only matching the ether type, no VLAN support needed, etc.) and they should be supported by a broad range of NICs (even Intel 82599 Niantic from 2013). This feature is mostly aimed at pure DPDK (without extended rte_flow offload support) where LACP is mixed in the same queues and processed by the same CPUs than data plane traffic. > Additionally, it doesn't seem to have a good solution for kernel side. For non-DPDK use cases, I see two separate paths. Please do correct me if I am wrong: 1) pure kernel (not tested, only from ethtool(8)) ethtool -L $dev rx $((rxqs + 1)) ethtool -X $dev equal $((rxqs - 1)) ethtool -U $dev flow-type ether proto 0x8809 m 0xffff action $rxqs 2) tc flow offload Only mlx5 supported hardware is concerned and there should be direct support for hardware bond offload (LACP handled in the NIC). > And I worry about adding flows into the system that the ofproto layer > doesn't know about but will interact with - but maybe I'm just being > paranoid. There should be no overlap with the ofproto layer. The CP protection flows only route certain packets into certain RXQs. The packets are still processed by the same pipeline. I understand your reservations as this involves intrusive elements in the packet flow and does not play well with RTE flow offload. However, actual openflow pipelines (like the ones in OVN deployments) are supported in RTE flow by a limited and recent set of hardware. Users with existing deployments and older hardware cannot benefit from this. This feature could allow making these environments more resilient and less prone to link flapping. Also, given that cp-protection is disabled by default, there will be no conflict with DPDK hw-offload when there is hardware support. What do you think? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
