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 12DA1A0544; Mon, 10 Oct 2022 21:42:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AA12640143; Mon, 10 Oct 2022 21:42:34 +0200 (CEST) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by mails.dpdk.org (Postfix) with ESMTP id 960EA40041 for ; Mon, 10 Oct 2022 21:42:33 +0200 (CEST) Received: by mail-qt1-f170.google.com with SMTP id cj27so7078602qtb.7 for ; Mon, 10 Oct 2022 12:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DZdsOt83JQoelBd7wnh9ummnQ+VrIdsFvbbPpugUw/o=; b=POJX6Wq+Wm13kTOepWkqYQ1TNIMkSNoY3KOQHoo8crpRdBW8hz83w8gwl7JYpvrbzC zKBQmUG5IJU33Ad4afGCKUCu7BNCGV2uZNR86F3F8JvI+GnHE/NIBTumzPCbYi+Zijv0 Bl3QTckNFbnwodQmZCG+VIlL274y2pl7uqc/Rn9EBhkZ7OQYRLlAHLxIAgxppn8lbz+c KVWPZ+einwc0TXeI1tRLtHIP/hDIvokUsJr/9SnRB+0Aei8Zm4E0DmY5TQYpE+6uMykE tI4j8LUU/bW5ZbbI37U/S8bpyAJG5lYse9uXTD255/D86eoNLymF4makjt3YSM2N4OWK EycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DZdsOt83JQoelBd7wnh9ummnQ+VrIdsFvbbPpugUw/o=; b=VbKlTru4B9CuAz5eM6rbl7iogAltoe3/OElT0DDP15Zt+zLlKFiXlzAZth91ECaX2D byIU56uR6KDiM+p/Soad6aaZwOIVHg3l5lHaUcJNVYzMdWhcKm+w4CS+wqkD6c6RbRMy tKxKtvhe0kvjOt5HUzdACu4V0dD6H3ZT5K12ut29qPwxE2f7F7KaC6x/OyXkw7ebRVXr LnMfex0wtPUbJjop87TB2V2kfr9veaqnZ0xA8WzaijDV/Lkyh7MDR5yG/MhMcVwOp+VJ 5VGmEbZCDMBHHZEx9bgR1AB3ybZ25s5ZXP+6uRau2w/Ngd5hryhs8NJs5R1X0487kCpX j2hA== X-Gm-Message-State: ACrzQf39p9E3Ll6A3MC8sFGAlJzuQ8ALiwKGFnd1XgehJGV13oOhkLfl YhrgF7jWVTuNwb7bMzQKCdQhSZbfsMI= X-Google-Smtp-Source: AMsMyM4q6GVTAexBa76CkCFhbc6V6P48R5QLktsajPy9MKelzSJ7RIaoMPsPW7cQqzfxGM/kvN4n6g== X-Received: by 2002:a05:622a:513:b0:396:378a:f0e4 with SMTP id l19-20020a05622a051300b00396378af0e4mr13984034qtx.515.1665430952951; Mon, 10 Oct 2022 12:42:32 -0700 (PDT) Received: from ?IPV6:2600:4040:225b:ea00:6063:8c9b:774a:6cf4? ([2600:4040:225b:ea00:6063:8c9b:774a:6cf4]) by smtp.googlemail.com with ESMTPSA id dt39-20020a05620a47a700b006ec59941acasm5189144qkb.11.2022.10.10.12.42.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 12:42:32 -0700 (PDT) Message-ID: Date: Mon, 10 Oct 2022 15:42:31 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v4] net/bonding: call Tx prepare before Tx burst Content-Language: en-US To: Chengwen Feng , thomas@monjalon.net, ferruh.yigit@xilinx.com Cc: dev@dpdk.org, chas3@att.com, humin29@huawei.com, andrew.rybchenko@oktetlabs.ru, konstantin.ananyev@huawei.com References: <1619171202-28486-2-git-send-email-tangchengchang@huawei.com> <20221009033639.38232-1-fengchengwen@huawei.com> From: Chas Williams <3chas3@gmail.com> In-Reply-To: <20221009033639.38232-1-fengchengwen@huawei.com> 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 10/8/22 23:36, Chengwen Feng wrote: > uint16_t slaves[RTE_MAX_ETHPORTS]; > uint8_t tx_failed_flag = 0; > uint16_t num_of_slaves; > + uint16_t num_tx_prep; > > uint16_t max_nb_of_tx_pkts = 0; > > @@ -1320,12 +1339,18 @@ bond_ethdev_tx_burst_broadcast(void *queue, struct rte_mbuf **bufs, > for (i = 0; i < nb_pkts; i++) > rte_pktmbuf_refcnt_update(bufs[i], num_of_slaves - 1); > > + /* It is rare that bond different PMDs together, so just call tx-prepare once */ > + num_tx_prep = rte_eth_tx_prepare(slaves[0], bd_tx_q->queue_id, > + bufs, nb_pkts); You probably want to do this before you update the refcnt on the mbufs. Otherwise, the common rte_eth_tx_prepare operation, rte_vlan_insert, will fail since the refcnt will not be 1. > + if (unlikely(num_tx_prep < nb_pkts)) > + tx_failed_flag = 1; > + > /* Transmit burst on each active slave */ > for (i = 0; i < num_of_slaves; i++) { > slave_tx_total[i] = rte_eth_tx_burst(slaves[i], bd_tx_q->queue_id, > - bufs, nb_pkts); > + bufs, num_tx_prep); > > - if (unlikely(slave_tx_total[i] < nb_pkts)) > + if (unlikely(slave_tx_total[i] < num_tx_prep)) > tx_failed_flag = 1; > > /* record the value and slave index for the slave which transmits the > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index e8d1e1c658..b0396bb86e 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -6031,6 +6031,10 @@ uint16_t rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id, > * @see rte_eth_tx_prepare to perform some prior checks or adjustments > * for offloads. > * > + * @note This function must not modify mbufs (including packets data) unless > + * the refcnt is 1. The exception is the bonding PMD, which does not have > + * tx-prepare function, in this case, mbufs maybe modified. Exactly. See my comment about calling prepare before you modify the refcnt. > + * > * @param port_id > * The port identifier of the Ethernet device. > * @param queue_id