From: Li Yu <raise.sail@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: netdev@vger.kernel.org, eric.dumazet@gmail.com,
davem@davemloft.net, bhutchings@solarflare.com,
shemminger@vyatta.com
Subject: Re: [Q/RFC] BPF use in broader scope
Date: Thu, 29 Mar 2012 17:49:18 +0800 [thread overview]
Message-ID: <4F74301E.9020702@gmail.com> (raw)
In-Reply-To: <20120329074443.GB2098@minipsycho>
于 2012年03月29日 15:44, Jiri Pirko 写道:
> Hi all.
>
> I came to an idea of using BPF infrastructure currently used in kernel,
> for computing hashes selecting TX ports in team device. Since the same
> data (skb) are alalyzed/used as for socket filtering, BPF seems so be quite
> suitable for this. It would allow userspace daemon to specify various
> kinds of TX selection algorithms.
>
> Here are proposed things to be done:
> 1) introduce in-kernel api for creating sk-unattached filters (I have
> the patch cooked up already)
>
> 2) extend current BPF machine to allow XOR operation. Not sure if this
> is doable or what the best of doing this is.
>
> 3) add possibility to pass some data to the machine via
> pre-filling "Scratch Memory Store". I think this can be done easily
> moving "u32 mem[BPF_MEMWORDS];" to bpf_func caller and pass it as the
> second function parameter. That should not break anything.
>
> Then the computed hash can be either stored into Scratch memory or returned
> directly (where ordinary sk filters return len).
>
> Does this seems reasonable? Thoughts, comments?
>
Very interesting.
I am working on a blktrace like utility for networking subsystem. It
needs a trace events filter to avoid to generate too much results which
user does not interesting, it seem that the generic BPF is the best
choice here.
So far, the "skbtrace" need to filter two kinds of objects: the skb and
socket, so I think that above "Scratch Memory Store" is necessary indeed.
Thanks.
Yu
> Thanks!
>
> Jirka
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-03-29 9:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-29 7:44 [Q/RFC] BPF use in broader scope Jiri Pirko
2012-03-29 7:49 ` David Miller
2012-03-29 7:54 ` Jiri Pirko
2012-03-29 8:02 ` Eric Dumazet
2012-03-29 8:31 ` Jiri Pirko
2012-03-29 8:43 ` David Miller
2012-03-29 8:45 ` Eric Dumazet
2012-03-29 9:31 ` Jiri Pirko
2012-05-11 2:41 ` Li Yu
2012-05-11 6:22 ` Jiri Pirko
2012-05-11 7:06 ` Li Yu
2012-05-11 8:45 ` Jiri Pirko
2012-03-29 7:58 ` Eric Dumazet
2012-03-29 9:49 ` Li Yu [this message]
2012-03-29 14:04 ` Nuno Martins
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=4F74301E.9020702@gmail.com \
--to=raise.sail@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jpirko@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).