On 16/09/29 (木) 21:49, Jiri Benc wrote:
On Tue, 27 Sep 2016 17:55:40 +0900, Toshiaki Makita wrote:
This adds support for envhdrlen.
Example:
# ip link set eno1 envhdrlen 8
Thank you for taking a look at this.
I don't see why this should be user visible, let alone requiring user
to set it. This should be transparent, kernel should compute the value
as needed based on the configuration and set it up. Requiring the
administrator to pick up a calculator and sum up all the vlan, mpls and
whatever header lengths is silly.
I'm thinking both in-kernel automation (for VLAN) and users' manual
operation are necessary. In fact, as I stated in the cover letter, my
first implementation was an automation-based approach. Actually
automation is advanced form of this feature so I'm proposing this very
basic feature first.
I realize that we currently have no easy way to do that. Especially
with lwtunnels and stuff line MPLS where we don't easily know the
number of tags. But every uAPI we introduce will have to be supported
forever and going a particular way just because it is easy to implement
is not sustainable.
It may be possible for MPLS lwtunnel to notify underlying device of
needed header length. But at this point MPLS does not allow encapsulated
packets to be greater than MTU of underlying device. So how to determine
if someone wants to leverage envhdrlen instead? Add a knob to lwtunnel
layer? Then, add another knob to l2tp, iptunnel, or anything like that?
At least full-automation does not look possible other than VLAN (which
by default requires envhdrlen expansion), so anyway manual operation is
needed in some form.
Another use-case is reducing envhdrlen. We can expand it on creating
VLAN device automatically, but cannot decrease the size because there
could be other consumers of envhdrlen.
At the very least, it should be configurable from the other direction.
I.e. telling which interfaces can be used by vlans or MPLS (if it
cannot be inferred automatically) and configuring maximum number of
tags on the given vlan/mpls/whatever interface/route/whatever.
Probably I don't get your point...
Are you suggesting something like this?
$ ip link set eth0.10.20 expand-realdev-envhdrlen
or like this?
$ ip link set eth0 allowed-vlan-tags 2
Toshiaki Makita
