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 236CAA0545; Mon, 20 Jun 2022 12:55:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF79040151; Mon, 20 Jun 2022 12:55:15 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2081.outbound.protection.outlook.com [40.107.236.81]) by mails.dpdk.org (Postfix) with ESMTP id D03D140150 for ; Mon, 20 Jun 2022 12:55:13 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FIk937sbiK8AdkARZOUleCAr5+CcJ29sTnSsqOB0/IkOUoRRQp/YurCz4DpTOEHkn409yeKkJ44spbmDLiJ5mkY5JBSt1+pzZR0bIxHKsap9iW2l7660jIjf+YgN9jrQwfBmmRNJuRFtaE6M8Jf9T4iTbAlfb2Zn1S03SJn4Ss6AuEjkHeEKvTIn7KsCSbhPLHGzwl2HzzfAGwlnuzcI+1il5ueXbwf9DeNwPo/dp7N6qFzrxDFmYczsiBJIycyRecCkTpbe2RU5QRvd7w9OnLeJmnQw1SVjAZ/7sY4LWvmn42VxnE4K3Q/SIxwTo2YJNVKT/F5sUXyWerTn0SEaKQ== 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=BxxQ2nvU7QGmI7r/cDBQyzend8SIU5UFmsJeBLGrG+o=; b=beC7DJiPJUs/Dw/UAdUMjxL+b8rt9jJVeLcHRHMUFumEqZ0XB4NVAKlbtIxWbTM8mnW7/UmUwr6Zrdy+Z5wVFBASGm40NQFC6zISAcMGTVJhUFFpJjmgbvW0kRMMO4hjH/xaPkk41/PMBemomktnXfxG45T2Opw8Rx1NytTQ/4jr/obU4MqRdUWolUlmsyaQyfSMKXjuvIdGzGn4NDMw/zJLEDnSPWDj6qLUuRL+xNwN20rt1XVBpe8GxerGkZmjVjGy/pBtKa/Da9ZvBcAGlIYgFxQoZf43zuKu/DZ6vEhtpoyRwSuqWvzMCLay/d/u/z7q038enrPrCBb18IuaBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=broadcom.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=BxxQ2nvU7QGmI7r/cDBQyzend8SIU5UFmsJeBLGrG+o=; b=QHjg4yGl+v3pwDjdGoy7ZOBGa4HG0fL+9XU23/SAUDDaXL2zOkUHjr14Iq9q8aP/7sk5/JBfqcJp8j6n9jh4ZmuVrslGg54hcVIA14ozdpFlqqgLYjAdRt81iEAKKKgpxvzul2ysR5RodnIb5k5+HDTnlPDfnmAYv9ZFFac6vn8= Received: from SA1P222CA0074.NAMP222.PROD.OUTLOOK.COM (2603:10b6:806:2c1::20) by DM6PR02MB4138.namprd02.prod.outlook.com (2603:10b6:5:a3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.15; Mon, 20 Jun 2022 10:55:10 +0000 Received: from SN1NAM02FT0038.eop-nam02.prod.protection.outlook.com (2603:10b6:806:2c1:cafe::f9) by SA1P222CA0074.outlook.office365.com (2603:10b6:806:2c1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14 via Frontend Transport; Mon, 20 Jun 2022 10:55:10 +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 SN1NAM02FT0038.mail.protection.outlook.com (10.97.5.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5353.14 via Frontend Transport; Mon, 20 Jun 2022 10:55:10 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) 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.2176.14; Mon, 20 Jun 2022 11:55:08 +0100 Received: from smtp.xilinx.com (172.21.105.198) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Mon, 20 Jun 2022 11:55:08 +0100 Envelope-to: ajit.khaparde@broadcom.com, kalesh-anakkur.purayil@broadcom.com, dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, thomas@monjalon.net Received: from [10.71.119.54] (port=62975) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1o3F3k-0006Vz-Hc; Mon, 20 Jun 2022 11:55:08 +0100 Message-ID: Date: Mon, 20 Jun 2022 11:55:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [dpdk-dev] [PATCH 1/8] net/bnxt: remove assert for zero data len in Tx path Content-Language: en-US To: Ajit Khaparde CC: Kalesh A P , dpdk-dev , Andrew Rybchenko , Thomas Monjalon References: <20220615145703.6613-1-kalesh-anakkur.purayil@broadcom.com> <20220615145703.6613-2-kalesh-anakkur.purayil@broadcom.com> <9bb5c847-cde8-ff20-8468-3c69e7b2af3b@xilinx.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 97a6b92d-f7d8-4894-9eec-08da52ab5888 X-MS-TrafficTypeDiagnostic: DM6PR02MB4138:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OA5l1pHFDmrR3usIxDyfdvwdIzZWY/dNtvYZgrV0FlvY5rHyD07N4sN1l8PYMWeglqh6hEHTh/oEumpBLrvfbPL9VXCftyl59gnIQSYyiuk/Pjsvz7IpmFIkrKCBjY8/tGvo4riWCYrhgJFULIHIIYUjtmjBxqkGFkkECirBFb+RH9D5iyfdK62wcuXVGxCiARfsLPEFqdEt1Cz8DXRlNHgn/u6eIUwmrMH4lrsQwvEiFIOcuHi5iiyo+ngzkqHl45W1gbe33s6m4m4vx3GVPNsI4liUnbuTtzH2JGy26hLI6LRRjyNCQnf/5dBTr+c/oBF++/N/XEcX5JkzCSdbpQATSjZahCNS1q1PBatf05ZBXojuBHpPJmTx2csT4vxfvdWXe7Kb5Al/YtgkXwq5dgAJ52WEltpeCbfG2QYBrzGuqQfH4g7dw9FydelsXF8RuMiPFqLGj3DARpTK3gJ0jlEy4oAaS9JOmS10UCWdEkAgFM/AwmmNMT+R5KCTMuQ9hwFc13OtqJTP5SR5yqb1EU+IsFTXopCdB+DhMjF6wh7EcwnyS2+t1h7inKKym/ZK3+ip3mApdTm1VYJzro5upi3ffj6TuKBRHdZtfIPEK5Lh1L8lfhNXKcKOls4PlNG8pVSnTfC527Y98+FAzAW8YPrzJOxDLnROVAdA7df9CkCJGsSKe+qSffPbUp17ihUhr8gmEf9Vj0NFgEtdkBpX5T0fNyuOXfgQsqF9pwqm6BGm+hr4Ud7GF0kMF4gnHM9MmdtJRH9lyHiLg+95zdXRvg== 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:(13230016)(4636009)(376002)(346002)(39860400002)(136003)(396003)(46966006)(40470700004)(36840700001)(316002)(44832011)(2906002)(6916009)(478600001)(26005)(53546011)(54906003)(8936002)(5660300002)(8676002)(36756003)(31686004)(31696002)(9786002)(41300700001)(2616005)(70586007)(70206006)(4326008)(7636003)(82310400005)(40460700003)(82740400003)(186003)(336012)(426003)(47076005)(40480700001)(36860700001)(356005)(83380400001)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2022 10:55:10.1768 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 97a6b92d-f7d8-4894-9eec-08da52ab5888 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: SN1NAM02FT0038.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB4138 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 6/20/2022 12:09 AM, Ajit Khaparde wrote: > On Thu, Jun 16, 2022 at 10:03 AM Ferruh Yigit wrote: >> >> On 6/15/2022 3:56 PM, Kalesh A P wrote: >>> >>> From: Somnath Kotur >>> >>> Currently the PMD tries to detect a potential 0 byte DMA by >>> using RTE_VERIFY. >>> But since RTE_VERIFY internally calls rte_panic() it is fatal to >>> the application and some applications want to avoid that. >>> So return an error from the bnxt xmit handler if such a bad pkt is >>> encountered by logging an error message, dumping the pkt header and >>> dump the current stack as well >>> >>> Signed-off-by: Somnath Kotur >>> Reviewed-by: Ajit Khaparde >>> --- >>> drivers/net/bnxt/bnxt_txr.c | 29 ++++++++++++++++++++++++++--- >>> 1 file changed, 26 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c >>> index 7a7196a..67e0167 100644 >>> --- a/drivers/net/bnxt/bnxt_txr.c >>> +++ b/drivers/net/bnxt/bnxt_txr.c >>> @@ -123,6 +123,26 @@ bnxt_xmit_need_long_bd(struct rte_mbuf *tx_pkt, struct bnxt_tx_queue *txq) >>> return false; >>> } >>> >>> +static bool >>> +bnxt_zero_data_len_tso_segsz(struct rte_mbuf *tx_pkt, uint8_t data_len_chk) >>> +{ >>> + const char *type_str = "Data len"; >>> + uint16_t len_to_check = tx_pkt->data_len; >>> + >>> + if (data_len_chk == 0) { >>> + type_str = "TSO Seg size"; >>> + len_to_check = tx_pkt->tso_segsz; >>> + } >>> + >>> + if (len_to_check == 0) { >>> + PMD_DRV_LOG(ERR, "Error! Tx pkt %s == 0\n", type_str); >>> + rte_pktmbuf_dump(stdout, tx_pkt, 64); >>> + rte_dump_stack(); >>> + return true; >>> + } >>> + return false; >>> +} >>> + >>> static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt, >>> struct bnxt_tx_queue *txq, >>> uint16_t *coal_pkts, >>> @@ -179,7 +199,8 @@ static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt, >>> } >>> >>> /* Check non zero data_len */ >>> - RTE_VERIFY(tx_pkt->data_len); >>> + if (unlikely(bnxt_zero_data_len_tso_segsz(tx_pkt, 1))) >>> + return -EIO; >>> >> >> Some PMDs does the similar verification in the 'rte_eth_tx_prepare()' >> API (tx_pkt_prepare() dev_ops), this helps to separate the checks and Tx >> data path code, do you want to do the same? > > > When we originally added these checks, we were not sure how prevalent > is the usage of tx_pkt_prepare() dev_op by various applications. > > We will stick with this patch for now and implement that > rte_eth_tx_prepare() in the next release? > 'rte_eth_tx_prepare()' is not mandatory, so yes there may be applications that are not calling this API. If we have a consensus to have checks in the prepare function, I think it helps both to PMDs and applications.