From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [PATCH] filter: introduce SKF_AD_VLAN_PROTO BPF extension Date: Wed, 04 Mar 2015 18:41:50 -0800 Message-ID: <54F7C26E.3040704@plumgrid.com> References: <1425501718-12066-1-git-send-email-msekleta@redhat.com> <54F77336.7040006@plumgrid.com> <54F7BF43.80203@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Jiri Pirko To: Toshiaki Makita , Michal Sekletar , netdev@vger.kernel.org Return-path: Received: from mail-ie0-f176.google.com ([209.85.223.176]:38251 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753860AbbCEClt (ORCPT ); Wed, 4 Mar 2015 21:41:49 -0500 Received: by iecrd18 with SMTP id rd18so72830349iec.5 for ; Wed, 04 Mar 2015 18:41:48 -0800 (PST) In-Reply-To: <54F7BF43.80203@lab.ntt.co.jp> Sender: netdev-owner@vger.kernel.org List-ID: On 3/4/15 6:28 PM, Toshiaki Makita wrote: > On 2015/03/05 6:03, Alexei Starovoitov wrote: >> On 3/4/15 12:41 PM, Michal Sekletar wrote: >>> This commit introduces new BPF extension. It makes possible to load >>> value of >>> skb->vlan_proto (vlan tpid) to register A. >>> >>> Currently, vlan header is removed from frame and information is >>> available to >>> userspace only via tpacket interface. Hence, it is not possible to >>> install >>> filter which uses value of vlan tpid field. >>> >>> AFAICT only way how to filter based on tpid value is to reconstruct >>> original >>> frame encapsulation and interpret BPF filter code in userspace. Doing >>> that is >>> way slower than doing filtering in kernel. >>> >>> Cc: Alexei Starovoitov >>> Cc: Jiri Pirko >>> Signed-off-by: Michal Sekletar >>> --- >>> @@ -282,6 +282,7 @@ Possible BPF extensions are shown in the following >>> table: >>> vlan_tci skb_vlan_tag_get(skb) >>> vlan_pr skb_vlan_tag_present(skb) >>> rand prandom_u32() >>> + vlan_proto skb->vlan_proto >> >> the patch is correct and looks clean, but I don't understand >> the motivation for the patch. >> There is already SKF_AD_VLAN_TAG_PRESENT. If it is set then only >> two possible values of vlan_proto are ETH_P_8021Q or ETH_P_8021AD. >> If there another vlan header inside the packet, it's AD. > > 802.1ad can be used without an inner vlan tag. > Also, we can send/receive QinQ frames with 802.1Q outer tags. > (We can create vlan interface on 802.1Q vlan interface.) yes, but I think existing 'vlan_tag_present' would be enough to address the issue mentioned in two bugs reports.