All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.