RE: [RDMA for-next V3 1/6] IB/MAD: Add send path trace points

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > +	TP_PROTO(struct ib_mad_send_wr_private *wr, struct
> > rdma_mad_trace_addr *addr),
> > > +	TP_ARGS(wr, addr),
> > > +
> > > +	TP_STRUCT__entry(
> > > +		__field(u8,             base_version)
> > > +		__field(u8,             mgmt_class)
> > > +		__field(u8,             class_version)
> > > +		__field(u8,             port_num)
> > > +		__field(u32,            qp_num)
> > > +		__field(u8,             method)
> > > +		__field(u8,             sl)
> > > +		__field(u16,            attr_id)
> > > +		__field(u32,            attr_mod)
> > > +		__field(u64,            wrtid)
> > > +		__field(u64,            tid)
> > > +		__field(u16,            status)
> > > +		__field(u16,            class_specific)
> > > +		__field(u32,            length)
> > > +		__field(u32,            dlid)
> > > +		__field(u32,            rqpn)
> > > +		__string(dev_name,      wr->mad_agent_priv->agent.device-
> > >name)
> > > +		__field(void *,         agent_priv)
> > > +		__field(unsigned long,  timeout)
> > > +		__field(int,            retries_left)
> > > +		__field(int,            max_retries)
> > > +		__field(int,            retry)
> > > +		__field(u32,            rqkey)
> > > +		__field(u16,            pkey)
> > > +	),
> >
> > Does it really make sense to extract all this data? Can we just trace the bulk
> > packet header? I have no idea what convention is in tracing..
> 

A bulk header would preclude filtering or triggering on the fields in the bulk portion.

That is one of the most useful aspects of the static tracing.

Mike



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux