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 13672A0A02; Thu, 14 Jan 2021 18:29:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D368D1413E8; Thu, 14 Jan 2021 18:29:45 +0100 (CET) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id 123C91413E7 for ; Thu, 14 Jan 2021 18:29:44 +0100 (CET) Received: by mail-pf1-f182.google.com with SMTP id c79so3771076pfc.2 for ; Thu, 14 Jan 2021 09:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pensando.io; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8Wt7tgG5o9ZWArlrO03pZ0TUile4kKk6L1BDr9syvoc=; b=Jq39QxfBjECt/gF0qMnpXMdvyIP7jUuiDXbty+beg4Dxl4stPHTnVXm522mYc2wvuJ 3vGbKWBto3r8YgmQJ5bd8jX675TTft3zkgoNqLVHMf+ky9Q3GaYJLQ8DC2a6mAhbxPWR XM4hn9I/o9dvFpg3Unq0QJBDxagJ2eUy/H1mC194rPeHLus/It5AQ8QAzqRGC844h7I+ ZI2N/PF0voEiwp1nExd7UsYKrefFVrlyRG6Pojf4OZdKoHQaeBzJVkPLhk6B/F2T3Fg5 0VH0w0+3zx27mys5nanBOAll+9lAFP1n4bJSx9OuKKobP+pLSIZ/7pTV/Rem62+seofI SHcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8Wt7tgG5o9ZWArlrO03pZ0TUile4kKk6L1BDr9syvoc=; b=iHeNEeygLiCZqi6jIzDov9H2A5hROfW7xco+S2EwSjgDqk6tBS72SxWV4TLEMwnAjz E7UJ6SFtzwOi8pR6/QPMe3OSQOtUusRuS56qAHvPf3KIsokmEY4yejJrxDg6OJ/YiHCT RWfF5kKZHIckSbcUt7uIVWUmZy9eImyYbPoO0S/SbeC/FhuGKPiW0YlFLQtlP72ep8rg 23EKxFmTYJTuXuOhBDTmo6nANfAKkyZip1D7f4YKoxHbW55qfShd6i4remEyXNTXgq0w uMEYMSPFwYlu/2Tw3xawWEboybmb8bDv2UAK9dsmpOZBORQ27rORnidIj90fgmJJa2b8 MLgg== X-Gm-Message-State: AOAM5302zhTjIQB1f/R49a090MXlERsrRE1UjVaqeCpp8DV1TXAQTtVU w+rNUsRHfDordpPkuiGQ/LngfA== X-Google-Smtp-Source: ABdhPJwPSOyU2Zq9/igelMMdZFUyLIEmN2d5HMxjgE0aVvLXKOwEfzVp3TGnA2XcGKfAOPAJJ6GnJA== X-Received: by 2002:a63:1865:: with SMTP id 37mr8552305pgy.206.1610645383122; Thu, 14 Jan 2021 09:29:43 -0800 (PST) Received: from ?IPv6:2600:1700:6b0:fde0:8ce5:94fe:3825:7b95? ([2600:1700:6b0:fde0:8ce5:94fe:3825:7b95]) by smtp.gmail.com with ESMTPSA id a12sm5982809pgq.5.2021.01.14.09.29.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jan 2021 09:29:42 -0800 (PST) From: Andrew Boyer Message-Id: <97F6D3C8-E222-407C-A523-1E5D2552442A@pensando.io> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 14 Jan 2021 12:29:40 -0500 In-Reply-To: <96dd6d7a-7af3-2c59-b25f-e9f0cad974d0@intel.com> Cc: Steve Yang , dev@dpdk.org, thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, oulijun@huawei.com To: Ferruh Yigit References: <20201217092312.27033-1-stevex.yang@intel.com> <20210114094537.13661-1-stevex.yang@intel.com> <53a37e85-fdba-ae58-1028-1facc33884dc@intel.com> <96dd6d7a-7af3-2c59-b25f-e9f0cad974d0@intel.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v3 01/22] ethdev: fix MTU size exceeds max rx 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" > On Jan 14, 2021, at 12:13 PM, Ferruh Yigit = wrote: >=20 > On 1/14/2021 4:36 PM, Ferruh Yigit wrote: >> On 1/14/2021 9:45 AM, Steve Yang wrote: >>> Ethdev is using default Ethernet overhead to decide if provided >>> 'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value, >>> and limits it to MAX if it is. >>>=20 >>> Since the application/driver used Ethernet overhead is different = than >>> the ethdev one, check result is wrong. >>>=20 >>> If the driver is using Ethernet overhead bigger than the default = one, >>> the provided 'max_rx_pkt_len' is trimmed down, and in the driver = when >>> correct Ethernet overhead is used to convert back, the resulting MTU = is >>> less than the intended one, causing some packets to be dropped. >>>=20 >>> Like, >>> app -> max_rx_pkt_len =3D 1500/*mtu*/ + 22/*overhead*/ =3D 1522 >>> ethdev -> 1522 > 1518/*MAX*/; max_rx_pkt_len =3D 1518 >>> driver -> MTU =3D 1518 - 22 =3D 1496 >>> Packets with size 1497-1500 are dropped although intention is to be = able >>> to send/receive them. >>>=20 >>> The fix is to make ethdev use the correct Ethernet overhead for = port, >>> instead of default one. >>>=20 >>> Fixes: 59d0ecdbf0e1 ("ethdev: MTU accessors") >>>=20 >>> Signed-off-by: Steve Yang >> <...> >>> @@ -1410,11 +1422,18 @@ rte_eth_dev_configure(uint16_t port_id, = uint16_t nb_rx_q, uint16_t nb_tx_q, >>> goto rollback; >>> } >>> } else { >>> - if (dev_conf->rxmode.max_rx_pkt_len < RTE_ETHER_MIN_LEN || >>> - dev_conf->rxmode.max_rx_pkt_len > RTE_ETHER_MAX_LEN) >>> + uint16_t pktlen =3D dev_conf->rxmode.max_rx_pkt_len; >>> + if (pktlen < RTE_ETHER_MIN_MTU + overhead_len || >>> + pktlen > RTE_ETHER_MTU + overhead_len) >>> /* Use default value */ >>> dev->data->dev_conf.rxmode.max_rx_pkt_len =3D >>> - RTE_ETHER_MAX_LEN; >>> + RTE_ETHER_MTU + overhead_len; >> What do you think removing the above check, the else block, = completely? >> Since the 'max_rx_pkt_len' should not be used when jumbo frame is not = set. >=20 > As I tested removing this check is causing problem because some PMDs = are using the 'max_rx_pkt_len' even jumbo frame is not set. >=20 > Perhaps better to keep it, and make a separate patch later to remove = this check, after PMDs fixed. Hello Ferruh - Working on fixing our PMD here. Do you want PMDs to update the = JUMBO_FRAME flag based on the mtu value in dev_set_mtu(), or do you want = the application to be solely responsible for it? Thanks, Andrew >>> + } >>> + >>> + /* Scale the MTU size to adapt max_rx_pkt_len */ >>> + if (dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_JUMBO_FRAME) { >>> + dev->data->mtu =3D = dev->data->dev_conf.rxmode.max_rx_pkt_len - >>> + overhead_len; >>> } >> Above if block has exact same check, why not move it above block? >=20 > Can you still send a new version for above change please?