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 091EBA052A; Tue, 26 Jan 2021 04:45:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B801B1411F0; Tue, 26 Jan 2021 04:45:18 +0100 (CET) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mails.dpdk.org (Postfix) with ESMTP id 2E28D1411EB for ; Tue, 26 Jan 2021 04:45:17 +0100 (CET) Received: by mail-ot1-f41.google.com with SMTP id k8so15027828otr.8 for ; Mon, 25 Jan 2021 19:45:17 -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=3QWOEYU5b+WGyN+/scvuDr4xKO/k/Yg2d8zcrnFB6zw=; b=f+zQigMZYpPOf+uDq31BlF+mAHgOhe5Mk8GCx1ItLnIePau7rfcjGmbSFM0JsJKi6F XY3Mujs1DVq+Yv33HXnRjNcccMtpJq7sQQUdW4ru3hgG2whSXNd1rQ8cMzDY25Xp1lOY 69iyU/vCs602TAaUZ95EisL1LK8beb4Efqt04= 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=3QWOEYU5b+WGyN+/scvuDr4xKO/k/Yg2d8zcrnFB6zw=; b=dhopeTCF99A0wRIGPmQT/hd0/i/j/14YSA3c/7c4Lp/kUE6DrwXAaYJGw0QWQHmtuB GmzdydRHezMfa6ePU0586SpQwvMdKKSY6DY4fLa5vaOtCyUlzqe5lWKhT+6FfIjEG3lI 0IMQ78szu/EjP/l1hTTDOOwGfMdh0LkVn5wJCfxLJezk03cBrQPsdYAMinEIRX/QM8km CjAD+SlNI1Zp6Fwj7kZHxNBd38/QC1Q2yZj+g+ULe82KqFZBZ+g1wNg7RyNLvl+YPMV9 ErB80ceU1rg/ZW9FIlLI64jKsW6PL7Fu5vTDDPHxa9tJomaWdinubeMx9z1zP8PZah15 GVJA== X-Gm-Message-State: AOAM531p89XIxwrpiWih8N+wAmrz6bhlS+Ekg+TdqUJbmAU31jNE4qVG wD14FUBTAc3UEnPVneGtmAaW5D8y5igulIiJ73zJhQ== X-Google-Smtp-Source: ABdhPJyx04hBh6s6g8CQfi/poepkKm2C4b5OqNsV0cjIM0yv3t3hi4ZbkFl63t7JDiY3lm9TRx5EoanxPqFIA0ZjhVw= X-Received: by 2002:a9d:135:: with SMTP id 50mr2683126otu.267.1611632716365; Mon, 25 Jan 2021 19:45:16 -0800 (PST) MIME-Version: 1.0 References: <20210125083202.38267-1-stevex.yang@intel.com> <20210125181548.2713326-1-ferruh.yigit@intel.com> <1efbcf83-8b7f-682c-7494-44cacef55e36@intel.com> In-Reply-To: <1efbcf83-8b7f-682c-7494-44cacef55e36@intel.com> From: Lance Richardson Date: Mon, 25 Jan 2021 22:45:05 -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="000000000000959e6105b9c57bf2" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v5] app/testpmd: fix setting maximum packet length 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" --000000000000959e6105b9c57bf2 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 25, 2021 at 7:44 PM Ferruh Yigit wrote: > > >> + 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? > > > > 'port->rx_conf[]' is testpmd struct, and 'port->dev_conf.rxmode.offloads' values > are reflected to 'port->rx_conf[].offloads' for all queues. > > We should set the offload in 'port->rx_conf[].offloads' if it is set in > 'port->dev_conf.rxmode.offloads'. > > If a port has capability for 'JUMBO_FRAME', 'port->rx_conf[].offloads' can have > it. And the port level capability is already checked above. > I'm still not 100% clear about the per-queue offload question. With this patch, and jumbo max packet size configured (on the command line in this case), I see: testpmd> show port 0 rx_offload configuration Rx Offloading Configuration of port 0 : Port : JUMBO_FRAME Queue[ 0] : JUMBO_FRAME testpmd> show port 0 rx_offload capabilities Rx Offloading Capabilities of port 0 : Per Queue : Per Port : VLAN_STRIP IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO OUTER_IPV4_CKSUM VLAN_FILTER VLAN_EXTEND JUMBO_FRAME SCATTER TIMESTAMP KEEP_CRC OUTER_UDP_CKSUM RSS_HASH Yet if I configure a jumbo MTU starting with standard max packet size, jumbo is only enabled at the port level: testpmd> port config mtu 0 9000 testpmd> port start all testpmd> show port 0 rx_offload configuration Rx Offloading Configuration of port 0 : Port : JUMBO_FRAME Queue[ 0] : It still seems odd for a per-queue offload to be enabled on a PMD that doesn't support per-queue receive offloads. --000000000000959e6105b9c57bf2--