On Mon, 9 Feb 2015 21:47:42 -0800
Alexei Starovoitov wrote:
> On Mon, Feb 9, 2015 at 9:45 PM, Alexei Starovoitov wrote:
> > I thought we already stated that.
> > Here is the quote from perf_event.h:
> > * # The RAW record below is opaque data wrt the ABI
> > * #
> >
Added Linus because he's the one that would revert changes on breakage.
On Mon, 9 Feb 2015 21:45:21 -0800
Alexei Starovoitov wrote:
> On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt wrote:
> > On Mon, 9 Feb 2015 23:08:36 -0500
> > Steven Rostedt wrote:
> >
> >> I don't want to get stuck with
Added Linus because he's the one that would revert changes on breakage.
On Mon, 9 Feb 2015 21:45:21 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Feb 2015 23:08:36 -0500
Steven Rostedt
On Mon, 9 Feb 2015 21:47:42 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Feb 9, 2015 at 9:45 PM, Alexei Starovoitov a...@plumgrid.com wrote:
I thought we already stated that.
Here is the quote from perf_event.h:
* # The RAW record below is opaque data wrt the ABI
On Mon, Feb 9, 2015 at 9:45 PM, Alexei Starovoitov wrote:
> I thought we already stated that.
> Here is the quote from perf_event.h:
> * # The RAW record below is opaque data wrt the ABI
> * #
> * # That is, the ABI doesn't make any promises wrt to
>
On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt wrote:
> On Mon, 9 Feb 2015 23:08:36 -0500
> Steven Rostedt wrote:
>
>> I don't want to get stuck with pinned kernel data structures again. We
>> had 4 blank bytes of data for every event, because latency top hard
>> coded the field. Luckily, the 64
On Mon, 9 Feb 2015 23:08:36 -0500
Steven Rostedt wrote:
> I don't want to get stuck with pinned kernel data structures again. We
> had 4 blank bytes of data for every event, because latency top hard
> coded the field. Luckily, the 64 bit / 32 bit interface caused latency
> top to have to use
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov wrote:
> +static void print_netif_receive_skb(void *data, int size)
> +{
> + struct ftrace_raw_netif_receive_skb {
> + struct trace_entry t;
> + void *skb;
> + __u32 len;
> + __u32 name;
> +
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov wrote:
> +int perf_event_mmap(int fd);
> +int perf_event_poll(int fd);
> +typedef void (*print_fn)(void *data, int size);
> +void perf_event_read(print_fn fn);
> +struct trace_entry {
> + unsigned short type;
> + unsigned
tracex1_kern.c - C program which will be compiled into eBPF
to filter netif_receive_skb events on skb->dev->name == "lo"
The programs returns 1 to store an event into ring_buffer
and returns 0 - to discard an event.
tracex1_user.c - corresponding user space component that:
- loads bpf program via
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
+int perf_event_mmap(int fd);
+int perf_event_poll(int fd);
+typedef void (*print_fn)(void *data, int size);
+void perf_event_read(print_fn fn);
+struct trace_entry {
+ unsigned short type;
+
tracex1_kern.c - C program which will be compiled into eBPF
to filter netif_receive_skb events on skb-dev-name == lo
The programs returns 1 to store an event into ring_buffer
and returns 0 - to discard an event.
tracex1_user.c - corresponding user space component that:
- loads bpf program via
On Mon, 9 Feb 2015 19:45:57 -0800
Alexei Starovoitov a...@plumgrid.com wrote:
+static void print_netif_receive_skb(void *data, int size)
+{
+ struct ftrace_raw_netif_receive_skb {
+ struct trace_entry t;
+ void *skb;
+ __u32 len;
+ __u32
On Mon, Feb 9, 2015 at 9:45 PM, Alexei Starovoitov a...@plumgrid.com wrote:
I thought we already stated that.
Here is the quote from perf_event.h:
* # The RAW record below is opaque data wrt the ABI
* #
* # That is, the ABI doesn't make any promises
On Mon, Feb 9, 2015 at 9:16 PM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 9 Feb 2015 23:08:36 -0500
Steven Rostedt rost...@goodmis.org wrote:
I don't want to get stuck with pinned kernel data structures again. We
had 4 blank bytes of data for every event, because latency top hard
On Mon, 9 Feb 2015 23:08:36 -0500
Steven Rostedt rost...@goodmis.org wrote:
I don't want to get stuck with pinned kernel data structures again. We
had 4 blank bytes of data for every event, because latency top hard
coded the field. Luckily, the 64 bit / 32 bit interface caused latency
top to
16 matches
Mail list logo
