diff mbox series

[v3,01/32] common/cpt: add common logging support

Message ID 1538744363-30340-2-git-send-email-anoob.joseph@caviumnetworks.com (mailing list archive)
State Superseded, archived
Delegated to: akhil goyal
Headers
Series Adding Cavium's OCTEONTX crypto PMD |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Anoob Joseph Oct. 5, 2018, 12:58 p.m. UTC 
  From: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>

Add common logging macros

Signed-off-by: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
Signed-off-by: Murthy NSSR <nidadavolu.murthy@caviumnetworks.com>
Signed-off-by: Nithin Dabilpuram <nithin.dabilpuram@caviumnetworks.com>
Signed-off-by: Ragothaman Jayaraman <rjayaraman@caviumnetworks.com>
Signed-off-by: Srisivasubramanian S <ssrinivasan@caviumnetworks.com>
Signed-off-by: Tejasree Kondoj <kondoj.tejasree@caviumnetworks.com>
---
 MAINTAINERS                       |  4 ++++
 drivers/common/cpt/cpt_pmd_logs.h | 50 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+)
 create mode 100644 drivers/common/cpt/cpt_pmd_logs.h

Comments

Thomas Monjalon Oct. 8, 2018, 12:27 p.m. UTC | #1 
05/10/2018 14:58, Anoob Joseph:
> +Cavium OCTEON TX
> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> +F: drivers/common/cpt/

What is the real wording for this device family?
Sometimes I read OcteonTX with lowercases and no space,
sometimes OCTEONTX without space, sometimes OCTEON TX.

Another note: You should differentiate ethdev and cryptodev devices,
at least in the maintainer file.
We have nicvf, zipvf, ssovf, timvf.
I suggest to add "crypto" to the name of this section.
Anoob Joseph Oct. 8, 2018, 1:07 p.m. UTC | #2 
Hi Thomas,

On 08-10-2018 17:57, Thomas Monjalon wrote:
> External Email
>
> 05/10/2018 14:58, Anoob Joseph:
>> +Cavium OCTEON TX
>> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> +F: drivers/common/cpt/
> What is the real wording for this device family?
> Sometimes I read OcteonTX with lowercases and no space,
> sometimes OCTEONTX without space, sometimes OCTEON TX.
>
> Another note: You should differentiate ethdev and cryptodev devices,
> at least in the maintainer file.
> We have nicvf, zipvf, ssovf, timvf.
OCTEON TX (with the space) is the registered name of the chip. nicvf, 
zipvf, ssovf, timvf are all multiple blocks on the device and previous 
drivers were named that way. CPT is the similar name for the crypto 
block. Jerin is planning for a common naming convention for the blocks 
on the same family.

Different blocks would be named crypto_octeontx, event_octeontx etc, to 
denote that they are all part of the same device. We had to omit the 
space (between OCTEON & TX), since it would complicate the name for the 
directories.

OcteonTX is a wrong convention. It would be fixed going ahead.
> I suggest to add "crypto" to the name of this section.
This entry is already under "Crypto Drivers". So do we need a separate 
mention of "crypto"?

Anoob
Thomas Monjalon Oct. 8, 2018, 1:37 p.m. UTC | #3 
08/10/2018 15:07, Joseph, Anoob:
> On 08-10-2018 17:57, Thomas Monjalon wrote:
> > 05/10/2018 14:58, Anoob Joseph:
> >> +Cavium OCTEON TX
> >> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> >> +F: drivers/common/cpt/
> > What is the real wording for this device family?
> > Sometimes I read OcteonTX with lowercases and no space,
> > sometimes OCTEONTX without space, sometimes OCTEON TX.
> >
> > Another note: You should differentiate ethdev and cryptodev devices,
> > at least in the maintainer file.
> > We have nicvf, zipvf, ssovf, timvf.
> OCTEON TX (with the space) is the registered name of the chip. nicvf, 
> zipvf, ssovf, timvf are all multiple blocks on the device and previous 
> drivers were named that way. CPT is the similar name for the crypto 
> block. Jerin is planning for a common naming convention for the blocks 
> on the same family.
> 
> Different blocks would be named crypto_octeontx, event_octeontx etc, to 
> denote that they are all part of the same device. We had to omit the 
> space (between OCTEON & TX), since it would complicate the name for the 
> directories.
> 
> OcteonTX is a wrong convention. It would be fixed going ahead.
> > I suggest to add "crypto" to the name of this section.
> This entry is already under "Crypto Drivers". So do we need a separate 
> mention of "crypto"?

Yes I think it is better to add "crypto", especially for automated processing
of this file, we should avoid to have two times the same section title.
Anoob Joseph Oct. 8, 2018, 2:39 p.m. UTC | #4 
Hi Thomas,

