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 C69EC4388B for ; Fri, 12 Jan 2024 17:00:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AFDE9402AD; Fri, 12 Jan 2024 17:00:25 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 25C434028C for ; Fri, 12 Jan 2024 17:00:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705075223; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cAG/kK0A18DstYJEp1K6NZNxQfrgd+/pknhPtA9KXrQ=; b=XZFucP0L29eKZTEmXomAup53wja76+LzZWu7FbA6CXRuZjv0rqHBDggHDdGoFyp3MlI8Fc 9VX12b6XwhaBHV9cdnvKrGnAvhAFgK1L7gr6jouqEqvZv7CjLE81PsKRV19N7+egLVPYCb A5oA9dpQHG57/AYqjIULF48VAlq0E+I= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-424-bxFERnGDPNuZJ-iP3p54-Q-1; Fri, 12 Jan 2024 11:00:22 -0500 X-MC-Unique: bxFERnGDPNuZJ-iP3p54-Q-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-50ea9e189dcso5651679e87.2 for ; Fri, 12 Jan 2024 08:00:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705075221; x=1705680021; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cAG/kK0A18DstYJEp1K6NZNxQfrgd+/pknhPtA9KXrQ=; b=we8Ar7z4JnJhaf6ayx+ay89U+FRb7ZPNM1dxoBP94pdxgHjYByuBUrzZeV1+q81jS8 CeQ/aK+yerkemD/Zj4cF6nHZJ7igAvBwLicGc0dCsI/8MqeCkdFsDimzcYpryyc/zDmx lMaVdQI0UlIwOMu2yJFCyr5PbhfQ4sLlvS+tyLQaM3gKcrp2PMJgJtz8tKH3KrVkoMvD 1QTQwU8Snz+62fzSPHOLs0Te4wFoqlnKP7nlp5PQRtOKvISO+d30h2Oyuu7YgRgIxznn shqeoXeM6LtOC4xFa3AMc2SwwF96ytIHfvwLSca8XlYk7fOey/XIh5AVnxMbnIINupge /Bqg== X-Gm-Message-State: AOJu0YzZCqyIVmYKUEGJswOTpKDp9GT7agkqaVKMNP5E5fbZG+TMIWHQ dJisk/w7NgmWMFE+fMm7HbWh9q6KQBcea8y3HZh9ubquD6CyXKuY1qlyJYG9n1+07TVml1EhbNn VxboBPor90u6HpQrX0Pk3i+WlxOSIxps= X-Received: by 2002:a05:6512:3f06:b0:50e:7d75:de70 with SMTP id y6-20020a0565123f0600b0050e7d75de70mr480042lfa.28.1705075220842; Fri, 12 Jan 2024 08:00:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IFS9hgHU4s1fQJ0kEoxPErQOa3wiOe88m1cKqY2HeU2Pu7mdnVw+Wsacf1Lju0hubYwDJRJAVyD5n3KSg5PZGw= X-Received: by 2002:a05:6512:3f06:b0:50e:7d75:de70 with SMTP id y6-20020a0565123f0600b0050e7d75de70mr480030lfa.28.1705075220498; Fri, 12 Jan 2024 08:00:20 -0800 (PST) MIME-Version: 1.0 References: <20240103012912.4334-1-kaiwenx.deng@intel.com> <20240111052555.35930-1-kaiwenx.deng@intel.com> In-Reply-To: <20240111052555.35930-1-kaiwenx.deng@intel.com> From: David Marchand Date: Fri, 12 Jan 2024 17:00:07 +0100 Message-ID: Subject: Re: [PATCH v2] app/testpmd: use Tx preparation in txonly engine To: Kaiwen Deng Cc: dev@dpdk.org, stable@dpdk.org, qiming.yang@intel.com, yidingx.zhou@intel.com, Aman Singh , Yuying Zhang , Ferruh Yigit , Jerin Jacob Kollanukkaran X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Thu, Jan 11, 2024 at 7:06=E2=80=AFAM Kaiwen Deng wrote: > > Txonly forwarding engine does not call the Tx preparation API > before transmitting packets. This may cause some problems. > > TSO breaks when MSS spans more than 8 data fragments. Those > packets will be dropped by Tx preparation API, but it will cause > MDD event if txonly forwarding engine does not call the Tx preparation > API before transmitting packets. > > We can reproduce this issue by these steps list blow on ICE and I40e. > > ./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0xf -n 4 -- -i > --tx-offloads=3D0x00008000 > > testpmd>set txpkts 64,128,256,512,64,128,256,512,512 > testpmd>set burst 1 > testpmd>start tx_first 1 > > This commit will use Tx preparation API in txonly forwarding engine. > > Fixes: 655131ccf727 ("app/testpmd: factorize fwd engines Tx") > Cc: stable@dpdk.org > > Signed-off-by: Kaiwen Deng I did not see a reply to Jerin concern on performance impact of this change= . Some additional comment below. > --- > app/test-pmd/txonly.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c > index c2b88764be..9dc53553a7 100644 > --- a/app/test-pmd/txonly.c > +++ b/app/test-pmd/txonly.c > @@ -335,13 +335,16 @@ pkt_burst_transmit(struct fwd_stream *fs) > struct rte_mbuf *pkts_burst[MAX_PKT_BURST]; > struct rte_port *txp; > struct rte_mbuf *pkt; > + struct rte_mbuf *mb; > struct rte_mempool *mbp; > struct rte_ether_hdr eth_hdr; > uint16_t nb_tx; > uint16_t nb_pkt; > + uint16_t nb_prep; > uint16_t vlan_tci, vlan_tci_outer; > uint64_t ol_flags =3D 0; > uint64_t tx_offloads; > + char buf[256]; > > mbp =3D current_fwd_lcore()->mbp; > txp =3D &ports[fs->tx_port]; > @@ -396,7 +399,19 @@ pkt_burst_transmit(struct fwd_stream *fs) > if (nb_pkt =3D=3D 0) > return false; > > - nb_tx =3D common_fwd_stream_transmit(fs, pkts_burst, nb_pkt); > + nb_prep =3D rte_eth_tx_prepare(fs->tx_port, fs->tx_queue, > + pkts_burst, nb_pkt); > + if (unlikely(nb_prep !=3D nb_pkt)) { The buf variable declaration can be moved at the start of this block as buf is not needed anywhere else. > + mb =3D pkts_burst[nb_prep]; > + rte_get_tx_ol_flag_list(mb->ol_flags, buf, sizeof(buf)); You don't need a mb variable, simply pass pkts_burst[nb_prep]->ol_flags. rte_get_tx_ol_flag_list() return value must be checked for the (theoretical) case when the 'buf' variable is too short to avoid the below fprintf outputting garbage since buf may be unterminated. > + fprintf(stderr, > + "Preparing packet burst to transmit failed: %s ol= _flags: %s\n", > + rte_strerror(rte_errno), buf); > + fs->fwd_dropped +=3D nb_pkt - nb_prep; > + rte_pktmbuf_free_bulk(&pkts_burst[nb_prep], nb_pkt - nb_p= rep); > + } > + > + nb_tx =3D common_fwd_stream_transmit(fs, pkts_burst, nb_prep); > > if (txonly_multi_flow) > RTE_PER_LCORE(_src_port_var) -=3D nb_pkt - nb_tx; > -- > 2.34.1 > --=20 David Marchand