All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@plumgrid.com>
To: Tom Herbert <tom@herbertland.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Cc: "David S. Miller" <davem@davemloft.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] ebpf: add skb->hash to offset map for usage in {cls,act}_bpf or filters
Date: Sun, 2 Aug 2015 23:16:12 -0700	[thread overview]
Message-ID: <55BF072C.3000302@plumgrid.com> (raw)
In-Reply-To: <CALx6S35Xw-14Z8=w2cg7dFFzfkEmkjuqU=37uG3Tb-OoW2JEoA@mail.gmail.com>

On 8/2/15 6:09 PM, Tom Herbert wrote:
>> I was thinking whether to add skb_get_hash(), but then concluded the
>> >raw skb->hash seems fine in this case: we can directly access the hash
>> >w/o extra eBPF helper function call, it's filled out by many NICs on
>> >ingress, and in case the entropy level would not be sufficient, people
>> >can still implement their own specific sw fallback hash mix anyway.
>> >
> Maybe we should add the skb_get_hash also? It doesn't as useful if
> some scenarios we get a valid hash and in others not.

we also discussed whether it makes sense to expose l4_hash and sw_hash
bits as well. imo, seems a bit of overkill, since such call into sw hash
function like this exposes the logic of flow_dissector looking into
inner header. There are pros and cons. I think if we expose
flow_dissector it's cleaner to do it directly (instead of skb_get_hash).
Alternatively we can obfuscate skb_get_hash by calling it
'please compute some a hash on a packet somehow', but that will be
awkward to use. The programs can compute whatever hash they like anyway.

  reply	other threads:[~2015-08-03  6:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 22:46 [PATCH net-next] ebpf: add skb->hash to offset map for usage in {cls,act}_bpf or filters Daniel Borkmann
2015-08-03  0:21 ` David Miller
2015-08-03  1:09 ` Tom Herbert
2015-08-03  6:16   ` Alexei Starovoitov [this message]
2015-08-03 12:49     ` Daniel Borkmann

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=55BF072C.3000302@plumgrid.com \
    --to=ast@plumgrid.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    /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.