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 410CDA034F; Tue, 8 Jun 2021 11:49:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9998410EF; Tue, 8 Jun 2021 11:49:45 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id C181B410ED for ; Tue, 8 Jun 2021 11:49:44 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 654A87F670; Tue, 8 Jun 2021 12:49:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 654A87F670 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623145784; bh=UTZtcIPdv2Q5DUzCswuJ2FWnVdG1jUUAGPUVq8B5nWM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=uoMjLLtiPMzgFjT81KSP5j4wrAa2UCTR4ej4mmycJwISpYbvJAW0ThTSSftA8FnXt orxXBrKh6i9lkPP75UJUFCZPx7Ef3hi+ZRgTiirdzXEYF46nlxGnNwpjALyiwkdJnM BP0A5p/cDzgYlt7T1M6O37MdD2cNibYsT6vAqTcI= To: Chengchang Tang , dev@dpdk.org Cc: linuxarm@huawei.com, chas3@att.com, humin29@huawei.com, ferruh.yigit@intel.com, konstantin.ananyev@intel.com References: <1618571071-5927-1-git-send-email-tangchengchang@huawei.com> <1619171202-28486-1-git-send-email-tangchengchang@huawei.com> <1619171202-28486-3-git-send-email-tangchengchang@huawei.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Tue, 8 Jun 2021 12:49:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1619171202-28486-3-git-send-email-tangchengchang@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] net/bonding: support configuring Tx offloading for bonding 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 Sender: "dev" "for bonding" is redundant in the summary since it is already "net/bonding" On 4/23/21 12:46 PM, Chengchang Tang wrote: > Currently, the TX offloading of the bonding device will not take effect by TX -> Tx > using dev_configure. Because the related configuration will not be > delivered to the slave devices in this way. I think it is a major problem that Tx offloads are actually ignored. It should be a patches with "Fixes:" which addresses it. > The Tx offloading capability of the bonding device is the intersection of > the capability of all slave devices. Based on this, the following functions > are added to the bonding driver: > 1. If a Tx offloading is within the capability of the bonding device (i.e. > all the slave devices support this Tx offloading), the enabling status of > the offloading of all slave devices depends on the configuration of the > bonding device. > > 2. For the Tx offloading that is not within the Tx offloading capability > of the bonding device, the enabling status of the offloading on the slave > devices is irrelevant to the bonding device configuration. And it depends > on the original configuration of the slave devices. > > Signed-off-by: Chengchang Tang > --- > drivers/net/bonding/rte_eth_bond_pmd.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c > index 84af348..9922657 100644 > --- a/drivers/net/bonding/rte_eth_bond_pmd.c > +++ b/drivers/net/bonding/rte_eth_bond_pmd.c > @@ -1712,6 +1712,8 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev, > struct rte_flow_error flow_error; > > struct bond_dev_private *internals = bonded_eth_dev->data->dev_private; > + uint64_t tx_offload_cap = internals->tx_offload_capa; > + uint64_t tx_offload; > > /* Stop slave */ > errval = rte_eth_dev_stop(slave_eth_dev->data->port_id); > @@ -1759,6 +1761,17 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev, > slave_eth_dev->data->dev_conf.rxmode.offloads &= > ~DEV_RX_OFFLOAD_JUMBO_FRAME; > > + while (tx_offload_cap != 0) { > + tx_offload = 1ULL << __builtin_ctzll(tx_offload_cap); > + if (bonded_eth_dev->data->dev_conf.txmode.offloads & tx_offload) > + slave_eth_dev->data->dev_conf.txmode.offloads |= > + tx_offload; > + else > + slave_eth_dev->data->dev_conf.txmode.offloads &= > + ~tx_offload; > + tx_offload_cap &= ~tx_offload; > + } > + Frankly speaking I don't understand why it is that complicated. ethdev rejects of unsupported Tx offloads. So, can't we simply: slave_eth_dev->data->dev_conf.txmode.offloads = bonded_eth_dev->data->dev_conf.txmode.offloads;