From: Alexei Starovoitov <ast@plumgrid.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: Guy Harris <guy@alum.mit.edu>,
Michal Sekletar <msekleta@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] filter: introduce SKF_AD_VLAN_PROTO BPF extension
Date: Wed, 04 Mar 2015 23:23:25 -0800 [thread overview]
Message-ID: <54F8046D.6070807@plumgrid.com> (raw)
In-Reply-To: <20150305065053.GA2062@nanopsycho.orion>
On 3/4/15 10:50 PM, Jiri Pirko wrote:
> Thu, Mar 05, 2015 at 12:47:06AM CET, ast@plumgrid.com wrote:
>> On 3/4/15 1:14 PM, Guy Harris wrote:
>>>
>>> On Mar 4, 2015, at 1:03 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
>>>
>>>> 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.
>>>> So you can do the filtering already without adding new bpf extension...
>>>
>>> I presume he's referring to
>>>
>>> https://github.com/the-tcpdump-group/libpcap/issues/397
>>>
>>> or
>>>
>>> https://github.com/the-tcpdump-group/libpcap/issues/390
>>
>> ok. context is clear.
>> yet, it still sounds like something to fix inside libpcap.
>
> Libpcap need to somehow let kernel now what vlan proto it should filter on.
I don't think that's what bug report talking about. It's looking to
match on vlan id regardless of vlan_proto. Only vlan_tag_present is
needed to make it work.
> Also, it is not true that another vlan header inside packet is AD. You
> can have packet with just AD header (or 2 AD or 2 Q, etc).
yes. Correct, but then again it doesn't seem to be the goal of the bug
report.
To make myself clear. I think the patch is ok, I'm only asking for
clear justification based on real use case and not invented one.
next prev parent reply other threads:[~2015-03-05 7:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 20:41 [PATCH] filter: introduce SKF_AD_VLAN_PROTO BPF extension Michal Sekletar
2015-03-04 21:03 ` Alexei Starovoitov
2015-03-04 21:14 ` Guy Harris
2015-03-04 23:47 ` Alexei Starovoitov
2015-03-05 6:50 ` Jiri Pirko
2015-03-05 7:23 ` Alexei Starovoitov [this message]
2015-03-05 7:24 ` Michal Kubecek
2015-03-05 7:49 ` Alexei Starovoitov
2015-03-05 8:35 ` Guy Harris
2015-03-05 9:23 ` Michal Kubecek
2015-03-05 2:28 ` Toshiaki Makita
2015-03-05 2:41 ` Alexei Starovoitov
2015-03-05 10:37 ` Michal Sekletar
2015-03-05 16:52 ` Alexei Starovoitov
2015-03-05 20:03 ` Daniel Borkmann
2015-03-05 20:40 ` Alexei Starovoitov
2015-03-06 8:09 ` Michal Sekletar
2015-03-06 9:04 ` Michal Sekletar
2015-03-06 17:23 ` Daniel Borkmann
2015-03-06 14:02 ` Michal Kubecek
2015-03-06 17:54 ` Daniel Borkmann
2015-03-05 8:52 ` Jiri Pirko
2015-03-05 8:57 ` Denis Kirjanov
2015-03-05 14:33 ` Michal Sekletar
2015-03-05 18:12 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F8046D.6070807@plumgrid.com \
--to=ast@plumgrid.com \
--cc=guy@alum.mit.edu \
--cc=jpirko@redhat.com \
--cc=msekleta@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).