From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <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
Date: Wed, 2 Mar 2022 09:40:26 -0800 [thread overview]
Message-ID: <20220302094026.531fd14a@hermes.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86F17@smartserver.smartshare.dk>
On Wed, 2 Mar 2022 17:50:13 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> Again, Postel's Law makes perfect sense on a server.
>
> On a network appliance, I would prefer discarding oversize packets at ingress, rather than process them and discard them at egress.
>
> I do admit that my viewpoint is quite academic, and mostly relevant for L2 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 still the responsibility
of router and bridge software to look at MTU of the egress port and take action.
For L2 bridge, that means silently dropping and for L3 that is responding with ICMP.
The DPDK examples don't do this, and they should.
prev parent reply other threads:[~2022-03-02 17:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 17:50 Ferruh Yigit
2022-03-02 8:53 ` Morten Brørup
2022-03-02 16:21 ` Stephen Hemminger
2022-03-02 16:50 ` Morten Brørup
2022-03-02 17:40 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220302094026.531fd14a@hermes.local \
--to=stephen@networkplumber.org \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=damarion@cisco.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=humin29@huawei.com \
--cc=ian.stokes@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=matan@nvidia.com \
--cc=mb@smartsharesystems.com \
--cc=mdr@ashroe.eu \
--cc=qi.z.zhang@intel.com \
--cc=roy.fan.zhang@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).