Hi Sasha
> 1) How do we get access to the __data_loc field? (I can fetch the same
info from skb->dev->name but if there's a way to work with the __data_loc
field directly, it's even better.)
It is a dynamic array in kernel, the size can't be determined during
compiling time. At run time, kernel will calculate the size of dynamic
array, and reserve the space for that trace event entry(call
trace_event_buffer_reserve). The following kernel code can help you decode
__data_loc.
Lower 16bit is the offset against the beginning of the event entry.
Higher 16bit is the length of the array.
Kernel using __get_str to access the field, e.g. when you cat "trace_pipe".
it will print dev name.
#undef __get_dynamic_array
#define __get_dynamic_array(field) \
((void *)__entry + (__entry->__data_loc_##field & 0xffff))
#undef __get_dynamic_array_len
#define __get_dynamic_array_len(field) \
((__entry->__data_loc_##field >> 16) & 0xffff)
#undef __get_str
#define __get_str(field) ((char *)__get_dynamic_array(field))
You can get the skb->dev->name from __data_loc, as long as BPF copied
whole entry buffer to userspace. I haven't try it on user space code yet.
But it should works. :)
> 2) Do we need to fix the structure generation in tp_frontend_action to
explicitly take the field offsets into account, or to at least place a
dummy int whenever we see a __data_loc field? It looks like we might be
generating the right offsets by accident.
IMO, maybe we can generate some thing as same as kernel. e.g.
struct tracepoint__net__net_dev_start_xmit {
....
int data_loc_name;
...
};
Plus something similar with above __get_dynamic_array_len,
__get_dynamic_array.
Regards
Derek
On Tue, Jan 31, 2017 at 4:19 AM, Sasha Goldshtein via iovisor-dev <
[email protected]> wrote:
> Hi all,
>
> I'm trying to attach a BPF program to a tracepoint that has a __string
> field, such as net:net_dev_start_xmit. This tracepoint has the following
> format (from debugfs/events/.../format):
>
> name: net_dev_start_xmit
> ID: 1159
> format:
> field:unsigned short common_type; offset:0; size:2; signed:0;
> field:unsigned char common_flags; offset:2; size:1; signed:0;
> field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
> field:int common_pid; offset:4; size:4; signed:1;
> field:__data_loc char[] name; offset:8; size:4; signed:1;
> field:u16 queue_mapping; offset:12; size:2; signed:0;
> field:const void * skbaddr; offset:16; size:8; signed:0;
> field:bool vlan_tagged; offset:24; size:1; signed:0;
> ... many more fields omitted for brevity
>
> When enabling this tracepoint through ftrace, the trace pipe contains the
> dev name in the name field -- which is great. Looking at the layout, it
> seems odd that a char[] field would have size 4 (it is a pointer after
> all). So I assume it's not just a plain pointer, and this __data_loc thing
> means something. What does it mean? :)
>
> Our current code in tp_frontend_action.cc explicitly ignores __data_loc
> fields, which should supposedly affect the tracepoint entry layout. BTW, we
> also ignore the offset directives in the tracepoint format structure. This
> is the tracepoint entry structure that we end up generating:
>
> struct tracepoint__net__net_dev_start_xmit {
> u64 __do_not_use__;
> u16 queue_mapping;
> const void * skbaddr;
> bool vlan_tagged;
> /* many more fields omitted for brevity */
> };
>
> Looking at this structure declaration, the skbaddr field will be at offset
> 16 by pure chance (and the queue_mapping field will be at offset 8, which
> is where the 'name' field is). In general, it looks like we are assuming
> that our compiler is using the same default alignment logic as the kernel
> when it generates the tracepoint entry structure.
>
> So, my questions:
>
> 1) How do we get access to the __data_loc field? (I can fetch the same
> info from skb->dev->name but if there's a way to work with the __data_loc
> field directly, it's even better.)
>
> 2) Do we need to fix the structure generation in tp_frontend_action to
> explicitly take the field offsets into account, or to at least place a
> dummy int whenever we see a __data_loc field? It looks like we might be
> generating the right offsets by accident.
>
> Thanks,
> Sasha
>
>
> _______________________________________________
> iovisor-dev mailing list
> [email protected]
> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>
>
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
