From: Daniel Borkmann <daniel@iogearbox.net>
To: Jamal Hadi Salim <jhs@mojatatu.com>,
Alexei Starovoitov <ast@plumgrid.com>
Cc: David Miller <davem@davemloft.net>,
jiri@resnulli.us, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] tc: fix tc actions in case of shared skb
Date: Tue, 14 Jul 2015 14:19:34 +0200 [thread overview]
Message-ID: <55A4FE56.90605@iogearbox.net> (raw)
In-Reply-To: <55A4F92E.1020908@mojatatu.com>
On 07/14/2015 01:57 PM, Jamal Hadi Salim wrote:
> On 07/14/15 06:29, Daniel Borkmann wrote:
>> On 07/14/2015 12:26 AM, Alexei Starovoitov wrote:
>>> On 7/13/15 1:55 PM, Daniel Borkmann wrote:
>>>> On 07/13/2015 10:17 PM, Alexei Starovoitov wrote:
>>>> ...
>>>>> We cannot check tc actions from pktgen, since they can be added
>>>>> dynamically.
>>>>> So I see three options:
>>>>> 1 get rid of burst hack for both RX and TX in pktgen (kills
>>>>> performance)
>>>>> 2 add unlikely(skb_shread) check to few tc actions
>>>>> 3 do nothing
>>> ...
>>>> pktgen case. :/ With regards to option 2, you could hide that behind
>>>> a static inline helper wrapped in IS_ENABLED(CONFIG_NET_PKTGEN), but
>>>> that is a veeeery ugly workaround/hack as well (and distros might
>>>> even ship it nevertheless).
>>>
>>> naming such helper is a headache as well.
>>> static inline bool is_pktgen_shared_skb(struct sk_buff *skb)
>>> {
>>> #if IS_ENABLED(CONFIG_NET_PKTGEN)
>>> /* pktgen uses skb->users += burst trick to reuse skb */
>>> return skb_shared(skb);
>>> #else
>>> return false;
>>> #endif
>>> }
>>> and in actions:
>>> if (unlikely(is_pktgen_shared_skb(skb))) goto drop;
>>>
>>> thoughts?
>>
>> As I mentioned above, so Fedora, for example, ships pktgen by default.
>> That means, we'd run into the above test for shared skb in every case,
>> meaning it won't help much and it's also a pretty nasty hack. ;)
>>
>> One other thing that comes to mind, not sure if it's worth it though,
>> would be to split the skb->tc_verd's TC_NCLS itself into TC_NCLS/TC_NACT,
>> so that you can go into the classifier, but skip the action part.
>>
>> Since in tcf_action_exec(), we already test for that, you might be able
>> to add this with no extra cost. pktgen would then need to tag its skb
>> with TC_NACT, so that you'll always return with TC_ACT_OK. And if you
>> really would want to test tc actions, then w/o pktgen bursting ...
>
> Would just a simple skb->mark not work? Drop if skb->mark = x
> using skbedit. Or a brand new pktgen_burst_mode action that drops?
I think it's more about the fact that something could BUG() when used with
pktgen, otherwise you could just generally drop after classification.
next prev parent reply other threads:[~2015-07-14 12:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 0:10 [PATCH net-next] tc: fix tc actions in case of shared skb Alexei Starovoitov
2015-07-12 4:29 ` David Miller
2015-07-13 19:47 ` Alexei Starovoitov
2015-07-13 20:04 ` David Miller
2015-07-13 20:17 ` Alexei Starovoitov
2015-07-13 20:55 ` Daniel Borkmann
2015-07-13 22:26 ` Alexei Starovoitov
2015-07-14 10:29 ` Daniel Borkmann
2015-07-14 11:57 ` Jamal Hadi Salim
2015-07-14 12:19 ` Daniel Borkmann [this message]
2015-07-14 15:46 ` Alexei Starovoitov
2015-07-14 22:34 ` David Miller
2015-07-14 23:08 ` Alexei Starovoitov
2015-07-15 0:58 ` John Fastabend
2015-07-15 1:01 ` Alexei Starovoitov
2015-07-13 13:13 ` Jamal Hadi Salim
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=55A4FE56.90605@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@plumgrid.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--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 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.