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 7AD3F43ADA for ; Thu, 8 Feb 2024 13:10:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 709BF4114B; Thu, 8 Feb 2024 13:10:20 +0100 (CET) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by mails.dpdk.org (Postfix) with ESMTP id 5AABD40278; Thu, 8 Feb 2024 13:10:18 +0100 (CET) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-42a4516ec46so8292221cf.0; Thu, 08 Feb 2024 04:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707394217; x=1707999017; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/oL03uJbNlb+a4+6k/Fr6jOQC6cj4KjrWU2OlpUD5n4=; b=AMPCk7iNPLtgFV5tzODObSmx5dgX0lI6EtnkInPFzSmTMDp/JFH17zn8A3a1EYXpnU ekdF1BB0gT+Mfs5VfjzbPv/GveeXcSvQ5XggQLTdnRINvsIJJMCDFH8rEHt2X37SNs1j fxMV8/yCgvMJCSWBP6koRuLeiyBSIUNQnE4dbeHa7tB6exCPT7UXig74n2t2XQ75m/1n 1sLPmegBDuQ4DTo2W3qbO8ejahG2v2tgsByk9yDPJnw0RkBdHpRHZ4Pc8JykW1AIsel+ zIcWWYSu8ONgTkU9dRGVeYNNaXTxG5xCeDjQXOYnwRxuL1sZ4eC5koXSnMXudbjoc2rH 6FJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707394217; x=1707999017; 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=/oL03uJbNlb+a4+6k/Fr6jOQC6cj4KjrWU2OlpUD5n4=; b=mAwcwGh3EhidTbN8EPNTBy8Cna2rUfHKkzFoBXaO05zvmosF6H7BsUbKjTZ8q2WEpd QCcOfLOjxQDdZUz5Qtj/FX8ndnV1TL7jpHx+GyL7kBpioVbDDmQRwsUwLA/mOA5bsdBf 3XbiEoRu1Pfeb1afqZ+mvb2GHVY4Vdfh3Nxs6G0xxQvu4sQ5Pw+rSmkQfgJ7VFIiRSGy cxo0Q3yIrFMgUmYgdkqi18XuouVqEZ2LIfrgdzIPYWTJMeuJwyqu+51PxmwwG1o9/1US LrWylBdWA5MmimGP8SNXY4xS2JscMTKPGbb1uyrZmaJjot8Q+VBObCaqmpBpx46pw22E qAYA== X-Gm-Message-State: AOJu0YwvfGu4Y5YwPvHkVRV32gAWVI4I6lW1YbmDrm1QnqX3ZygkSr0N C1sN0L7f6cNtaVCXhCIG93cIOop6HUUQ3OjhI6hKUNmWIDVF/qXX1lZz9IpTSZazN5ph93Xq+3d /vwNiqd2KowTBmsWm8UUdKkwXtFhKLSb/qns= X-Google-Smtp-Source: AGHT+IEUG4qm6wFIIPk+++0Bz9j0J0y9BnQvqm4tgyGWGaa9lQS5THbK7ZR92HkxcqEInUAkR4WYWe4Hy1I911KxODo= X-Received: by 2002:a05:622a:1b87:b0:42c:455e:5863 with SMTP id bp7-20020a05622a1b8700b0042c455e5863mr4130720qtb.7.1707394217578; Thu, 08 Feb 2024 04:10:17 -0800 (PST) MIME-Version: 1.0 References: <20240103012912.4334-1-kaiwenx.deng@intel.com> <20240111052555.35930-1-kaiwenx.deng@intel.com> <38baef9c-103a-4be4-8546-e9ea35abc46f@amd.com> In-Reply-To: <38baef9c-103a-4be4-8546-e9ea35abc46f@amd.com> From: Jerin Jacob Date: Thu, 8 Feb 2024 17:39:51 +0530 Message-ID: Subject: Re: [PATCH v2] app/testpmd: use Tx preparation in txonly engine To: Ferruh Yigit , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Konstantin Ananyev Cc: Kaiwen Deng , dev@dpdk.org, stable@dpdk.org, qiming.yang@intel.com, yidingx.zhou@intel.com, Aman Singh , Yuying Zhang , David Marchand 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, Feb 8, 2024 at 6:15=E2=80=AFAM Ferruh Yigit = wrote: > > On 1/11/2024 5:25 AM, 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. > > > > txonly is used commonly, adding Tx prepare for a specific case may > impact performance for users. > > What happens when driver throws MDD (Malicious Driver Detection) event, > can't it be ignored? As you are already OK to drop the packet, can > device be configured to drop these packages? > > > Or as Jerin suggested adding a new forwarding engine is a solution, but > that will create code duplication, I prefer to not have it if this can We don't need to have full-blown NEW need forwarding engine. Just that, we need to select correct ".packet_fwd" based on the offload requirements. It is easy to avoid code duplication by following without performance impact by moving the logic to compile time and use runtime to fix up static inline generic_tx_only_packet_forward(...., const unsigned flag) { #logic common for both packet forward #if (flag & NEED_PREPARE) prepare specific code } static generic_tx_only_packet_forward_without_prepare() { generic_tx_only_packet_forward(..., 0); } static generic_tx_only_packet_forward_with_prepare() { generic_tx_only_packet_forward(..., NEED_PREPARE); } Select the correct .packet_fwd in runtime(generic_tx_only_packet_forward_without_prepare() vs generic_tx_only_packet_forward_with_prepare()) > be handled in device level. >