From: Stephen Hemminger <stephen@networkplumber.org>
To: "Fredrik Markström" <fredrik.markstrom@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls
Date: Thu, 11 May 2017 12:44:54 -0700 [thread overview]
Message-ID: <20170511124454.473dd56e@xeon-e3> (raw)
In-Reply-To: <CAKdL+dS_-UiHA5tr7zP-5LtwDd0aXpZq5tpMYf9kr7hu2SwdGQ@mail.gmail.com>
On Thu, 11 May 2017 21:10:11 +0200
Fredrik Markström <fredrik.markstrom@gmail.com> wrote:
> On Thu, May 11, 2017 at 6:01 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Thu, 11 May 2017 15:46:27 +0200
> > Fredrik Markstrom <fredrik.markstrom@gmail.com> wrote:
> >
> >> From: Fredrik Markström <fredrik.markstrom@gmail.com>
> >>
> >> is_skb_forwardable() currently checks if the packet size is <= mtu of
> >> the receiving interface. This is not consistent with most of the hardware
> >> ethernet drivers that happily receives packets larger then MTU.
> >
> > Wrong.
>
> What is "Wrong" ? I was initially skeptical to implement this patch,
> since it feels odd to have different MTU:s set on the two sides of a
> link. After consulting some IP people and the RFC:s I kind of changed
> my mind and thought I'd give it a shot. In the RFCs I couldn't find
> anything that defined when and when not a received packet should be
> dropped.
>
> >
> > Hardware interfaces are free to drop any packet greater than MTU (actually MTU + VLAN).
> > The actual limit is a function of the hardware. Some hardware can only limit by
> > power of 2; some can only limit frames larger than 1500; some have no limiting at all.
>
> Agreed. The purpose of these patches is to be able to configure an
> veth interface to mimic these different behaviors. Non of the Ethernet
> interfaces I have access to drops packets due to them being larger
> then the configured MTU like veth does.
>
> Being able to mimic real Ethernet hardware is useful when
> consolidating hardware using containers/namespaces.
>
> In a reply to a comment from David Miller in my previous version of
> the patch I attached the example below to demonstrate the case in
> detail.
>
> This works with all ethernet hardware setups I have access to:
>
Why not just use an iptables rule to enforce what ever semantic you
want?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Fredrik Markström" <fredrik.markstrom@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bridge@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls
Date: Thu, 11 May 2017 12:44:54 -0700 [thread overview]
Message-ID: <20170511124454.473dd56e@xeon-e3> (raw)
In-Reply-To: <CAKdL+dS_-UiHA5tr7zP-5LtwDd0aXpZq5tpMYf9kr7hu2SwdGQ@mail.gmail.com>
On Thu, 11 May 2017 21:10:11 +0200
Fredrik Markström <fredrik.markstrom@gmail.com> wrote:
> On Thu, May 11, 2017 at 6:01 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Thu, 11 May 2017 15:46:27 +0200
> > Fredrik Markstrom <fredrik.markstrom@gmail.com> wrote:
> >
> >> From: Fredrik Markström <fredrik.markstrom@gmail.com>
> >>
> >> is_skb_forwardable() currently checks if the packet size is <= mtu of
> >> the receiving interface. This is not consistent with most of the hardware
> >> ethernet drivers that happily receives packets larger then MTU.
> >
> > Wrong.
>
> What is "Wrong" ? I was initially skeptical to implement this patch,
> since it feels odd to have different MTU:s set on the two sides of a
> link. After consulting some IP people and the RFC:s I kind of changed
> my mind and thought I'd give it a shot. In the RFCs I couldn't find
> anything that defined when and when not a received packet should be
> dropped.
>
> >
> > Hardware interfaces are free to drop any packet greater than MTU (actually MTU + VLAN).
> > The actual limit is a function of the hardware. Some hardware can only limit by
> > power of 2; some can only limit frames larger than 1500; some have no limiting at all.
>
> Agreed. The purpose of these patches is to be able to configure an
> veth interface to mimic these different behaviors. Non of the Ethernet
> interfaces I have access to drops packets due to them being larger
> then the configured MTU like veth does.
>
> Being able to mimic real Ethernet hardware is useful when
> consolidating hardware using containers/namespaces.
>
> In a reply to a comment from David Miller in my previous version of
> the patch I attached the example below to demonstrate the case in
> detail.
>
> This works with all ethernet hardware setups I have access to:
>
Why not just use an iptables rule to enforce what ever semantic you
want?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Fredrik Markström" <fredrik.markstrom@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls
Date: Thu, 11 May 2017 12:44:54 -0700 [thread overview]
Message-ID: <20170511124454.473dd56e@xeon-e3> (raw)
In-Reply-To: <CAKdL+dS_-UiHA5tr7zP-5LtwDd0aXpZq5tpMYf9kr7hu2SwdGQ@mail.gmail.com>
On Thu, 11 May 2017 21:10:11 +0200
Fredrik Markström <fredrik.markstrom@gmail.com> wrote:
> On Thu, May 11, 2017 at 6:01 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Thu, 11 May 2017 15:46:27 +0200
> > Fredrik Markstrom <fredrik.markstrom@gmail.com> wrote:
> >
> >> From: Fredrik Markström <fredrik.markstrom@gmail.com>
> >>
> >> is_skb_forwardable() currently checks if the packet size is <= mtu of
> >> the receiving interface. This is not consistent with most of the hardware
> >> ethernet drivers that happily receives packets larger then MTU.
> >
> > Wrong.
>
> What is "Wrong" ? I was initially skeptical to implement this patch,
> since it feels odd to have different MTU:s set on the two sides of a
> link. After consulting some IP people and the RFC:s I kind of changed
> my mind and thought I'd give it a shot. In the RFCs I couldn't find
> anything that defined when and when not a received packet should be
> dropped.
>
> >
> > Hardware interfaces are free to drop any packet greater than MTU (actually MTU + VLAN).
> > The actual limit is a function of the hardware. Some hardware can only limit by
> > power of 2; some can only limit frames larger than 1500; some have no limiting at all.
>
> Agreed. The purpose of these patches is to be able to configure an
> veth interface to mimic these different behaviors. Non of the Ethernet
> interfaces I have access to drops packets due to them being larger
> then the configured MTU like veth does.
>
> Being able to mimic real Ethernet hardware is useful when
> consolidating hardware using containers/namespaces.
>
> In a reply to a comment from David Miller in my previous version of
> the patch I attached the example below to demonstrate the case in
> detail.
>
> This works with all ethernet hardware setups I have access to:
>
Why not just use an iptables rule to enforce what ever semantic you
want?
next prev parent reply other threads:[~2017-05-11 19:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-11 13:46 [Bridge] [PATCH v2 0/2] net: Set maximum receive packet size on veth interfaces Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` [Bridge] [PATCH v2 1/2] net: Added mtu parameter to dev_forward_skb calls Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 16:01 ` [Bridge] " Stephen Hemminger
2017-05-11 16:01 ` Stephen Hemminger
2017-05-11 19:10 ` [Bridge] " Fredrik Markström
2017-05-11 19:10 ` Fredrik Markström
2017-05-11 19:10 ` Fredrik Markström
2017-05-11 19:44 ` Stephen Hemminger [this message]
2017-05-11 19:44 ` Stephen Hemminger
2017-05-11 19:44 ` Stephen Hemminger
2017-05-12 14:35 ` [Bridge] " Fredrik Markström
2017-05-12 14:35 ` Fredrik Markström
2017-05-12 14:35 ` Fredrik Markström
2017-05-12 8:05 ` [Bridge] " Teco Boot
2017-05-12 8:05 ` Teco Boot
2017-05-12 8:05 ` [Bridge] " Teco Boot
2017-05-12 12:48 ` Fredrik Markström
2017-05-12 12:48 ` Fredrik Markström
2017-05-12 12:48 ` [Bridge] " Fredrik Markström
2017-05-11 13:46 ` [Bridge] [PATCH v2 2/2] veth: Added attribute to set maximum receive size on veth interfaces Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` [Bridge] Support for VETH_MRU in libnl Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
2017-05-11 13:46 ` Fredrik Markstrom
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=20170511124454.473dd56e@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=ast@kernel.org \
--cc=bridge@lists.linux-foundation.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fredrik.markstrom@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.