From: Alexei Starovoitov <ast@plumgrid.com>
To: David Miller <davem@davemloft.net>
Cc: daniel@iogearbox.net, tgraf@suug.ch, jiri@resnulli.us,
jhs@mojatatu.com, netdev@vger.kernel.org
Subject: Re: [PATCH v3 net-next 2/2] tc: add 'needs_l2' flag to ingress qdisc
Date: Wed, 08 Apr 2015 20:05:13 -0700 [thread overview]
Message-ID: <5525EC69.1080606@plumgrid.com> (raw)
In-Reply-To: <20150408.224404.1913719826015357860.davem@davemloft.net>
On 4/8/15 7:44 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@plumgrid.com>
> Date: Wed, 8 Apr 2015 16:26:15 -0700
>
>> index 4cd5cf1aedf8..887033fbdfa6 100644
>> --- a/net/sched/act_csum.c
>> +++ b/net/sched/act_csum.c
>> @@ -565,6 +565,8 @@ static struct tc_action_ops act_csum_ops = {
>> .act = tcf_csum,
>> .dump = tcf_csum_dump,
>> .init = tcf_csum_init,
>> + /* todo: fix pskb_may_pull in tcf_csum to not assume L2 */
>> + .flags = TCA_NEEDS_L2,
>> };
>>
>> MODULE_DESCRIPTION("Checksum updating actions");
>
>
> All this module really cares about is where skb_network_header() is
> for data accesses. And a simple offset would allow it to calculate
> the pskb_may_pull() length argument correctly.
>
> And it would therefore work without all of these expensive SKB share
> check calls etc.
yes. act_csum can be fixed. I mentioned that in the commit log.
I can drop markings for anything other than cls_bpf/act_bpf if you like?
> I really don't like your approach, and I'd rather you propagate the
> offset into the BPF programs you generate. I bet you can do it in
> an efficient way, and just haven't put in the effort to discover
> how.
I'm sure there is a way to propagate the offset into the programs.
It's not about efficiency of programs, but about consistency.
Programs should know nothing about kernel. Sending network offset
into them is exposing this very specific kernel behavior.
As soon as we do that all programs need to be written with this
offset in mind, so they can work with ingress and egress. It would
also break sockex1_kern.c, sockex2_kern.c and all other bpf programs.
That's not acceptable to me.
As I said I'd rather disable them attaching to ingress than force
all program authors to always use network_offset.
Offset 0 points to L2 was always fundamental assumption of BPF.
Both in classic and now carried over into extended.
We cannot change that.
We can cheat and say 'bpf for ingress' has to use new rules, but
that's just wrong. Imagine documenting it everywhere and all
confusion it will cause.
I still don't understand why you don't like it.
bridge is doing skb_share_check and that's acceptable there.
What's wrong with doing it for ingress here under flag?
Will 'early_ingress_l2' hook and flag be better?
Like adding:
skb = early_handle_ing(skb, &pt_prev, &ret, orig_dev);
right before taps in __netif_receive_skb_core ?
This way we can safely push/pull without share check.
next prev parent reply other threads:[~2015-04-09 3:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 23:26 [PATCH v3 net-next 1/2] net: introduce skb_postpush_rcsum() helper Alexei Starovoitov
2015-04-08 23:26 ` [PATCH v3 net-next 2/2] tc: add 'needs_l2' flag to ingress qdisc Alexei Starovoitov
2015-04-09 2:44 ` David Miller
2015-04-09 3:05 ` Alexei Starovoitov [this message]
2015-04-09 3:14 ` David Miller
2015-04-09 3:39 ` Alexei Starovoitov
2015-04-09 5:20 ` Alexei Starovoitov
2015-04-09 5:25 ` David Miller
2015-04-09 15:15 ` Daniel Borkmann
2015-04-09 15:36 ` Eric Dumazet
2015-04-09 17:20 ` Alexei Starovoitov
2015-04-09 10:49 ` Jamal Hadi Salim
2015-04-09 11:02 ` Jamal Hadi Salim
2015-04-09 15:38 ` Daniel Borkmann
2015-04-10 11:49 ` Jamal Hadi Salim
2015-04-09 17:03 ` Alexei Starovoitov
2015-04-10 12:48 ` Jamal Hadi Salim
2015-04-10 22:35 ` Alexei Starovoitov
2015-04-13 14:28 ` Jamal Hadi Salim
2015-04-13 16:13 ` Alexei Starovoitov
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=5525EC69.1080606@plumgrid.com \
--to=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/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).