Checks
Commit Message
* Rename net/ark specific CONFIG_RTE macros to local macros.
* Change condition of ARK_PAD_TX to match behavior of meson build
to makefile build.
* Install header file needed for dynamic library.
* Update doc as required.
Signed-off-by: Ed Czeck <ed.czeck@atomicrules.com>
---
doc/guides/nics/ark.rst | 24 ++++++++++++++----------
drivers/net/ark/ark_logs.h | 16 +++++++---------
drivers/net/ark/meson.build | 2 ++
3 files changed, 23 insertions(+), 19 deletions(-)
Comments
On 8/19/2020 9:45 PM, Ed Czeck wrote:
> * Rename net/ark specific CONFIG_RTE macros to local macros.
> * Change condition of ARK_PAD_TX to match behavior of meson build
> to makefile build.
> * Install header file needed for dynamic library.
> * Update doc as required.
>
> Signed-off-by: Ed Czeck <ed.czeck@atomicrules.com>
> ---
> doc/guides/nics/ark.rst | 24 ++++++++++++++----------
> drivers/net/ark/ark_logs.h | 16 +++++++---------
> drivers/net/ark/meson.build | 2 ++
> 3 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/doc/guides/nics/ark.rst b/doc/guides/nics/ark.rst
> index 06e8c3374..4d8920cd0 100644
> --- a/doc/guides/nics/ark.rst
> +++ b/doc/guides/nics/ark.rst
> @@ -124,27 +124,31 @@ Configuration Information
>
> **DPDK Configuration Parameters**
>
> - The following configuration options are available for the ARK PMD:
> + The following compile-time configuration options are available for the ARK PMD:
>
> - * **CONFIG_RTE_LIBRTE_ARK_PMD** (default y): Enables or disables inclusion
> - of the ARK PMD driver in the DPDK compilation.
> + * **ARK_NOPAD_TX**: When enabled TX
> + packets are not padded to 60 bytes to support downstream MACS.
>
> - * **CONFIG_RTE_LIBRTE_ARK_PAD_TX** (default y): When enabled TX
> - packets are padded to 60 bytes to support downstream MACS.
> -
> - * **CONFIG_RTE_LIBRTE_ARK_DEBUG_RX** (default n): Enables or disables debug
> + * **ARK_DEBUG_RX**: Enables debug
> logging and internal checking of RX ingress logic within the ARK PMD driver.
>
> - * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TX** (default n): Enables or disables debug
> + * **ARK_DEBUG_TX**: Enables debug
> logging and internal checking of TX egress logic within the ARK PMD driver.
>
> - * **CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS** (default n): Enables or disables debug
> + * **ARK_DEBUG_STATS**: Enables debug
> logging of detailed packet and performance statistics gathered in
> the PMD and FPGA.
>
> - * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE** (default n): Enables or disables debug
> + * **ARK_DEBUG_TRACE**: Enables debug
> logging of detailed PMD events and status.
Logging can be controlled in runtime, that is what we should use.
In data path, we use compile time flags because of the performance issues. So OK
to have 'CONFIG_RTE_LIBRTE_ARK_DEBUG_RX' & 'CONFIG_RTE_LIBRTE_ARK_DEBUG_TX' as
compile time flag, but why having compile time flag for rest?
>
> +Note that enabling debugging options may affect system performance.
> +These options may be set by specifying them in CFLAG
> +environment before the meson build set. E.g.::
> +
> + export CFLAGS="-DARK_DEBUG_TRACE"
> + meson build
> +
When you passed the flag as above, it is still global to all components in the
DPDK, this is not just for ark. What is the motivation to remove the
"RET_LIBRTE_" prefix?
>
> Building DPDK
> -------------
> diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h
> index 44aac6102..125583475 100644
> --- a/drivers/net/ark/ark_logs.h
> +++ b/drivers/net/ark/ark_logs.h
> @@ -6,14 +6,12 @@
> #define _ARK_DEBUG_H_
>
> #include <inttypes.h>
> -#include <rte_log.h>
> -
>
> /* Configuration option to pad TX packets to 60 bytes */
> -#ifdef RTE_LIBRTE_ARK_PAD_TX
> -#define ARK_TX_PAD_TO_60 1
> -#else
> +#ifdef ARK_NOPAD_TX
> #define ARK_TX_PAD_TO_60 0
> +#else
> +#define ARK_TX_PAD_TO_60 1
> #endif
So you don't want to convert this to runtime configuration.
The point we are reducing compile time flags:
1) It forks the code paths and by time it leave not tested, even not compiled
code paths which may cause rotten code by time.
2) Multiple code paths will lead deployment problems. When you deploy an
application, you won't able to change the compile time configuration in customer
environment and need to re-compile (most probably re-test) and re-deploy it.
Also there is not easy way to figure out from binary in customer environment
that with which compile time flags it has been built.
Switching to CFLAGS="..." doesn't make above concerns go away and indeed it
makes (1) worst since hides the config options within the driver. Previously it
was possible to trigger each config option and do testing using scripts, now
since config options are hidden in driver we can't do even that.
Can you please detail why "ARK_TX_PAD_TO_60" is needed exactly?
And can you please justify why it has to be compile time config option?
<...>
> @@ -11,3 +11,5 @@ sources = files('ark_ddm.c',
> 'ark_pktgen.c',
> 'ark_rqp.c',
> 'ark_udm.c')
> +
> +install_headers('ark_ext.h')
>
Installing PMD header file is not required but this has an unique usage.
Ark PMD is wrapper to the external shared library which should implement the
functions that has prototypes in the 'ark_ext.h'.
Since this header is not needed by users of the dpdk library, but needed by
extension developers for the ark PMD, I think the header should not be installed.
On Thu, Aug 20, 2020 at 7:16 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
...
>
> Logging can be controlled in runtime, that is what we should use.
> In data path, we use compile time flags because of the performance issues. So OK
> to have 'CONFIG_RTE_LIBRTE_ARK_DEBUG_RX' & 'CONFIG_RTE_LIBRTE_ARK_DEBUG_TX' as
> compile time flag, but why having compile time flag for rest?
Agreed. We'll remove most of these macro in the next commit pushing
the behavior
into run-time log control.
> >
> > +Note that enabling debugging options may affect system performance.
> > +These options may be set by specifying them in CFLAG
> > +environment before the meson build set. E.g.::
> > +
> > + export CFLAGS="-DARK_DEBUG_TRACE"
> > + meson build
> > +
>
> When you passed the flag as above, it is still global to all components in the
> DPDK, this is not just for ark. What is the motivation to remove the
> "RET_LIBRTE_" prefix?
There are 2 issues here.
1) With the makefile flow, users could add other configurations with
the documented
and recommended sed commands. I.e.,
sed -ri 's/(CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE)=n/\1=y/' build/.config
The makefiles took care of everything from there. This no longer works with the
meson build flow. The solution is to set that macro passing it in the
CFLAG environment.
We're open to other recommendations.
2) Is there an advantage of promoting a PMD macro to a global macro?
It seems to add to the noise of dpdk configuration and there are many
PMD specific macros throughout the code base.
>
> >
> > Building DPDK
> > -------------
> > diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h
> > index 44aac6102..125583475 100644
> > --- a/drivers/net/ark/ark_logs.h
> > +++ b/drivers/net/ark/ark_logs.h
> > @@ -6,14 +6,12 @@
> > #define _ARK_DEBUG_H_
> >
> > #include <inttypes.h>
> > -#include <rte_log.h>
> > -
> >
> > /* Configuration option to pad TX packets to 60 bytes */
> > -#ifdef RTE_LIBRTE_ARK_PAD_TX
> > -#define ARK_TX_PAD_TO_60 1
> > -#else
> > +#ifdef ARK_NOPAD_TX
> > #define ARK_TX_PAD_TO_60 0
> > +#else
> > +#define ARK_TX_PAD_TO_60 1
> > #endif
>
> So you don't want to convert this to runtime configuration.
>
> The point we are reducing compile time flags:
> 1) It forks the code paths and by time it leave not tested, even not compiled
> code paths which may cause rotten code by time.
>
> 2) Multiple code paths will lead deployment problems. When you deploy an
> application, you won't able to change the compile time configuration in customer
> environment and need to re-compile (most probably re-test) and re-deploy it.
> Also there is not easy way to figure out from binary in customer environment
> that with which compile time flags it has been built.
>
> Switching to CFLAGS="..." doesn't make above concerns go away and indeed it
> makes (1) worst since hides the config options within the driver. Previously it
> was possible to trigger each config option and do testing using scripts, now
> since config options are hidden in driver we can't do even that.
>
> Can you please detail why "ARK_TX_PAD_TO_60" is needed exactly?
> And can you please justify why it has to be compile time config option?
>
The need to pad packets is dependent on the underlying FPGA hardware
implementation which lies outside the control of our deliverables. Thus we
leave control up to our customer and how they deliver and deploy DPDK. This
needs to be a compile-time macro since the code executes within the
per-packet processing under rte_eth_tx_burst().
We can change the macro to ARK_MIN_TX_PKTLEN, which should have zero
overhead when set to 0. (I'm assuming that compiles will remove if
(unsigned < 0) blocks.) Should this be an RTE_LIBRTE macro? How does
a user change this during compile?
> <...>
>
> > @@ -11,3 +11,5 @@ sources = files('ark_ddm.c',
> > 'ark_pktgen.c',
> > 'ark_rqp.c',
> > 'ark_udm.c')
> > +
> > +install_headers('ark_ext.h')
> >
>
> Installing PMD header file is not required but this has an unique usage.
>
> Ark PMD is wrapper to the external shared library which should implement the
> functions that has prototypes in the 'ark_ext.h'.
>
> Since this header is not needed by users of the dpdk library, but needed by
> extension developers for the ark PMD, I think the header should not be installed.
So is your recommendation that anyone developing an ark pmd extension
must have access to DPDK source, in addition to the installed code?
It seems like one include location is better than two.
Many thanks,
Ed.
On 8/20/2020 4:41 PM, Ed Czeck wrote:
> On Thu, Aug 20, 2020 at 7:16 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
> ...
>>
>> Logging can be controlled in runtime, that is what we should use.
>> In data path, we use compile time flags because of the performance issues. So OK
>> to have 'CONFIG_RTE_LIBRTE_ARK_DEBUG_RX' & 'CONFIG_RTE_LIBRTE_ARK_DEBUG_TX' as
>> compile time flag, but why having compile time flag for rest?
>
> Agreed. We'll remove most of these macro in the next commit pushing
> the behavior
> into run-time log control.
>
>>>
>>> +Note that enabling debugging options may affect system performance.
>>> +These options may be set by specifying them in CFLAG
>>> +environment before the meson build set. E.g.::
>>> +
>>> + export CFLAGS="-DARK_DEBUG_TRACE"
>>> + meson build
>>> +
>>
>> When you passed the flag as above, it is still global to all components in the
>> DPDK, this is not just for ark. What is the motivation to remove the
>> "RET_LIBRTE_" prefix?
>
> There are 2 issues here.
> 1) With the makefile flow, users could add other configurations with
> the documented
> and recommended sed commands. I.e.,
> sed -ri 's/(CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE)=n/\1=y/' build/.config
> The makefiles took care of everything from there. This no longer works with the
> meson build flow. The solution is to set that macro passing it in the
> CFLAG environment.
> We're open to other recommendations.
Yes compile time flags are harder to use with meson build system, and this is
kind of intentional because of above mentioned reasons.
It is possible to add compile time option as meson config option if we must, but
that is not suggested, the intention is get rid of compile time flags as much as
we can, and we were already very picky to accept new compile time flags to make
build for some time.
> 2) Is there an advantage of promoting a PMD macro to a global macro?
> It seems to add to the noise of dpdk configuration and there are many
> PMD specific macros throughout the code base.
If CFLAG used to pass macros to multiple components, or if there is a bigger
build environment that builds both application and DPDK, CFLAGS is common flag
and I think better to keep the DPDK namespace for DPDK macros. At least let me
say the way that I don't see the motivation to remove the DPDK namespace from
macros.
>
>>
>>>
>>> Building DPDK
>>> -------------
>>> diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h
>>> index 44aac6102..125583475 100644
>>> --- a/drivers/net/ark/ark_logs.h
>>> +++ b/drivers/net/ark/ark_logs.h
>>> @@ -6,14 +6,12 @@
>>> #define _ARK_DEBUG_H_
>>>
>>> #include <inttypes.h>
>>> -#include <rte_log.h>
>>> -
>>>
>>> /* Configuration option to pad TX packets to 60 bytes */
>>> -#ifdef RTE_LIBRTE_ARK_PAD_TX
>>> -#define ARK_TX_PAD_TO_60 1
>>> -#else
>>> +#ifdef ARK_NOPAD_TX
>>> #define ARK_TX_PAD_TO_60 0
>>> +#else
>>> +#define ARK_TX_PAD_TO_60 1
>>> #endif
>>
>> So you don't want to convert this to runtime configuration.
>>
>> The point we are reducing compile time flags:
>> 1) It forks the code paths and by time it leave not tested, even not compiled
>> code paths which may cause rotten code by time.
>>
>> 2) Multiple code paths will lead deployment problems. When you deploy an
>> application, you won't able to change the compile time configuration in customer
>> environment and need to re-compile (most probably re-test) and re-deploy it.
>> Also there is not easy way to figure out from binary in customer environment
>> that with which compile time flags it has been built.
>>
>> Switching to CFLAGS="..." doesn't make above concerns go away and indeed it
>> makes (1) worst since hides the config options within the driver. Previously it
>> was possible to trigger each config option and do testing using scripts, now
>> since config options are hidden in driver we can't do even that.
>>
>> Can you please detail why "ARK_TX_PAD_TO_60" is needed exactly?
>> And can you please justify why it has to be compile time config option?
>>
> The need to pad packets is dependent on the underlying FPGA hardware
> implementation which lies outside the control of our deliverables. Thus we
> leave control up to our customer and how they deliver and deploy DPDK. This
> needs to be a compile-time macro since the code executes within the
> per-packet processing under rte_eth_tx_burst().
It is still possible to use runtime config by having two burst functions, one
with padding and without padding support, which is selected based on provided
runtime flag. Runtime parameter can provide the padding size.
But agree that adds more complexity.
>
> We can change the macro to ARK_MIN_TX_PKTLEN, which should have zero
> overhead when set to 0. (I'm assuming that compiles will remove if
> (unsigned < 0) blocks.) Should this be an RTE_LIBRTE macro? How does
> a user change this during compile?
>
>> <...>
>>
>>> @@ -11,3 +11,5 @@ sources = files('ark_ddm.c',
>>> 'ark_pktgen.c',
>>> 'ark_rqp.c',
>>> 'ark_udm.c')
>>> +
>>> +install_headers('ark_ext.h')
>>>
>>
>> Installing PMD header file is not required but this has an unique usage.
>>
>> Ark PMD is wrapper to the external shared library which should implement the
>> functions that has prototypes in the 'ark_ext.h'.
>>
>> Since this header is not needed by users of the dpdk library, but needed by
>> extension developers for the ark PMD, I think the header should not be installed.
>
> So is your recommendation that anyone developing an ark pmd extension
> must have access to DPDK source, in addition to the installed code?
> It seems like one include location is better than two.
>
Yes.
I understand it makes PMD extension developer's life easy to have 'ark_ext.h'
installed in system folders but I think it doesn't fit there.
DPDK public headers are for application developers to use the DPDK APIs.
'ark_ext.h' is used by PMD developer to build PMD extension which is indeed can
be taken as developing DPDK internal component.
And if I understand correctly the a PMD extension is required per a bitstream
for a Arkville device, so not really many developers affected from it.
(Also the name prefix and the namespace of the symbols in the header is not
suitable to be a public header, but this is something else.)
@@ -124,27 +124,31 @@ Configuration Information
**DPDK Configuration Parameters**
- The following configuration options are available for the ARK PMD:
+ The following compile-time configuration options are available for the ARK PMD:
- * **CONFIG_RTE_LIBRTE_ARK_PMD** (default y): Enables or disables inclusion
- of the ARK PMD driver in the DPDK compilation.
+ * **ARK_NOPAD_TX**: When enabled TX
+ packets are not padded to 60 bytes to support downstream MACS.
- * **CONFIG_RTE_LIBRTE_ARK_PAD_TX** (default y): When enabled TX
- packets are padded to 60 bytes to support downstream MACS.
-
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_RX** (default n): Enables or disables debug
+ * **ARK_DEBUG_RX**: Enables debug
logging and internal checking of RX ingress logic within the ARK PMD driver.
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TX** (default n): Enables or disables debug
+ * **ARK_DEBUG_TX**: Enables debug
logging and internal checking of TX egress logic within the ARK PMD driver.
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS** (default n): Enables or disables debug
+ * **ARK_DEBUG_STATS**: Enables debug
logging of detailed packet and performance statistics gathered in
the PMD and FPGA.
- * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE** (default n): Enables or disables debug
+ * **ARK_DEBUG_TRACE**: Enables debug
logging of detailed PMD events and status.
+Note that enabling debugging options may affect system performance.
+These options may be set by specifying them in CFLAG
+environment before the meson build set. E.g.::
+
+ export CFLAGS="-DARK_DEBUG_TRACE"
+ meson build
+
Building DPDK
-------------
@@ -6,14 +6,12 @@
#define _ARK_DEBUG_H_
#include <inttypes.h>
-#include <rte_log.h>
-
/* Configuration option to pad TX packets to 60 bytes */
-#ifdef RTE_LIBRTE_ARK_PAD_TX
-#define ARK_TX_PAD_TO_60 1
-#else
+#ifdef ARK_NOPAD_TX
#define ARK_TX_PAD_TO_60 0
+#else
+#define ARK_TX_PAD_TO_60 1
#endif
/* system camel case definition changed to upper case */
@@ -55,7 +53,7 @@ extern int ark_logtype;
/* Debug macro for tracing full behavior, function tracing and messages*/
-#ifdef RTE_LIBRTE_ARK_DEBUG_TRACE
+#ifdef ARK_DEBUG_TRACE
#define PMD_FUNC_LOG(level, fmt, ...) ARK_FUNC_ON(level, fmt, ##__VA_ARGS__)
#define PMD_DEBUG_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
#else
@@ -65,7 +63,7 @@ extern int ark_logtype;
/* Debug macro for reporting FPGA statistics */
-#ifdef RTE_LIBRTE_ARK_DEBUG_STATS
+#ifdef ARK_DEBUG_STATS
#define PMD_STATS_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
#else
#define PMD_STATS_LOG(level, fmt, ...) ARK_TRACE_OFF(level, fmt, ##__VA_ARGS__)
@@ -73,7 +71,7 @@ extern int ark_logtype;
/* Debug macro for RX path */
-#ifdef RTE_LIBRTE_ARK_DEBUG_RX
+#ifdef ARK_DEBUG_RX
#define ARK_RX_DEBUG 1
#define PMD_RX_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
#else
@@ -82,7 +80,7 @@ extern int ark_logtype;
#endif
/* Debug macro for TX path */
-#ifdef RTE_LIBRTE_ARK_DEBUG_TX
+#ifdef ARK_DEBUG_TX
#define ARK_TX_DEBUG 1
#define PMD_TX_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
#else
@@ -11,3 +11,5 @@ sources = files('ark_ddm.c',
'ark_pktgen.c',
'ark_rqp.c',
'ark_udm.c')
+
+install_headers('ark_ext.h')