Date: Sat, 29 Apr 2017 09:36:02 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Gleb Smirnoff <glebius@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: <c126691d-b7b5-d23d-a751-d5fe1650fa83@FreeBSD.org> In-Reply-To: <20170429021651.GZ56922@FreeBSD.org> References: <201704281100.v3SB0wgY005696@repo.freebsd.org> <20170429021651.GZ56922@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29.04.2017 05:16, Gleb Smirnoff wrote: > 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. Thanks for looking. I agree that all those arguments are valid for code removed in r281885. But if you look closer, my code is different. In its present state it does not propagate any capabilities change to the trunk or other vlans, affecting only the specified vlan. With my code there also may be some collisions, for example, if somebody first disable capability X for vlanN and then enable Y for trunk, Y may not get propagated to the vlanN since it wasn't present in the mask set there while disabling X. But I think it is a minor price to pay. I've made additional experiments with LRO flag, and they shown me that 1) that flag should be passed through from trunk to vlans, and 2) I do want to propagate that flag disable from vlan back to trunk, since its absence or disable for vlan does not change anything -- trunk continues feeding aggregated packets, which may not be welcome in case of later bridging. But I am not going to do it in so straightforward way it was done there previous time, since it was clearly broken, for example, for IFCAP_VLAN_HWTAGGING. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c126691d-b7b5-d23d-a751-d5fe1650fa83>