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 F317AA0032; Tue, 13 Sep 2022 12:23:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D31DE40156; Tue, 13 Sep 2022 12:23:02 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2049.outbound.protection.outlook.com [40.107.243.49]) by mails.dpdk.org (Postfix) with ESMTP id 286C840151 for ; Tue, 13 Sep 2022 12:23:01 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kjCuVj6JJATmzFlDqR42Gr98PUao9b+AcemP1jOxCBPawM8Nmn4CntCDFlGangI/myRheckt+NEa//ea9GVUO+tYBfr9xZVb6DFeMCKPTHrDpiJ81Kc4pYgpZUvxhJi9EzmhR+/SplB02z0v9t5EkjFparE2U3tC2mjzy3m1Q0o9O7wMhsML+cM+c0SLVOUFbOSrA7QsV/npA4uvrjFHP0kiN2ZzhqYWNjgu3UO8DICSx7ajYF4zgUV1boUq7C5Kl85pMiUc0Pg4UKsejLCgLrYJtdzR7iU8sYh2pvJmg4TpqMzA9YehLApB6gNmkDtjrYVSSCtfrcR5OukJitAb1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Xp7sgJU7g/d0GaDm+Xp3MSp3J5rrkFEwHCN9gBgziAY=; b=KR4LCoN6lc4uk75kn9d02hGpmJNDAbwwxAM7abqYC1oGj04j6G2L7n1V6hdI1j1FqVO4kGbXewktFLF3zc9XgC94GRyLZwOPitT9Ee0fGl41hS1m1RP8W4Djcquq8j/uqGJBOHb4sfHaX/eI6fl3yJtI1qTOHxn65igPVHUYWflWMcHptn6NU/aZnxKTSwjtxgVJbunLO+n7cN/nFPIZmq/lUURgIN65hLzun/wXglUqSRfcsYTrl0KhNtM14uATZa0A8YNSOE/oEP5D0uDG3AB1WaT0I607jx8IKph1QcuRyu0XELdLFPosnVUh32w4/aHP0HyayW2k2TPXFyeaAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=huawei.com smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xp7sgJU7g/d0GaDm+Xp3MSp3J5rrkFEwHCN9gBgziAY=; b=IypNY8sF1hFKYjbitJ86HXcFZc6EKn82Uy+JcYXQfxPSTS/88KBIYdln7tu+CyGYDdw6bxqtYAm9hKCqnROqAZlvYY3Q+k27JFRJwL6IJ7qvQTgYnliyIuIpcwD91Or3a3RyG209j9FCziCrJPxFy9sn52Je95ORKUOHh67RkVQ= Received: from BN9PR03CA0137.namprd03.prod.outlook.com (2603:10b6:408:fe::22) by CH2PR02MB6790.namprd02.prod.outlook.com (2603:10b6:610:7d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.14; Tue, 13 Sep 2022 10:22:58 +0000 Received: from BN1NAM02FT033.eop-nam02.prod.protection.outlook.com (2603:10b6:408:fe:cafe::fe) by BN9PR03CA0137.outlook.office365.com (2603:10b6:408:fe::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.12 via Frontend Transport; Tue, 13 Sep 2022 10:22:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.80.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.80.198; helo=xir-pvapexch01.xlnx.xilinx.com; pr=C Received: from xir-pvapexch01.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT033.mail.protection.outlook.com (10.13.3.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5612.13 via Frontend Transport; Tue, 13 Sep 2022 10:22:58 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 13 Sep 2022 11:22:57 +0100 Received: from smtp.xilinx.com (172.21.105.198) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2375.24 via Frontend Transport; Tue, 13 Sep 2022 11:22:57 +0100 Envelope-to: fengchengwen@huawei.com, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, konstantin.ananyev@intel.com, dev@dpdk.org, chas3@att.com, humin29@huawei.com Received: from [10.71.194.74] (port=62625) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1oY34D-0003K1-5T; Tue, 13 Sep 2022 11:22:57 +0100 Message-ID: <495fb2f0-60c2-f1c9-2985-0d08bb463ad0@xilinx.com> Date: Tue, 13 Sep 2022 11:22:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH v2 1/3] net/bonding: support Tx prepare Content-Language: en-US To: Chengwen Feng , , , CC: , , References: <1619171202-28486-2-git-send-email-tangchengchang@huawei.com> <20220725040842.35027-1-fengchengwen@huawei.com> <20220725040842.35027-2-fengchengwen@huawei.com> From: Ferruh Yigit In-Reply-To: <20220725040842.35027-2-fengchengwen@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1NAM02FT033:EE_|CH2PR02MB6790:EE_ X-MS-Office365-Filtering-Correlation-Id: de3768a6-ae85-47fa-975a-08da9571edfb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ijmwg8YgMMeSQjUXdigqpiVzVfcF1HsFgPdSvPkxZNAUDkl5LiIc2bRyLpsBkqIGxeCE6sAWGcVJ2R+g9/7RkQzzUTQtUovnVexuUlaqBOthrZWF2q7uJ+UT9Gj2xtqsxJcaN6v0+n68Zp+2o21MA1jt2sCZtqmrW8TwAso+eVYDWJQScShhRGso7J0QVDzyupOD6w6SFR8rxmhr0OpjAl9C62IeXa3yvnxoi1fnjEGMwT2gLD3sbHO35UhgYfBISf0f5bf9MxLvhnMO2PYwm7SBxTav07m2+3EhoQn16R/x+Q+kon4b8BUAavjNNCNlhTr5Pvlh/Omb6sDzlvAyKu3l/kN6/OvPltmOuJ0dgxW/eefybIMynwuFNl5vMY/QwMGcnvUL7jYUZGTBwfoNQgAMmUTux7r3TuHoxy/p/wACGNLNg+sw/4gf97ToXkB/KWyinmcwYvZTdgSYNWq4ReiMDK1rE1zdUzrEU//hLtVoY8CXzhE0TMxzns2rrfM2enTyjII6UKTp2sdOiuRikBRIHd5ahg8fev7reWkoLgegvPumiiR0R5g5Rfvc0W+P7qhU8RPqFPZIv0D9Ddougdq3MW9FYp1P18r5it3INnmaXtNBSvIFsrxP7qUVTuyHEWP2u7Q1QyHFmlOoor5vAOoG4vYR8PR+LNvci6vtoJNjHmUJEf3dzAmgWmahskJz8GrtZeHmjZfSYGUSQXyhgmdvfkrxMR4iu6zB3Ah3/0esB+GN51qk3AP1ceVeTnU9VaDjs9QK+UcHUs2fZVJSCcpJir/13D/1pgYBLv1KX6kRS7R3w3t4YeFDmRhFBZBG1LWErFTYXRCOiAgZ246JWg== X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch01.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230022)(4636009)(376002)(136003)(396003)(39860400002)(346002)(451199015)(40470700004)(36840700001)(46966006)(44832011)(36860700001)(31686004)(36756003)(40460700003)(478600001)(70206006)(70586007)(8676002)(4326008)(53546011)(41300700001)(31696002)(9786002)(356005)(8936002)(82310400005)(5660300002)(7636003)(186003)(336012)(82740400003)(54906003)(40480700001)(26005)(2616005)(110136005)(316002)(83380400001)(2906002)(47076005)(426003)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2022 10:22:58.1159 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de3768a6-ae85-47fa-975a-08da9571edfb X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch01.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR02MB6790 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 7/25/2022 5:08 AM, Chengwen Feng wrote: > > Normally, to use the HW offloads capability (e.g. checksum and TSO) in > the Tx direction, the application needs to call rte_eth_dev_prepare to > do some adjustment with the packets before sending them (e.g. processing > pseudo headers when Tx checksum offload enabled). But, the tx_prepare > callback of the bonding driver is not implemented. Therefore, the > sent packets may have errors (e.g. checksum errors). > > However, it is difficult to design the tx_prepare callback for bonding > driver. Because when a bonded device sends packets, the bonded device > allocates the packets to different slave devices based on the real-time > link status and bonding mode. That is, it is very difficult for the > bonded device to determine which slave device's prepare function should > be invoked. > > So, in this patch, the tx_prepare callback of bonding driver is not > implemented. Instead, the rte_eth_dev_tx_prepare() will be called for > all the fast path packets in mode 0, 1, 2, 4, 5, 6 (mode 3 is not > included, see[1]). In this way, all tx_offloads can be processed > correctly for all NIC devices in these modes. > > As previously discussed (see V1), if the tx_prepare fails, the bonding > driver will free the cossesponding packets internally, and only the > packets of the tx_prepare OK are xmit. > Please provide link to discussion you refer to. > To minimize performance impact, this patch adds one new > 'tx_prepare_enabled' field, and corresponding control and get API: > rte_eth_bond_tx_prepare_set() and rte_eth_bond_tx_prepare_get(). > > [1]: In bond mode 3 (broadcast), a packet needs to be sent by all slave > ports. Different slave PMDs process the packets differently in > tx_prepare. If call tx_prepare before each slave port sending, the sent > packet may be incorrect. > > Signed-off-by: Chengchang Tang > Signed-off-by: Chengwen Feng <...> > +static inline uint16_t > +bond_ethdev_tx_wrap(struct bond_tx_queue *bd_tx_q, uint16_t slave_port_id, > + struct rte_mbuf **tx_pkts, uint16_t nb_pkts) > +{ > + struct bond_dev_private *internals = bd_tx_q->dev_private; > + uint16_t queue_id = bd_tx_q->queue_id; > + struct rte_mbuf *fail_pkts[nb_pkts]; > + uint8_t fail_mark[nb_pkts]; > + uint16_t nb_pre, index; > + uint16_t fail_cnt = 0; > + int i; > + > + if (!internals->tx_prepare_enabled) > + goto tx_burst; > + > + nb_pre = rte_eth_tx_prepare(slave_port_id, queue_id, tx_pkts, nb_pkts); > + if (nb_pre == nb_pkts) > + goto tx_burst; > + > + fail_pkts[fail_cnt++] = tx_pkts[nb_pre]; > + memset(fail_mark, 0, sizeof(fail_mark)); > + fail_mark[nb_pre] = 1; > + for (i = nb_pre + 1; i < nb_pkts; /* update in inner loop */) { > + nb_pre = rte_eth_tx_prepare(slave_port_id, queue_id, > + tx_pkts + i, nb_pkts - i); 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?