Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 20 Jul 2020 16:36:58 -0700 (PDT)
Message-Id: <20200720.163658.560155959996455439.davem@davemloft.net>
To:     stephen@networkplumber.org
Cc:     willemdebruijn.kernel@gmail.com, srirakr2@cisco.com,
        akpm@linux-foundation.org, xe-linux-external@cisco.com,
        kuba@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, sthemmin@microsoft.com,
        mbumgard@cisco.com
Subject: Re: [PATCH v2] AF_PACKET doesnt strip VLAN information
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20200720135650.1939665b@hermes.lan>
References: <CY4PR1101MB21013DCD55B754E29AF4A838907B0@CY4PR1101MB2101.namprd11.prod.outlook.com>
        <CAF=yD-+gCkPVkXwcH6KiKYGV77TvpZiDo=3YyXeuGFk=TR2dcw@mail.gmail.com>
        <20200720135650.1939665b@hermes.lan>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, 20 Jul 2020 13:56:50 -0700

> It matters because the problem is generic, not just to the netvsc driver.
> For example, BPF programs and netfilter rules will see different packets
> when send is through AF_PACKET than they would see for sends from the
> kernel stack.
> 
> Presenting uniform data to the lower layers makes sense.

The issue here is that for hyperv, vlan offloading is not a "may" but
a "must" and I've never understood it to have that meaning.

And I still haven't heard what is going to happen in Q-in-Q situations
even with the ugly hyperv driver hack that is currently under review.