All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chema Gonzalez <chema@google.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.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 09:22:23 -0700	[thread overview]
Message-ID: <CA+ZOOTNMHBsGzdwk=3k1==EVvV8Ge-EPxmFLNyHvdke=1QSPzg@mail.gmail.com> (raw)
In-Reply-To: <534D4A72.2010909@redhat.com>

On Tue, Apr 15, 2014 at 8:04 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> 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 ...
I thought about that. In fact, the original patch (written for
FreeBSD) worked by extending the ISA with a new load mode that did "A
= random();". After seeing your eBPF work, I got convinced that we
want to get a generic ISA when possible, where random is typically not
an insn. Also, the bpf_call approach makes it much easier to integrate
with the different JITs.

-Chema

  reply	other threads:[~2014-04-15 16:22 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
2014-04-15 16:22       ` Chema Gonzalez [this message]
2014-04-15 16:30   ` Chema Gonzalez
2014-04-15 16:44     ` Daniel Borkmann
2014-04-15 18:19       ` Chema Gonzalez
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='CA+ZOOTNMHBsGzdwk=3k1==EVvV8Ge-EPxmFLNyHvdke=1QSPzg@mail.gmail.com' \
    --to=chema@google.com \
    --cc=ast@plumgrid.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --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.