Date: Fri, 28 Apr 2017 19:16:51 -0700 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r317547 - head/sys/net Message-ID: <20170429021651.GZ56922@FreeBSD.org> In-Reply-To: <201704281100.v3SB0wgY005696@repo.freebsd.org> References: <201704281100.v3SB0wgY005696@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 28, 2017 at 11:00:58AM +0000, Alexander Motin wrote: A> Author: mav A> Date: Fri Apr 28 11:00:58 2017 A> New Revision: 317547 A> URL: https://svnweb.freebsd.org/changeset/base/317547 A> A> Log: A> Allow some control over enabled capabilities for if_vlan. A> A> It improves interoperability with if_bridge, which may need to disable A> some capabilities not supported by other members. IMHO there is still A> open question about LRO capability, which may need to be disabled on A> physical interface. A> A> MFC after: 2 weeks A> Sponsored by: iXsystems, Inc. On quick glance this looks like the opposite to what was done in r281885. As discussed back 2 years ago: - There are no NICs that are able to have different set of capabilities turned on on different VLANs, and unlikely such will appear. - Capabilities should be switched on VLAN trunk. - Allowing to switch capabilities on a VLAN with magical flip of properties of all the VLANs on the same trunk is an ugly design. This is something unexpected for a sysadmin. Better refuse that and make him toggle properties on the trunk explicitily. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170429021651.GZ56922>