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 BC04B4388B; Fri, 12 Jan 2024 17:00:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9C7340633; 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 513FE402AD 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-688-mZ5bORC1Oq-IiY61lO60Xw-1; Fri, 12 Jan 2024 11:00:22 -0500 X-MC-Unique: mZ5bORC1Oq-IiY61lO60Xw-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-50e73a71c8aso4494202e87.3 for ; Fri, 12 Jan 2024 08:00:21 -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=bSKMkI6sSRt4NpwfoxzHkWjCUdrVeP11TOnjb44FPPt5W3Eqcw0npyoSLqd4DrJnUJ sRuwIP+xknWlxry9iiCx6TFdtmnTM50kbyVZ4ftxRhfYltrDLIvuDxdraaftS2v23wdT DIiXm7z4KLAkTM9Fytswy46uXGSUR8vE7fdOkel4eORVKpzv+qcbwGQSVQkPN9owYjmG ZpynefnsbMyazlCNITDfr/IVnkdVo9hs45YVh5TcDzF6SBvvm2q78OhE4mo0LVlypgSe Ibi6jCQwDwFgUG7KVzDcsoFgjDW9xiAiCEAqYE9uRchb642/INJ/gM530+/Itxzc9Pd0 xFMA== X-Gm-Message-State: AOJu0YzET9MDhkb+Rcu0GCZ35l4D3HPpe10ObH3xaho8ZTbY8kTYsh3x s9GZadSbIioC0PsXaZ2y9Flg2rQ0nbA64Cjk2nCBNoMXX0klpXN986jPfTCBTCclvqk/xJgcNZa jE6whyeLJz39cLaBPXCSQ1K4RVTI= X-Received: by 2002:a05:6512:3f06:b0:50e:7d75:de70 with SMTP id y6-20020a0565123f0600b0050e7d75de70mr480036lfa.28.1705075220810; 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: 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 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