Thanks a lot,
Now I want to convert elog file to text file.
I compiled perftools in test directory, but when running c2cpel tools, the
following error accrued:
c2cpel: error while loading shared libraries: libcperf.so.0: cannot open
shared object file: No such file or directory
Best Regards,
Juan Salmon.
On Wed, Nov 29, 2017 at 3:53 PM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:
> PMFJI, but we have organized schemes for capturing, serializing, and
> eventually displaying string data.
>
>
>
> Please note: a single "format" call will probably cost more than *the
> entire clock-cycle budget* available to process a packet. Really.
> Seriously. Printfs (aka format calls) in the packet-processing path are to
> be avoided at all costs. The basic event-logger modus operandi is to
> capture binary data and pretty-print it offline.
>
>
>
> At times, one will need or want to log string data. Here's how to proceed:
>
>
>
> The printf-like function elog_string(...) adds a string to the event log
> string heap, and returns a cookie which offline tools use to print that
> string. The "T" format specifier in an event definition means "go print the
> string at the indicated u32 string heap offset”. Here’s an example:
>
>
>
> /* *INDENT-OFF* */
>
> ELOG_TYPE_DECLARE (e) =
>
> {
>
> .format = "serialize-msg: %s index %d",
>
> .format_args = "T4i4",
>
> };
>
> struct
>
> {
>
> u32 c[2];
>
> } *ed;
>
> ed = ELOG_DATA (mc->elog_main, e);
>
> ed->c[0] = elog_id_for_msg_name (mc, msg->name);
>
> ed->c[1] = si;
>
>
>
> So far so good, but let’s do a bit of work to keep from blowing up the
> string heap:
>
>
>
> static u32
>
> elog_id_for_msg_name (mc_main_t * m, char *msg_name)
>
> {
>
> uword *p, r;
>
> uword *h = m->elog_id_by_msg_name;
>
> u8 *name_copy;
>
>
>
> if (!h)
>
> h = m->elog_id_by_msg_name = hash_create_string (0, sizeof (uword));
>
>
>
> p = hash_get_mem (h, msg_name);
>
> if (p)
>
> return p[0];
>
> r = elog_string (m->elog_main, "%s", msg_name);
>
>
>
> name_copy = format (0, "%s%c", msg_name, 0);
>
>
>
> hash_set_mem (h, name_copy, r);
>
> m->elog_id_by_msg_name = h;
>
>
>
> return r;
>
> }
>
>
>
> As in: each unique string appears exactly once in the event-log string
> heap. Hash_get_mem (x) is way cheaper than printf(x). Please remember that
> this hash flavor is not inherently thread-safe.
>
>
>
> In the case of enumerated strings, use the “t” format specifier. It only
> costs 1 octet to represent up to 256 constant strings:
>
>
>
> ELOG_TYPE_DECLARE (e) =
>
> {
>
> .format = "my enum: %s",
>
> .format_args = "t1",
>
> .n_enum_strings =
>
> 2,
>
> .enum_strings =
>
> {
>
> "string 1",
>
> "string 2",
>
> },
>
> };
>
> struct
>
> {
>
> u8 which;
>
> } *ed;
>
> ed = ELOG_DATA (&vlib_global_main.elog_main, e);
>
> ed->which = which;
>
>
>
>
>
> HTH… Dave
>
>
>
> -----Original Message-----
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Florin Coras
> Sent: Wednesday, November 29, 2017 4:43 AM
> To: Juan Salmon <salmonju...@gmail.com>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] problem in elog format
>
>
>
> Hi Juan,
>
>
>
> We don’t typically use elogs to store strings, still, you may be able to
> get it to run with:
>
>
>
> struct
>
> {
>
> u8 err[20];
>
> } * ed;
>
>
>
> And then copy your data to err: clib_memcpy (ed->err, your_vec, vec_len
> (your_vec)). Make sure your vec is 0 terminated.
>
>
>
> HTH,
>
> Florin
>
>
>
> > On Nov 28, 2017, at 9:12 PM, Juan Salmon <salmonju...@gmail.com> wrote:
>
> >
>
> >
>
> > I want to use event-log and send string to one of elements of ed struct.
>
> > but the result is not correct.
>
> >
>
> > the sample code:
>
> >
>
> > ELOG_TYPE_DECLARE (e) = {
>
> > .format = "Test LOG: %s",
>
> > .format_args = "s20",
>
> > };
>
> > struct
>
> > {
>
> > u8 * err;
>
> > } * ed;
>
> >
>
> >
>
> > vlib_worker_thread_t * w = vlib_worker_threads + cpu_index;
>
> > ed = ELOG_TRACK_DATA (&vlib_global_main.elog_main, e,
> w->elog_track);
>
> >
>
> > ed->err = format (0,"%s", "This is a Test");
>
> >
>
> >
>
> > Could you please help me?
>
> >
>
> >
>
> > Best Regards,
>
> > Juan Salmon.
>
> > _______________________________________________
>
> > vpp-dev mailing list
>
> > vpp-dev@lists.fd.io
>
> > https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
> _______________________________________________
>
> vpp-dev mailing list
>
> vpp-dev@lists.fd.io
>
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
