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 389E4A0032; Tue, 13 Sep 2022 17:08:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1C984021D; Tue, 13 Sep 2022 17:08:33 +0200 (CEST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by mails.dpdk.org (Postfix) with ESMTP id ADAF240151 for ; Tue, 13 Sep 2022 17:08:31 +0200 (CEST) Received: by mail-yb1-f178.google.com with SMTP id t184so18256416yba.4 for ; Tue, 13 Sep 2022 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=YrUENqZDcC4Z+wDYS6+AvVFPfR3c9ASF21yx+oPWTMc=; b=BTdA86wU2rbKQNMjRVH8sktBi31+AMMcfqkzDv22QRFqi57mCADcNeRIAXLH+ORo5t l01MWK4IjYSyrhTR0D7s+Jf+Nm19B+dTXrCHhWFdSWoKvIxB4pVJHMCO2NS0kWuJlZ1h z9eNT2SMn1XiEAhXK3ga3OZ/+x366JTbEhg46vmYGfWJnMbIq57jFYeMR9TglMUa+kiD Bh8DkioOh3KhVrL7vnrjQBFEvDME8DdvYcbeS4fD7eVlzoMzXylmq9JfTkrqF9BYKjh2 bh2CgMM1PxagwnaAmHMAaVqAUVRIIR6VITfCHC9j0IR1yokFuAHUwk7FuohBkVtY3vhk Hf9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=YrUENqZDcC4Z+wDYS6+AvVFPfR3c9ASF21yx+oPWTMc=; b=mpVSdzdDCaBBBQSuHTPqUGpwGrc13JgQGzWHgZSVGNa3UqZXg3obTOU/0Bcfz/smj4 OWa1nFcQU4VvOHufR/ZXzsRAn6U5sHRdTyyaRLO8qOOHJB/LwN+GJBpAsq1hlJX8cb3E pvTzprNxt8NTlqkQUZQJKUEGLWsFcvh28x+QV0WONLK+CHEHtsVJDO7JbwwTUjzZSArK dkSQO2RvM0d97H+muIrG+QDPpljhylflnfhCWs1L6F3nF7joJYDhT0r1h9f1E3sEH0Xh 1Z3acek12SYEe1glxDK5oRkkM6KlEz+tyx8pOgDhwGdtr/F4jJmCYeQNIGDIcrDku4Bx DNFA== X-Gm-Message-State: ACgBeo0EGkOyit1H3kjAV6yKI9s5gPKsUjmnsLo3E/MqagZ2dUK9Wl+a J5Hpvy55hpAtnZBtElqhXyXCIqXjBK9lNuoyuNM= X-Google-Smtp-Source: AA6agR5P6loPGU1x00+c7kUU97zYXknjXoKN1UM+8VqrSPkixPWbMxzuVuFsAIeaFul666Y6ILVBR2r0u00/WBS65UY= X-Received: by 2002:a25:2650:0:b0:6a8:fc69:417d with SMTP id m77-20020a252650000000b006a8fc69417dmr26978512ybm.492.1663081711002; Tue, 13 Sep 2022 08:08:31 -0700 (PDT) MIME-Version: 1.0 References: <1619171202-28486-2-git-send-email-tangchengchang@huawei.com> <20220725040842.35027-1-fengchengwen@huawei.com> <20220725040842.35027-2-fengchengwen@huawei.com> <495fb2f0-60c2-f1c9-2985-0d08bb463ad0@xilinx.com> In-Reply-To: <495fb2f0-60c2-f1c9-2985-0d08bb463ad0@xilinx.com> From: Chas Williams <3chas3@gmail.com> Date: Tue, 13 Sep 2022 11:08:19 -0400 Message-ID: Subject: Re: [PATCH v2 1/3] net/bonding: support Tx prepare To: Ferruh Yigit , Chengwen Feng , thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, konstantin.ananyev@intel.com Cc: dev@dpdk.org, chas3@att.com, humin29@huawei.com Content-Type: text/plain; charset="UTF-8" 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 9/13/22 06:22, Ferruh Yigit wrote: > On 7/25/2022 5:08 AM, Chengwen Feng wrote: > > > I assume intention is to make this as transparent as possible to the > user, that is why you are using a wrapper that combines > `rte_eth_tx_prepare()` & `rte_eth_tx_burst()` APIs. But for other PMDs > `rte_eth_tx_burst()` is called explicitly by the application. > > Path is also adding two new bonding specific APIs to enable/disable Tx > prepare. > Instead if you leave calling `rte_eth_tx_prepare()` decision to user, > there will be no need for the enable/disable Tx prepare APIs and the > wrapper. > > The `tx_pkt_prepare()` implementation in bonding can do the mode check, > call Tx prepare for all slaves and apply failure recovery, as done in > this wrapper function, what do you think, will it work? > If you leave calling tx_prepare to the user, you need to perform a hash calculation to determine an output device. Since the output devices might be different types, you really need to know which device's tx_prepare needs to be called. You potentially will calculate the packet hash twice. While you could be clever with storing the hash in the mbuf somewhere, that's likely more complicated.