From: Daniel Borkmann <dborkman@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Chema Gonzalez <chema@google.com>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, ast@plumgrid.com
Subject: Re: [PATCH] filter: added BPF random opcode
Date: Tue, 15 Apr 2014 17:04:18 +0200 [thread overview]
Message-ID: <534D4A72.2010909@redhat.com> (raw)
In-Reply-To: <1397572894.4222.98.camel@edumazet-glaptop2.roam.corp.google.com>
On 04/15/2014 04:41 PM, Eric Dumazet wrote:
> On Tue, 2014-04-15 at 09:24 +0200, Daniel Borkmann wrote:
>
>>> @@ -773,6 +779,7 @@ static bool convert_bpf_extensions(struct sock_filter *fp,
>>> case SKF_AD_OFF + SKF_AD_NLATTR:
>>> case SKF_AD_OFF + SKF_AD_NLATTR_NEST:
>>> case SKF_AD_OFF + SKF_AD_CPU:
>>> + case SKF_AD_OFF + SKF_AD_RANDOM:
>>
>> I think instead of a function call, this sould rather be modelled
>> directly into the internal insn set and thus converted differently,
>> so we can spare us the call.
>
> Hmmm... this would need percpu storage, thus preempt disable/enable
> calls, and prandom_u32_state() is about 40 instructions.
>
> This is really not worth the pain.
Absolutely, that was not what I meant actually. Calling to
prandom_u32_state() is fine, no need to have another prng just
for that. I was just wondering if it makes sense to model that
directly as an instruction into a jump-table target that calls
prandom_u32() from there instead 'indirectly'. Need to think
about this a bit more ...
next prev parent reply other threads:[~2014-04-15 15:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 23:02 [PATCH] filter: added BPF random opcode Chema Gonzalez
2014-04-15 7:24 ` Daniel Borkmann
2014-04-15 14:41 ` Eric Dumazet
2014-04-15 15:04 ` Daniel Borkmann [this message]
2014-04-15 16:22 ` Chema Gonzalez
2014-04-15 16:30 ` Chema Gonzalez
2014-04-15 16:44 ` Daniel Borkmann
2014-04-15 18:19 ` Chema Gonzalez
-- strict thread matches above, loose matches on Subject: below --
2014-04-15 18:16 Chema Gonzalez
2014-04-16 6:24 ` Alexei Starovoitov
2014-04-16 8:32 ` Daniel Borkmann
2014-04-17 0:19 ` Chema Gonzalez
2014-04-17 1:38 ` Eric Dumazet
2014-04-18 20:21 ` 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=534D4A72.2010909@redhat.com \
--to=dborkman@redhat.com \
--cc=ast@plumgrid.com \
--cc=chema@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.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 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.