From: Alexei Starovoitov <ast@plumgrid.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>, David Miller <davem@davemloft.net>
Cc: daniel@iogearbox.net, tgraf@suug.ch, jiri@resnulli.us,
netdev@vger.kernel.org
Subject: Re: [PATCH v3 net-next 2/2] tc: add 'needs_l2' flag to ingress qdisc
Date: Thu, 09 Apr 2015 10:03:28 -0700 [thread overview]
Message-ID: <5526B0E0.7060000@plumgrid.com> (raw)
In-Reply-To: <5526593E.4040608@mojatatu.com>
On 4/9/15 3:49 AM, Jamal Hadi Salim wrote:
> those devices and only speacial case with them. Your assumptions of
> blindly pushing/pulling will break in some cases (take a look at
> mirred).
you underestimated how much time I've spent studying mirred ;)
In particular my v2 patch fixes two bugs in it:
- it was forwarding packets with L2 present to tunnel devices if used
with egress qdisc
- it wasn't updating skb->csum with ingress qdisc
In v3 since 'needs_l2' is an optional flag, I didn't touch mirred
and left its bugs for the future patches.
> Your changes penalize everyone else because of this assumption
> bpf makes. We have always tried to be sensitive to perfomance.
hmm. penalize everyone? it's an optional flag.
If ingress_l2 is used with cls_bpf plus some other classifier,
sure, the other classifier is paying potential cost skb_share_check
if taps are active. The chances of having more than a couple classifiers
on a single device are very slim, since they're called sequentially
and killing performance regardless.
In most of the use cases I'm after, cls_bpf will be the only classifier
attached. In some cases there may be few others, but cls_bpf will be
the first and the heaviest one. So it makes sense to optimize for it.
> code path and you are adding a bunch more unconditionally.
not true at all. Looks like you misread the v3 patch completely.
It's an optional flag.
next prev parent reply other threads:[~2015-04-09 17:03 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
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 [this message]
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=5526B0E0.7060000@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 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.