Re: [PATCH RFC rdma-core 1/3] util: Add common code for provider debug

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

 



On Thu, Jan 19, 2017 at 10:58:38AM -0700, Jason Gunthorpe wrote:
> On Thu, Jan 19, 2017 at 10:09:24AM +0200, Leon Romanovsky wrote:
> > On Wed, Jan 18, 2017 at 11:44:11AM -0700, Jason Gunthorpe wrote:
> > > On Wed, Jan 18, 2017 at 08:31:04PM +0200, Leon Romanovsky wrote:
> > > > On Wed, Jan 18, 2017 at 09:44:44AM -0700, Jason Gunthorpe wrote:
> > > > > On Wed, Jan 18, 2017 at 07:31:30AM +0200, Leon Romanovsky wrote:
> > > > > > > +#define PRINT_ERR(fmt, ...)								\
> > > > > > > +do {											\
> > > > > > > +	fprintf(stderr, "[%s:%d]" fmt, __func__, __LINE__, ##__VA_ARGS__);		\
> > > > > > > +} while (0)
> > > > > > > +
> > > > > > > +#define PRINT_DBG(dbg_mask, dbg_level, fmt, ...)					\
> > > > > > > +do {											\
> > > > > > > +	if ((rdma_dbg_mask & dbg_mask) && (rdma_dbg_level >= dbg_level))		\
> > > > > > > +		fprintf(stderr, "[%s:%d]" fmt, __func__, __LINE__, ##__VA_ARGS__);	\
> > > > > > > +} while (0)
> > > > > > > +
> > > > > > > +#define LOG_DBG(dbg_fp, dbg_mask, dbg_level, fmt, ...)					\
> > > > > > > +do {											\
> > > > > > > +	if ((rdma_dbg_mask & dbg_mask) && (rdma_dbg_level >= dbg_level))		\
> > > > > > > +		fprintf(dbg_fp, "[%s:%d]" fmt, __func__, __LINE__, ##__VA_ARGS__);	\
> > > > > > > +} while (0)
> > > > > > > +
> > > > > > > +#define LOG_DBG_FLUSH(dbg_fp, dbg_mask, dbg_level, fmt, ...)				\
> > > > > > > +do {											\
> > > > > > > +		LOG_DBG(dbg_fp, dbg_mask, dbg_level, fmt, ##__VA_ARGS__);		\
> > > > > > > +		if (dbg_fp != stderr)							\
> > > > > > > +			fflush(dbg_fp);							\
> > > > > > > +} while (0)
> > > > > >
> > > > > > IMHO, these macros should be inline functions, and better to avoid global variables.
> > > > >
> > > > > It is more expensive at the call site to inline something that calls
> > > > > via va_args than via ..., so these should remain as macros.
> > > >
> > > > These macros/functions need to be compiled in for DEBUG mode only, in
> > > > such case you can pay extra CPU cycles.
> > >
> > > One of the reasonable ways to use this is to always compile in *error
> > > case* debug prints, as these are intrinsically on the slow error path
> > > already - however for that use we certainly want to minimize icache
> > > consumption at the call site.
> >
> > There are debug prints in data path too.
> > https://patchwork.kernel.org/patch/9521817/
> > See mlx5_get_next_cqe and mlx5_cq_read_wc_opcode functions.
>
> I was suggesting two debug entry points, one that is compiled out and the
> other that is not.

Exactly, I just didn't understand it from your previous responses.

Thanks

>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Attachment: signature.asc
Description: PGP signature


[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