svn commit: r317547 - head/sys/net

[Alexander Motin]

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