From owner-svn-src-head@freebsd.org Sat Apr 29 06:36:07 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD8FED54629; Sat, 29 Apr 2017 06:36:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BE911297; Sat, 29 Apr 2017 06:36:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id c80so43138270lfh.3; Fri, 28 Apr 2017 23:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cnUb883Gg3baZCajb8/0TLWvSgwR+cRKSKw2dvs5J2E=; b=mznmaCaG6x/TKGYgKz0HpXvvPbDG/KnuFwmHgKwE1kFLXGjO3GHcsTPZNXvHodcoe1 nOKeaiHv6FfqavU85omZr98tnH3gfIaiuKz0rG4opYi1hXPcwQG0TKxVJQywNWVC8gyV AoTm1ARWixn9Ok0vOIOf+6E10ua2IV8B5fyt8xz8WQmrbXacTijjcObHkayDgNTNqs2F AsfXHWXBbVgsT6bJNlgyK/EFlGYqdtmRq8uukqRKmz7+NGsCQU6UK6JkxnSwttQI5daz 0WLXer1NKUJe818RUe5mhF1JmRWBzVYJVieoxKdPEqCrvMDQlPt6pWTJbgWhzUef93Gi 7Kig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cnUb883Gg3baZCajb8/0TLWvSgwR+cRKSKw2dvs5J2E=; b=ClpWfDTsV5FaGuZ/ju5wa5Z+nohEnv6gkMKx58mbVZ3K9innt1kDUGn2qQF5ydg7sN id/IPkdJ+vbZlWRgp14NA3XUc3uoRgsLiqeE1/njsVBKEu4a/URO0CICiLDzh1YaxN4J ErN0Y4GjZMQ/rxitNk4ePKt3e/6Exl7/mZ9myp/vbmx/j37pQfN/fsrzfCaRRywN5Qd3 F8+k912f9bRk/hbjB3I1SXbnD1AQh70dTuBjn5U35pD6VHFn4BChHyifgagRHeA5qs2H jJFWaZeHmdSJnDNy5MCD7y4HVSNgD9Pu78eyPiHk7Oz/h1L3Xf35toheFzfAAS5kKYOc xvCA== X-Gm-Message-State: AN3rC/5WP1Byb0JhNiPiWvqMfzUhXgqDkdyyoSVSpOeFT7YeU3irI5yH kGCZVmQNwfXNe7+MTWo= X-Received: by 10.46.33.11 with SMTP id h11mr5975853ljh.57.1493447764424; Fri, 28 Apr 2017 23:36:04 -0700 (PDT) Received: from spectre.mavhome.dp.ua ([134.249.139.101]) by smtp.gmail.com with ESMTPSA id 26sm1446916lfr.7.2017.04.28.23.36.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 23:36:03 -0700 (PDT) Sender: Alexander Motin Subject: Re: svn commit: r317547 - head/sys/net To: Gleb Smirnoff Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201704281100.v3SB0wgY005696@repo.freebsd.org> <20170429021651.GZ56922@FreeBSD.org> From: Alexander Motin Message-ID: Date: Sat, 29 Apr 2017 09:36:02 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170429021651.GZ56922@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 06:36:07 -0000 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