From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51CDD428FD; Sun, 9 Apr 2023 10:00:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D661D4067E; Sun, 9 Apr 2023 10:00:13 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 154E240141; Sun, 9 Apr 2023 10:00:12 +0200 (CEST) Received: from [192.168.1.126] (unknown [188.242.181.57]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id ECCCF62; Sun, 9 Apr 2023 11:00:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru ECCCF62 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1681027211; bh=rplTAzLCqZumbkO1TgjRdhud6ucFZV5SC7kLAoZn70U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BRZs7fUY8rMKPX/xaCK6jkos32jiNgT3FNb0qp/Z0aYAVOPFMQDuiIG1XwT5qYUPV Ithy+6XAOTaL8KaWcyi6uoufDvx9m+TSvarvJ4YQuG07GQF963v1++rORsUL2SxAIg xW0elWuHaJxwZWHWqLhZZpcpLn0FDBTtECvv4VvA= Message-ID: Date: Sun, 9 Apr 2023 11:00:03 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v3] net/sfc: stop misuse of Rx ingress m-port metadata on EF100 To: Ivan Malov , dev@dpdk.org Cc: Ferruh Yigit , stable@dpdk.org, Andy Moreton References: <20230309041101.8321-1-ivan.malov@arknetworks.am> <20230312105426.6732-1-ivan.malov@arknetworks.am> Content-Language: en-US From: Andrew Rybchenko In-Reply-To: <20230312105426.6732-1-ivan.malov@arknetworks.am> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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: stable@dpdk.org > > Signed-off-by: Ivan Malov > Reviewed-by: Andy Moreton Acked-by: Andrew Rybchenko