On 3/12/23 13:54, Ivan Malov wrote:
The driver supports representor functionality. In it, packets coming from VFs to the dedicated back-end Rx queue get demultiplexed into front-end Rx queues of representor ethdevs as per the per-packet metadata indicating logical HW ingress ports. On transmit, packets are provided with symmetrical metadata by front-end Tx queues, and the back-end queue transforms the data into so-called Tx override descriptors. These let the packets bypass flow lookup and go directly to the represented VFs.However, in the Rx part, the driver extracts the said metadata on every HW Rx queue, that is, not just on the one used by representors. Doing so leads to a buggy behaviour. It is revealed by operating testpmd as follows: dpdk-testpmd -a 0000:c6:00.0 -a 0000:c6:00.1 -- -i testpmd> flow create 0 transfer pattern port_representor \ port_id is 0 / end actions port_representor port_id 1 / end Flow rule #0 created testpmd> set fwd io testpmd> start tx_first testpmd> flow destroy 0 rule 0 Flow rule #0 destroyed testpmd> stop ---------------------- Forward statistics for port 0 ----------------- RX-packets: 19196498 RX-dropped: 0 RX-total: 19196498 TX-packets: 19196535 TX-dropped: 0 TX-total: 19196535 ----------------------------------------------------------------------- ---------------------- Forward statistics for port 1 ----------------- RX-packets: 19196503 RX-dropped: 0 RX-total: 19196503 TX-packets: 19196530 TX-dropped: 0 TX-total: 19196530 ----------------------------------------------------------------------- In this scenario, two physical functions of the adapter do not have any corresponding "back-to-back" forwarder on peer host. Packets transmitted from port 0 can only be forwarded to port 1 by means of a special flow rule. The flow rule indeed works, but destroying it does not stop forwarding. Port statistics carry on incrementing. Also, it is apparent that forwarding in the opposite direction must not have worked in this case as the flow is meant to target only one of the directions. Because of the bug, the first 32 mbufs received as a result of the flow rule operation have the said metadata present. In io mode, testpmd does not tamper with mbufs and passes them directly to transmit path, so this data remains in them instructing the PMD to override destinations of the packets via Tx option descriptors. Expected behaviour is as follows: ---------------------- Forward statistics for port 0 ----------------- RX-packets: 0 RX-dropped: 0 RX-total: 0 TX-packets: 15787496 TX-dropped: 0 TX-total: 15787496 ----------------------------------------------------------------------- ---------------------- Forward statistics for port 1 ----------------- RX-packets: 15787464 RX-dropped: 0 RX-total: 15787464 TX-packets: 32 TX-dropped: 0 TX-total: 32 ----------------------------------------------------------------------- These figures show the rule work only for one direction. Also, removing the flow shall cause forwarding to cease. Provided patch fixes the bug accordingly. Fixes: d0f981a3efd8 ("net/sfc: handle ingress mport in EF100 Rx prefix") Cc: sta...@dpdk.org Signed-off-by: Ivan Malov <ivan.ma...@arknetworks.am> Reviewed-by: Andy Moreton <amore...@xilinx.com>
Acked-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
