From: Toshiaki Makita <toshiaki.makita1@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v2 net-next 0/4] Automatic adjustment of max frame size
Date: Wed, 28 Oct 2015 16:40:16 +0900 [thread overview]
Message-ID: <56307BE0.5080606@gmail.com> (raw)
In-Reply-To: <20151028135820.72329de4@samsung9>
On 15/10/28 (?) 13:58, Stephen Hemminger wrote:
> On Mon, 26 Oct 2015 12:40:55 +0900
> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
...
Thank you for taking a look at the patch set.
I'm not sure if I fully understand you, so please correct me if I
misread you.
> The problem is that you require changing network device drivers
> and device specific knowledge about what will work or not. Because
> of that the modificaton can't be automated.
I'm not sure what you mean by "device specific knowledge" and "automated"...
Indeed, this requires change in each driver.
But required changes in drivers should be mostly making use of
ndo_change_mtu implementation code and not hard. We can progressively
implement ndo_enc_hdr_len for each driver.
If max frame size cannot be changed on a certain NIC, vlan driver will
emit a warning message and make MTU smaller, then userspace can handle
it (patch 3). If needed, maybe we can expose this feature via ethtool.
>
> Also, this effects even more layered devices like tunnels etc.
Yes, if tunnel devices start to utilize this framework. This is one of
purposes of my patch set.
> The problem is quite large, and this patch only begins to address it.
Yes, this is the first step to address the problem.
>
> It seems to me that just having the vlan driver to a sane
> auto default is the best solution.
For now, this patch implementation is limited to vlan. For other
protocols, auto-expansion may not be suitable and may need some nob to
use the framework.
If you mean just making MTU smaller on vlan device instead of adjusting
max frame size of real device, then it would not work. 802.1ad HW
switches, at any rate, send 1526 bytes frames so they will be dropped on
the real device.
> It might cause a smaller MTU
> than ideal, but at least it will still work. Then the user can
> manually set a larger MTU if they know their hardware will work.
Toshiaki Makita
WARNING: multiple messages have this Message-ID (diff)
From: Toshiaki Makita <toshiaki.makita1@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: "David S . Miller" <davem@davemloft.net>,
Patrick McHardy <kaber@trash.net>,
Vlad Yasevich <vyasevich@gmail.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 net-next 0/4] Automatic adjustment of max frame size
Date: Wed, 28 Oct 2015 16:40:16 +0900 [thread overview]
Message-ID: <56307BE0.5080606@gmail.com> (raw)
In-Reply-To: <20151028135820.72329de4@samsung9>
On 15/10/28 (水) 13:58, Stephen Hemminger wrote:
> On Mon, 26 Oct 2015 12:40:55 +0900
> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
...
Thank you for taking a look at the patch set.
I'm not sure if I fully understand you, so please correct me if I
misread you.
> The problem is that you require changing network device drivers
> and device specific knowledge about what will work or not. Because
> of that the modificaton can't be automated.
I'm not sure what you mean by "device specific knowledge" and "automated"...
Indeed, this requires change in each driver.
But required changes in drivers should be mostly making use of
ndo_change_mtu implementation code and not hard. We can progressively
implement ndo_enc_hdr_len for each driver.
If max frame size cannot be changed on a certain NIC, vlan driver will
emit a warning message and make MTU smaller, then userspace can handle
it (patch 3). If needed, maybe we can expose this feature via ethtool.
>
> Also, this effects even more layered devices like tunnels etc.
Yes, if tunnel devices start to utilize this framework. This is one of
purposes of my patch set.
> The problem is quite large, and this patch only begins to address it.
Yes, this is the first step to address the problem.
>
> It seems to me that just having the vlan driver to a sane
> auto default is the best solution.
For now, this patch implementation is limited to vlan. For other
protocols, auto-expansion may not be suitable and may need some nob to
use the framework.
If you mean just making MTU smaller on vlan device instead of adjusting
max frame size of real device, then it would not work. 802.1ad HW
switches, at any rate, send 1526 bytes frames so they will be dropped on
the real device.
> It might cause a smaller MTU
> than ideal, but at least it will still work. Then the user can
> manually set a larger MTU if they know their hardware will work.
Toshiaki Makita
next prev parent reply other threads:[~2015-10-28 7:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 3:40 [Intel-wired-lan] [PATCH v2 net-next 0/4] Automatic adjustment of max frame size Toshiaki Makita
2015-10-26 3:40 ` Toshiaki Makita
2015-10-26 3:40 ` [Intel-wired-lan] [PATCH v2 net-next 1/4] net: Add ndo_enc_hdr_len to notify extra header room for encapsulated frames Toshiaki Makita
2015-10-26 3:40 ` Toshiaki Makita
2015-10-26 3:40 ` [Intel-wired-lan] [PATCH v2 net-next 2/4] e1000e: Add ndo_enc_hdr_len Toshiaki Makita
2015-10-26 3:40 ` Toshiaki Makita
2015-10-26 3:40 ` [Intel-wired-lan] [PATCH v2 net-next 3/4] vlan: Notify real device of encap header length Toshiaki Makita
2015-10-26 3:40 ` Toshiaki Makita
2015-10-26 3:40 ` [Intel-wired-lan] [PATCH v2 net-next 4/4] bridge: Notify port " Toshiaki Makita
2015-10-26 3:40 ` Toshiaki Makita
2015-10-28 2:30 ` [Intel-wired-lan] [PATCH v2 net-next 0/4] Automatic adjustment of max frame size David Miller
2015-10-28 2:30 ` David Miller
2015-10-28 4:58 ` [Intel-wired-lan] " Stephen Hemminger
2015-10-28 4:58 ` Stephen Hemminger
2015-10-28 7:40 ` Toshiaki Makita [this message]
2015-10-28 7:40 ` Toshiaki Makita
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=56307BE0.5080606@gmail.com \
--to=toshiaki.makita1@gmail.com \
--cc=intel-wired-lan@osuosl.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.