On 4/12/2023 2:57 PM, 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>
Applied to dpdk-next-net/main, thanks.
