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 48476A0A0B for ; Mon, 25 Jan 2021 20:41:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3DFF91411AC; Mon, 25 Jan 2021 20:41:48 +0100 (CET) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by mails.dpdk.org (Postfix) with ESMTP id ADB9314116E for ; Mon, 25 Jan 2021 20:41:43 +0100 (CET) Received: by mail-ot1-f52.google.com with SMTP id 63so13952190oty.0 for ; Mon, 25 Jan 2021 11:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q/ep8rckgxr3/ajvmz+g9bo9mm7+aYqdcUs9V/Yb7uY=; b=Ox4kW4KKutEnQngZsgifmAp03Cpy/OEIr1h+BVmFgeQ8FSIK8TmQEECH2ynWBEHiX7 /3BgbXvQYKA+GpkR33VbkHBoU88MOp0zZsBVokghK1gs75leMwGid6RUUjyVBfcjrz40 ukyclNlfEy8l+5hGlFzc9nTVAtKjmVwJzwaiM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q/ep8rckgxr3/ajvmz+g9bo9mm7+aYqdcUs9V/Yb7uY=; b=hWSo0VrjGD9W98S7yvc1lFhwzrYZAsh1DE72EYhhjUZMNMlEx5zEZ71G+Hy56lW5ZK UePo3C40ZAi8dyf6RrkcDvXtE+uI4NXbCEDxD/ME+O3ftMFwpJRPsBTudyDCIzgRfBu9 wGSqqH2+k2Xojd+s0Eo7fzSYtnRH3uhoz3ExVLDw+TYHh7RJyEr1LMJc9THGLfLRDZzF ciFRjH/t6wkO1LyAWx1POC3aAUK49b9MkFYvl0hJzeO9UsTKfqTd2Sb9Inn90i8SVDzD XJuBw6smJ5kNjOaru3odnET11ikMynhx3jejSEWCDbYaJ9jdFalHJwOZtzlTOECRWDsA 2lAA== X-Gm-Message-State: AOAM530cNzRMaAOmNHpvz4MXv3LfVGH8RMirmAK31dDTBPAWg1u6gur6 olXDKnSk4D0BJzQk+yIJdHZtNgCDMswhZ3n8js5dAg== X-Google-Smtp-Source: ABdhPJyvMgQwrrhT98lBcH3QYD/zvnxTElVOted4oBe3gVFlvaFBRK+M9Aov2IYNinoxY7d4k1kFq4uNbKioXFZS4yU= X-Received: by 2002:a9d:2035:: with SMTP id n50mr1480300ota.44.1611603702764; Mon, 25 Jan 2021 11:41:42 -0800 (PST) MIME-Version: 1.0 References: <20210125083202.38267-1-stevex.yang@intel.com> <20210125181548.2713326-1-ferruh.yigit@intel.com> In-Reply-To: <20210125181548.2713326-1-ferruh.yigit@intel.com> From: Lance Richardson Date: Mon, 25 Jan 2021 14:41:31 -0500 Message-ID: To: Ferruh Yigit Cc: Wenzhuo Lu , Xiaoyun Li , Bernard Iremonger , Steve Yang , dev@dpdk.org, stable@dpdk.org, oulijun@huawei.com, wisamm@mellanox.com, lihuisong@huawei.com Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003da83405b9beba5f" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-stable] [PATCH v5] app/testpmd: fix setting maximum packet length X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" --0000000000003da83405b9beba5f Content-Type: text/plain; charset="UTF-8" On Mon, Jan 25, 2021 at 1:15 PM Ferruh Yigit wrote: > > From: Steve Yang > > "port config all max-pkt-len" command fails because it doesn't set the > 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag properly. > > Commit in the fixes line moved the 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload > flag update from 'cmd_config_max_pkt_len_parsed()' to 'init_config()'. > 'init_config()' function is only called during testpmd startup, but the > flag status needs to be calculated whenever 'max_rx_pkt_len' changes. > > The issue can be reproduce as [1], where the 'max-pkt-len' reduced and > 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag should be cleared but it > didn't. > > Adding the 'update_jumbo_frame_offload()' helper function to update > 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag and 'max_rx_pkt_len'. This > function is called both by 'init_config()' and > 'cmd_config_max_pkt_len_parsed()'. > > Default 'max-pkt-len' value set to zero, 'update_jumbo_frame_offload()' > updates it to "RTE_ETHER_MTU + PMD specific Ethernet overhead" when it > is zero. > If '--max-pkt-len=N' argument provided, it will be used instead. > And with each "port config all max-pkt-len" command, the > 'DEV_RX_OFFLOAD_JUMBO_FRAME' offload flag, 'max-pkt-len' and MTU is > updated. > > [1] > +/* > + * Helper function to arrange max_rx_pktlen value and JUMBO_FRAME offload, > + * MTU is also aligned if JUMBO_FRAME offload is not set. > + * > + * port->dev_info should be get before calling this function. Should this be "port->dev_info should be set ..." instead? > + if (rx_offloads != port->dev_conf.rxmode.offloads) { > + uint16_t qid; > + > + port->dev_conf.rxmode.offloads = rx_offloads; > + > + /* Apply JUMBO_FRAME offload configuration to Rx queue(s) */ > + for (qid = 0; qid < port->dev_info.nb_rx_queues; qid++) { > + if (on) > + port->rx_conf[qid].offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME; > + else > + port->rx_conf[qid].offloads &= ~DEV_RX_OFFLOAD_JUMBO_FRAME; > + } Is it correct to set per-queue offloads that aren't advertised by the PMD as supported in rx_queue_offload_capa? > + } > + > + /* If JUMBO_FRAME is set MTU conversion done by ethdev layer, > + * if unset do it here > + */ > + if ((rx_offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) == 0) { > + ret = rte_eth_dev_set_mtu(portid, > + port->dev_conf.rxmode.max_rx_pkt_len - eth_overhead); > + if (ret) > + printf("Failed to set MTU to %u for port %u\n", > + port->dev_conf.rxmode.max_rx_pkt_len - eth_overhead, > + portid); > + } > + > + return 0; > +} > + Applied and tested with a few iterations of configuring max packet size back and forth between jumbo and non-jumbo sizes, also tried setting max packet size using the command-line option, all seems good based on rx offloads and packet forwarding. Two minor questions above, otherwise LGTM. --0000000000003da83405b9beba5f--