From: Alexei Starovoitov <ast@plumgrid.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Michal Sekletar <msekleta@redhat.com>
Cc: netdev@vger.kernel.org, Jiri Pirko <jpirko@redhat.com>,
Ralf Baechle <ralf@linux-mips.org>,
Russell King <linux@arm.linux.org.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v2] filter: introduce SKF_AD_VLAN_TPID BPF extension
Date: Sat, 21 Mar 2015 08:41:17 -0700 [thread overview]
Message-ID: <550D911D.9070604@plumgrid.com> (raw)
In-Reply-To: <550D3EBF.4000907@iogearbox.net>
On 3/21/15 2:49 AM, Daniel Borkmann wrote:
> On 03/21/2015 03:23 AM, Alexei Starovoitov wrote:
>> On 3/20/15 3:27 AM, Michal Sekletar wrote:
>>> On Thu, Mar 19, 2015 at 09:08:35AM -0700, Alexei Starovoitov wrote:
>>>> Since it's a new field, I think it makes sense not to do ntohs at all.
>>>> Let bpf programs do htons(PROTO_CONSTANT), since it can be done at
>>>> compile time instead of run-time.
>>>
>>> Doing htons is not needed for vlan_tci thus I wanted to avoid
>>> surprise for
>>> users. But of course I'll do whatever you think is the best.
>>
>> ok. then let's not add ntohs for vlan_tpid
>
> Why? What speaks against handling this the exact same way as we
> do now with skb->protocol?
hmm. I think you miss read it. It's exactly the same way as
skb->protocol for extended. No point doing it differently for classic.
next prev parent reply other threads:[~2015-03-21 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 11:10 [PATCH net-next v2] filter: introduce SKF_AD_VLAN_TPID BPF extension Michal Sekletar
2015-03-19 16:08 ` Alexei Starovoitov
2015-03-20 10:27 ` Michal Sekletar
2015-03-21 2:23 ` Alexei Starovoitov
2015-03-21 9:49 ` Daniel Borkmann
2015-03-21 15:41 ` Alexei Starovoitov [this message]
2015-03-19 17:45 ` Denis Kirjanov
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=550D911D.9070604@plumgrid.com \
--to=ast@plumgrid.com \
--cc=benh@kernel.crashing.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jpirko@redhat.com \
--cc=linux@arm.linux.org.uk \
--cc=msekleta@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=schwidefsky@de.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.