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 15812A052A for ; Tue, 26 Jan 2021 04:45:20 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 050AD141203; Tue, 26 Jan 2021 04:45:20 +0100 (CET) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by mails.dpdk.org (Postfix) with ESMTP id 489691411F0 for ; Tue, 26 Jan 2021 04:45:17 +0100 (CET) Received: by mail-ot1-f48.google.com with SMTP id n42so15014012ota.12 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=EsEFi/RElkUrhzFTsrHIAN5ftqWsgjyxBF8MLn8eFZw=; b=C7NxVd7J+izBWGyqGodLKr6OFAIOjS2yIFlNEpFzkHRmNA+YIgYRuQ9EpnYiChMFkw VemLu80GmyHV+b0frkh3ExsUDKlvFzmbYxnqdGcH/R4b9FmRijkWlmjuWswsFcxHHU7r yvx5QQOtAzXegREL58T3KsY10NiexsuDn1DCk= 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=EsEFi/RElkUrhzFTsrHIAN5ftqWsgjyxBF8MLn8eFZw=; b=IwIAYbOPBWvCai9hWmiQTv1VIhC6bXqKIIiqyZjPn5C8X+H5eOWQSBPNlKVtckUAow TbxTiLmfQagG625dVlQ+lc1nAtq+gCa4PGM1IaKsFlj8pxPazhhyIu0as+ZlYEwg86/L bay07o5YmB4jQXxxhuawCQQidZ3Lq21BWQjH8lpKMYrW7umKt1Qi7xkgkYaKChxVPyqm iqTgfhJBbmviO85H+HXADrZEWFv0YbWhmcPbYvfaEWyGKZ+pHhQnzd0wehrEbL8uVkJh KU+c0MRlzeu58kfHNbBk6wWQMsP2vBl1ELsiJmqN6WBRW974daoXMu+JX3j3IKa6zSz7 cznw== X-Gm-Message-State: AOAM532xNfHMWolepmPsBT3EfsiCy5rfcCl37w4xQ5YVSvMv6xy7/lov /7PQHUilpeAs/N1OnPFQmiNw5mS36PwGITNwm/4ccA== 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="00000000000095c4e505b9c57b6d" 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" --00000000000095c4e505b9c57b6d 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. --00000000000095c4e505b9c57b6d--