From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 843D6A04A7; Wed, 2 Mar 2022 18:40:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F6E74068B; Wed, 2 Mar 2022 18:40:36 +0100 (CET) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id DC77740141 for <dev@dpdk.org>; Wed, 2 Mar 2022 18:40:34 +0100 (CET) Received: by mail-pl1-f176.google.com with SMTP id 9so2187285pll.6 for <dev@dpdk.org>; Wed, 02 Mar 2022 09:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8SUUfuh/WyvbiYlMj2wvmWPTPfPXnjbkmconRTsFJUY=; b=7gbUmofhqL4icL7/Qd+TnJoJw/kWQpKpd7PGy+BmDVSGVmzZccL72I0Q8bLHx28He1 JfKqrdFzibvALsA1XwF8NuoBOifjmnCE3rXk3NVz40NxBENlhzU6nZOA+RdqvpAzatuU 8sp3n4KV241xtoFg3sAxWyqZ7zDwZ4eJwLF5DUiDdLlrM/xoyUUFGo6Hu5tEjE0lU6io nZnQ0ROET2zQloR100fFSrqLt3SCxvGTstyltdZKBdNgjzMS8i0By9vzUmw/O8FjIf/6 +WE2PUa5AKFI2FZedYwQsn4X+sP6etnl1Q7YWBXCzeCvWEGueKWzrmEN1rDEiOMoncwR elGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8SUUfuh/WyvbiYlMj2wvmWPTPfPXnjbkmconRTsFJUY=; b=4L07Em5u8TxRCwpGHaDJuiZX7/NC0lOTJFh/dP0SrVqAwbxQSlq+rrFrJfTDRhLeTb HC4kSAhU+KTKjCOudYyO9Xx9K/KoFseGYGCWVs5M2znU+t3A53HZP5Men8oyxyeJg/9v xgtt+3Y5GWMxfBzd/2yF8baCAjfjkBInVlw3jxFaK8c6Dq6guSeP/cNsSkhFupUwG+E2 LKwrTPDbTj4iQhgiGCjJOi9kxN4qOswbgihRc1F3Mf9xumnG+Vz8ycBpAd9mUYoL4xXZ TdpPbWEBOc2YyjGEO3lZ4g0F3u9Ie8aaVVhOhVCiqAK/eU5b6KOQnVhznpEOEeP646xZ 3kiA== X-Gm-Message-State: AOAM533+lqwmi3xTHPmDSsazYnAPUbxhwEN0ESUVkTPpgXlLIuJQbjOE 4Z3mkVBrWmx2t0Uzj6E61r3HIg== X-Google-Smtp-Source: ABdhPJz8HrcEI1ysXUJYj3qZgxpifxZgv+YpKq77BZZDFyLkNIQK7JV4qk2nhCgVhRvFi3sFahaesw== X-Received: by 2002:a17:902:864b:b0:14c:d45e:a77b with SMTP id y11-20020a170902864b00b0014cd45ea77bmr31614426plt.143.1646242834037; Wed, 02 Mar 2022 09:40:34 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id u5-20020a056a00158500b004f0f12b320asm22863093pfk.6.2022.03.02.09.40.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 09:40:33 -0800 (PST) Date: Wed, 2 Mar 2022 09:40:26 -0800 From: Stephen Hemminger <stephen@networkplumber.org> To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com> Cc: "Ferruh Yigit" <ferruh.yigit@intel.com>, <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net>, "Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>, <matan@nvidia.com>, "Qi Zhang" <qi.z.zhang@intel.com>, "Ajit Khaparde" <ajit.khaparde@broadcom.com>, "Ray Kinsella" <mdr@ashroe.eu>, "Bruce Richardson" <bruce.richardson@intel.com>, "Damjan Marion (damarion)" <damarion@cisco.com>, "Roy Fan Zhang" <roy.fan.zhang@intel.com>, "Min Hu (Connor)" <humin29@huawei.com>, "Konstantin Ananyev" <konstantin.ananyev@intel.com>, "Stokes, Ian" <ian.stokes@intel.com>, "David Marchand" <david.marchand@redhat.com> Subject: Re: MTU and frame size filtering inaccuracy Message-ID: <20220302094026.531fd14a@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86F17@smartserver.smartshare.dk> References: <e2554b78-cdda-aa33-ac6d-59a543a10640@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D86F14@smartserver.smartshare.dk> <20220302082159.06d3d872@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35D86F17@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Wed, 2 Mar 2022 17:50:13 +0100 Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote: > Again, Postel's Law makes perfect sense on a server. >=20 > On a network appliance, I would prefer discarding oversize packets at ing= ress, rather than process them and discard them at egress. >=20 > I do admit that my viewpoint is quite academic, and mostly relevant for L= 2 bridging appliances, where fragmentation is not available. It is probably= the best approach for DPDK to align the API with what common NIC hardware = supports. In other words, I agree with Stephen. :-) The HW should try (if it can) and filter overly large frames, but it is sti= ll the responsibility of router and bridge software to look at MTU of the egress port and take ac= tion. For L2 bridge, that means silently dropping and for L3 that is responding w= ith ICMP. The DPDK examples don't do this, and they should.