All of lore.kernel.org
 help / color / mirror / Atom feed
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 ...

  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.