On 08-10-2018 19:07, Thomas Monjalon wrote:
> External Email
>
> 08/10/2018 15:07, Joseph, Anoob:
>> On 08-10-2018 17:57, Thomas Monjalon wrote:
>>> 05/10/2018 14:58, Anoob Joseph:
>>>> +Cavium OCTEON TX
>>>> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>> +F: drivers/common/cpt/
>>> What is the real wording for this device family?
>>> Sometimes I read OcteonTX with lowercases and no space,
>>> sometimes OCTEONTX without space, sometimes OCTEON TX.
>>>
>>> Another note: You should differentiate ethdev and cryptodev devices,
>>> at least in the maintainer file.
>>> We have nicvf, zipvf, ssovf, timvf.
>> OCTEON TX (with the space) is the registered name of the chip. nicvf,
>> zipvf, ssovf, timvf are all multiple blocks on the device and previous
>> drivers were named that way. CPT is the similar name for the crypto
>> block. Jerin is planning for a common naming convention for the blocks
>> on the same family.
>>
>> Different blocks would be named crypto_octeontx, event_octeontx etc, to
>> denote that they are all part of the same device. We had to omit the
>> space (between OCTEON & TX), since it would complicate the name for the
>> directories.
>>
>> OcteonTX is a wrong convention. It would be fixed going ahead.
>>> I suggest to add "crypto" to the name of this section.
>> This entry is already under "Crypto Drivers". So do we need a separate
>> mention of "crypto"?
> Yes I think it is better to add "crypto", especially for automated processing
> of this file, we should avoid to have two times the same section title.
>
>
I would go ahead with,

Cavium OCTEONTX crypto

Hope this would be fine.

Thanks,
Anoob
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 5967c1d..52202b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -772,6 +772,10 @@  F: drivers/crypto/armv8/
 F: doc/guides/cryptodevs/armv8.rst
 F: doc/guides/cryptodevs/features/armv8.ini
 
+Cavium OCTEON TX
+M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
+F: drivers/common/cpt/
+
 Crypto Scheduler
 M: Fan Zhang <roy.fan.zhang@intel.com>
 F: drivers/crypto/scheduler/
diff --git a/drivers/common/cpt/cpt_pmd_logs.h b/drivers/common/cpt/cpt_pmd_logs.h
new file mode 100644
index 0000000..4cbec4e
--- /dev/null
+++ b/drivers/common/cpt/cpt_pmd_logs.h
@@ -0,0 +1,50 @@ 
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium, Inc
+ */
+
+#ifndef _CPT_PMD_LOGS_H_
+#define _CPT_PMD_LOGS_H_
+
+#include <rte_log.h>
+
+/*
+ * This file defines log macros
+ */
+
+#define CPT_PMD_DRV_LOG_RAW(level, fmt, args...) \
+		rte_log(RTE_LOG_ ## level, cpt_logtype, \
+			"cpt: %s(): " fmt "\n", __func__, ##args)
+
+#define CPT_PMD_INIT_FUNC_TRACE() CPT_PMD_DRV_LOG_RAW(DEBUG, " >>")
+
+#define CPT_LOG_INFO(fmt, args...) \
+	CPT_PMD_DRV_LOG_RAW(INFO, fmt, ## args)
+#define CPT_LOG_WARN(fmt, args...) \
+	CPT_PMD_DRV_LOG_RAW(WARNING, fmt, ## args)
+#define CPT_LOG_ERR(fmt, args...) \
+	CPT_PMD_DRV_LOG_RAW(ERR, fmt, ## args)
+
+/*
+ * DP logs, toggled out at compile time if level lower than current level.
+ * DP logs would be logged under 'PMD' type. So for dynamic logging, the
+ * level of 'pmd' has to be used.
+ */
+#define CPT_LOG_DP(level, fmt, args...) \
+	RTE_LOG_DP(level, PMD, fmt "\n", ## args)
+
+#define CPT_LOG_DP_DEBUG(fmt, args...) \
+	CPT_LOG_DP(DEBUG, fmt, ## args)
+#define CPT_LOG_DP_INFO(fmt, args...) \
+	CPT_LOG_DP(INFO, fmt, ## args)
+#define CPT_LOG_DP_WARN(fmt, args...) \
+	CPT_LOG_DP(WARNING, fmt, ## args)
+#define CPT_LOG_DP_ERR(fmt, args...) \
+	CPT_LOG_DP(ERR, fmt, ## args)
+
+/*
+ * cpt_logtype will be used for common logging. This field would be initialized
+ * by otx_* driver routines during PCI probe.
+ */
+int cpt_logtype;
+
+#endif /* _CPT_PMD_LOGS_H_ */