* Re: [PATCH v2 5/5] devtools: ignore changes into bbdev experimental API
@ 2023-09-18 15:22 0% ` Maxime Coquelin
0 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2023-09-18 15:22 UTC (permalink / raw)
To: Nicolas Chautru, dev; +Cc: trix, hemant.agrawal, david.marchand, hernan.vargas
On 6/15/23 18:49, Nicolas Chautru wrote:
> Developpers are warned that the related fft experimental functions
> do not preserve ABI, hence these can be waived.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> devtools/libabigail.abignore | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 7a93de3ba1..09b8f156b5 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -30,7 +30,9 @@
> [suppress_type]
> type_kind = enum
> changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> -
> +; Ignore changes to bbdev FFT API which is experimental
> +[suppress_type]
> + name = rte_bbdev_fft_op
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ; Temporary exceptions till next major ABI version ;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
With Hemmant's typo fix suggestion:
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
@ 2023-09-18 15:42 0% ` Maxime Coquelin
2023-09-18 20:50 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2023-09-18 15:42 UTC (permalink / raw)
To: Nicolas Chautru, dev; +Cc: trix, hemant.agrawal, david.marchand, hernan.vargas
On 9/18/23 17:08, Maxime Coquelin wrote:
>
>
> On 6/15/23 18:48, Nicolas Chautru wrote:
>> Extending existing FFT operation for new capabilities.
>> Optional frequency domain dewindowing, frequency resampling,
>> timing error correction and time offset per CS.
>>
>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>> ---
>> doc/guides/prog_guide/bbdev.rst | 24 ++++++++++++++++++++++++
>> lib/bbdev/rte_bbdev_op.h | 23 ++++++++++++++++++++++-
>> 2 files changed, 46 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/guides/prog_guide/bbdev.rst
>> b/doc/guides/prog_guide/bbdev.rst
>> index 8e384015ee..95b33562fe 100644
>> --- a/doc/guides/prog_guide/bbdev.rst
>> +++ b/doc/guides/prog_guide/bbdev.rst
>> @@ -1111,6 +1111,18 @@ with the operation flags forming a bitmask in
>> the ``op_flags`` field.
>> |RTE_BBDEV_FFT_FP16_OUTPUT |
>> | Set if the output data shall use FP16 format instead of INT16 |
>> +--------------------------------------------------------------------+
>> +|RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS |
>> +| Set if device supports adjusting time offset per CS |
>> ++--------------------------------------------------------------------+
>> +|RTE_BBDEV_FFT_TIMING_ERROR |
>> +| Set if device supports correcting for timing error |
>> ++--------------------------------------------------------------------+
>> +|RTE_BBDEV_FFT_DEWINDOWING |
>> +| Set if enabling the option FFT Dewindowing in Frequency domain |
>> ++--------------------------------------------------------------------+
>> +|RTE_BBDEV_FFT_FREQ_RESAMPLING |
>> +| Set if device supports the optional frequency resampling |
>> ++--------------------------------------------------------------------+
>> The FFT parameters are set out in the table below.
>> @@ -1121,6 +1133,8 @@ The FFT parameters are set out in the table below.
>>
>> +-------------------------+--------------------------------------------------------------+
>> |base_output |output
>> data |
>>
>> +-------------------------+--------------------------------------------------------------+
>> +|dewindowing_input |optional frequency domain dewindowing
>> input data |
>> ++-------------------------+--------------------------------------------------------------+
>> |power_meas_output |optional output data with power
>> measurement on DFT output |
>>
>> +-------------------------+--------------------------------------------------------------+
>> |op_flags |bitmask of all active operation
>> capabilities |
>> @@ -1155,6 +1169,16 @@ The FFT parameters are set out in the table below.
>>
>> +-------------------------+--------------------------------------------------------------+
>> |fp16_exp_adjust |value added to FP16 exponent at
>> conversion from INT16 |
>>
>> +-------------------------+--------------------------------------------------------------+
>> +|freq_resample_mode |frequency ressampling mode (0:transparent,
>> 1-2: resample) |
>> ++-------------------------+--------------------------------------------------------------+
>> +| output_depadded_size |output depadded size prior to frequency
>> resampling |
>> ++-------------------------+--------------------------------------------------------------+
>> +|cs_theta_0 |timing error correction initial
>> phase |
>> ++-------------------------+--------------------------------------------------------------+
>> +|cs_theta_d |timing error correction phase
>> increment |
>> ++-------------------------+--------------------------------------------------------------+
>> +|time_offset |time offset per CS of time domain
>> samples |
>> ++-------------------------+--------------------------------------------------------------+
>> The mbuf input ``base_input`` is mandatory for all bbdev PMDs and
>> is the incoming data for the processing. Its size may not fit into
>> an actual mbuf,
>> diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
>> index 990d110fa7..682e265327 100644
>> --- a/lib/bbdev/rte_bbdev_op.h
>> +++ b/lib/bbdev/rte_bbdev_op.h
>> @@ -50,6 +50,7 @@ extern "C" {
>> #define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
>> /* 12 CS maximum */
>> #define RTE_BBDEV_MAX_CS_2 (6)
>> +#define RTE_BBDEV_MAX_CS (12)
>> /* MLD-TS up to 4 layers */
>> #define RTE_BBDEV_MAX_MLD_LAYERS (4)
>> /* 12 SB per RB */
>> @@ -242,7 +243,15 @@ enum rte_bbdev_op_fft_flag_bitmasks {
>> /** Set if the input data used FP16 format. */
>> RTE_BBDEV_FFT_FP16_INPUT = (1ULL << 6),
>> /** Set if the output data uses FP16 format. */
>> - RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7)
>> + RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7),
>> + /** Flexible adjustment of Timing offset adjustment per CS. */
>> + RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS = (1ULL << 8),
>> + /** Flexible adjustment of Timing error correction per CS. */
>> + RTE_BBDEV_FFT_TIMING_ERROR = (1ULL << 9),
>> + /** Set for optional frequency domain dewindowing. */
>> + RTE_BBDEV_FFT_DEWINDOWING = (1ULL << 10),
>> + /** Flexible adjustment of frequency resampling mode. */
>> + RTE_BBDEV_FFT_FREQ_RESAMPLING = (1ULL << 11)
>> };
>> /** Flags for MLDTS operation and capability structure */
>> @@ -756,6 +765,8 @@ struct rte_bbdev_op_fft {
>> struct rte_bbdev_op_data base_input;
>> /** Output data starting from first antenna and first cyclic
>> shift. */
>> struct rte_bbdev_op_data base_output;
>> + /** Optional frequency window input data. */
>> + struct rte_bbdev_op_data dewindowing_input;
>> /** Optional power measurement output data. */
>> struct rte_bbdev_op_data power_meas_output;
>> /** Flags from rte_bbdev_op_fft_flag_bitmasks. */
>> @@ -790,6 +801,16 @@ struct rte_bbdev_op_fft {
>> uint16_t power_shift;
>> /** Adjust the FP6 exponent for INT<->FP16 conversion. */
>> uint16_t fp16_exp_adjust;
>> + /** Frequency resampling : 0: Transparent Mode1: 4/3 Resample2:
>> 2/3 Resample. */
>> + int8_t freq_resample_mode;
>> + /** Output depadded size prior to frequency resampling. */
>> + uint16_t output_depadded_size;
>> + /** Time error correction initial phase. */
>> + uint16_t cs_theta_0[RTE_BBDEV_MAX_CS];
>> + /** Time error correction phase increment. */
>> + uint32_t cs_theta_d[RTE_BBDEV_MAX_CS];
>> + /* Time offset per CS of time domain samples. */
>> + int8_t time_offset[RTE_BBDEV_MAX_CS];
>> };
>> /* >8 End of structure rte_bbdev_op_fft. */
>
> I think you need to document ABI change in:
> doc/guides/rel_notes/release_23_11.rst
Nevermind, I forgot the FFT API was still experimental.
No need to submit a new revision, I will fix the typos in patch 5.
Maxime
> Once done, please add my:
> Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>
> Maxime
>
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
2023-09-18 15:42 0% ` Maxime Coquelin
@ 2023-09-18 20:50 0% ` Chautru, Nicolas
0 siblings, 0 replies; 200+ results
From: Chautru, Nicolas @ 2023-09-18 20:50 UTC (permalink / raw)
To: Maxime Coquelin, dev
Cc: Rix, Tom, hemant.agrawal, david.marchand, Vargas, Hernan
Thanks Maxime.
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Monday, September 18, 2023 8:43 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
> Cc: Rix, Tom <trix@redhat.com>; hemant.agrawal@nxp.com;
> david.marchand@redhat.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v2 2/5] bbdev: add new capabilities for FFT processing
>
>
>
> On 9/18/23 17:08, Maxime Coquelin wrote:
> >
> >
> > On 6/15/23 18:48, Nicolas Chautru wrote:
> >> Extending existing FFT operation for new capabilities.
> >> Optional frequency domain dewindowing, frequency resampling, timing
> >> error correction and time offset per CS.
> >>
> >> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> >> ---
> >> doc/guides/prog_guide/bbdev.rst | 24 ++++++++++++++++++++++++
> >> lib/bbdev/rte_bbdev_op.h | 23 ++++++++++++++++++++++-
> >> 2 files changed, 46 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/guides/prog_guide/bbdev.rst
> >> b/doc/guides/prog_guide/bbdev.rst index 8e384015ee..95b33562fe
> 100644
> >> --- a/doc/guides/prog_guide/bbdev.rst
> >> +++ b/doc/guides/prog_guide/bbdev.rst
> >> @@ -1111,6 +1111,18 @@ with the operation flags forming a bitmask in
> >> the ``op_flags`` field.
> >> |RTE_BBDEV_FFT_FP16_OUTPUT
> >> |
> >> | Set if the output data shall use FP16 format instead of INT16
> >> |
> >>
> >> +--------------------------------------------------------------------
> >> +
> >> +|RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS
> >> +|| Set if device supports adjusting time offset per CS
> >> +||
> >> ++--------------------------------------------------------------------+
> >> +|RTE_BBDEV_FFT_TIMING_ERROR
> >> +|| Set if device supports correcting for timing error
> >> +||
> >> ++--------------------------------------------------------------------+
> >> +|RTE_BBDEV_FFT_DEWINDOWING
> >> +|| Set if enabling the option FFT Dewindowing in Frequency domain
> >> +||
> >> ++--------------------------------------------------------------------+
> >> +|RTE_BBDEV_FFT_FREQ_RESAMPLING
> >> +|| Set if device supports the optional frequency resampling
> >> +||
> >> ++--------------------------------------------------------------------+
> >> The FFT parameters are set out in the table below.
> >> @@ -1121,6 +1133,8 @@ The FFT parameters are set out in the table
> below.
> >>
> >> +-------------------------+--------------------------------------------------------------+
> >> |base_output |output
> >> data |
> >>
> >> +-------------------------+--------------------------------------------------------------+
> >> +|dewindowing_input |optional frequency domain dewindowing
> >> input data |
> >> ++-------------------------+--------------------------------------------------------------+
> >> |power_meas_output |optional output data with power
> >> measurement on DFT output |
> >>
> >> +-------------------------+--------------------------------------------------------------+
> >> |op_flags |bitmask of all active operation
> >> capabilities | @@ -1155,6 +1169,16 @@ The FFT
> >> parameters are set out in the table below.
> >>
> >> +-------------------------+--------------------------------------------------------------+
> >> |fp16_exp_adjust |value added to FP16 exponent at
> >> conversion from INT16 |
> >>
> >> +-------------------------+--------------------------------------------------------------+
> >> +|freq_resample_mode |frequency ressampling mode
> >> +|(0:transparent,
> >> 1-2: resample) |
> >> ++-------------------------+--------------------------------------------------------------+
> >> +| output_depadded_size |output depadded size prior to frequency
> >> resampling |
> >> ++-------------------------+--------------------------------------------------------------+
> >> +|cs_theta_0 |timing error correction initial
> >> phase |
> >> ++-------------------------+--------------------------------------------------------------+
> >> +|cs_theta_d |timing error correction phase
> >> increment |
> >> ++-------------------------+--------------------------------------------------------------+
> >> +|time_offset |time offset per CS of time domain
> >> samples |
> >> ++-------------------------+--------------------------------------------------------------+
> >> The mbuf input ``base_input`` is mandatory for all bbdev PMDs and
> >> is the incoming data for the processing. Its size may not fit into
> >> an actual mbuf, diff --git a/lib/bbdev/rte_bbdev_op.h
> >> b/lib/bbdev/rte_bbdev_op.h index 990d110fa7..682e265327 100644
> >> --- a/lib/bbdev/rte_bbdev_op.h
> >> +++ b/lib/bbdev/rte_bbdev_op.h
> >> @@ -50,6 +50,7 @@ extern "C" {
> >> #define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
> >> /* 12 CS maximum */
> >> #define RTE_BBDEV_MAX_CS_2 (6)
> >> +#define RTE_BBDEV_MAX_CS (12)
> >> /* MLD-TS up to 4 layers */
> >> #define RTE_BBDEV_MAX_MLD_LAYERS (4)
> >> /* 12 SB per RB */
> >> @@ -242,7 +243,15 @@ enum rte_bbdev_op_fft_flag_bitmasks {
> >> /** Set if the input data used FP16 format. */
> >> RTE_BBDEV_FFT_FP16_INPUT = (1ULL << 6),
> >> /** Set if the output data uses FP16 format. */
> >> - RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7)
> >> + RTE_BBDEV_FFT_FP16_OUTPUT = (1ULL << 7),
> >> + /** Flexible adjustment of Timing offset adjustment per CS. */
> >> + RTE_BBDEV_FFT_TIMING_OFFSET_PER_CS = (1ULL << 8),
> >> + /** Flexible adjustment of Timing error correction per CS. */
> >> + RTE_BBDEV_FFT_TIMING_ERROR = (1ULL << 9),
> >> + /** Set for optional frequency domain dewindowing. */
> >> + RTE_BBDEV_FFT_DEWINDOWING = (1ULL << 10),
> >> + /** Flexible adjustment of frequency resampling mode. */
> >> + RTE_BBDEV_FFT_FREQ_RESAMPLING = (1ULL << 11)
> >> };
> >> /** Flags for MLDTS operation and capability structure */ @@ -756,6
> >> +765,8 @@ struct rte_bbdev_op_fft {
> >> struct rte_bbdev_op_data base_input;
> >> /** Output data starting from first antenna and first cyclic
> >> shift. */
> >> struct rte_bbdev_op_data base_output;
> >> + /** Optional frequency window input data. */
> >> + struct rte_bbdev_op_data dewindowing_input;
> >> /** Optional power measurement output data. */
> >> struct rte_bbdev_op_data power_meas_output;
> >> /** Flags from rte_bbdev_op_fft_flag_bitmasks. */ @@ -790,6
> >> +801,16 @@ struct rte_bbdev_op_fft {
> >> uint16_t power_shift;
> >> /** Adjust the FP6 exponent for INT<->FP16 conversion. */
> >> uint16_t fp16_exp_adjust;
> >> + /** Frequency resampling : 0: Transparent Mode1: 4/3 Resample2:
> >> 2/3 Resample. */
> >> + int8_t freq_resample_mode;
> >> + /** Output depadded size prior to frequency resampling. */
> >> + uint16_t output_depadded_size;
> >> + /** Time error correction initial phase. */
> >> + uint16_t cs_theta_0[RTE_BBDEV_MAX_CS];
> >> + /** Time error correction phase increment. */
> >> + uint32_t cs_theta_d[RTE_BBDEV_MAX_CS];
> >> + /* Time offset per CS of time domain samples. */
> >> + int8_t time_offset[RTE_BBDEV_MAX_CS];
> >> };
> >> /* >8 End of structure rte_bbdev_op_fft. */
> >
> > I think you need to document ABI change in:
> > doc/guides/rel_notes/release_23_11.rst
>
> Nevermind, I forgot the FFT API was still experimental.
> No need to submit a new revision, I will fix the typos in patch 5.
>
> Maxime
>
> > Once done, please add my:
> > Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> >
> > Maxime
> >
> >
^ permalink raw reply [relevance 0%]
* [PATCH v5 02/26] net/nfp: unify the indent coding style
@ 2023-09-19 9:54 1% ` Chaoyong He
2023-09-19 9:54 3% ` [PATCH v5 05/26] net/nfp: standard the local variable " Chaoyong He
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-09-19 9:54 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Chaoyong He
Each parameter of function should occupy one line, and indent two TAB
character.
All the statement which span multi line should indent two TAB character.
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
---
drivers/net/nfp/nfpcore/nfp_cpp.h | 80 +++++-----
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 152 ++++++++++--------
drivers/net/nfp/nfpcore/nfp_cppcore.c | 173 +++++++++++++--------
drivers/net/nfp/nfpcore/nfp_crc.c | 19 ++-
drivers/net/nfp/nfpcore/nfp_hwinfo.c | 23 +--
drivers/net/nfp/nfpcore/nfp_mip.c | 21 ++-
drivers/net/nfp/nfpcore/nfp_mip.h | 2 +-
drivers/net/nfp/nfpcore/nfp_mutex.c | 25 +--
drivers/net/nfp/nfpcore/nfp_nffw.c | 12 +-
drivers/net/nfp/nfpcore/nfp_nsp.c | 108 +++++++------
drivers/net/nfp/nfpcore/nfp_nsp.h | 19 +--
drivers/net/nfp/nfpcore/nfp_nsp_cmds.c | 4 +-
drivers/net/nfp/nfpcore/nfp_nsp_eth.c | 72 +++++----
drivers/net/nfp/nfpcore/nfp_resource.c | 29 ++--
drivers/net/nfp/nfpcore/nfp_resource.h | 2 +-
drivers/net/nfp/nfpcore/nfp_rtsym.c | 38 +++--
drivers/net/nfp/nfpcore/nfp_rtsym.h | 15 +-
17 files changed, 463 insertions(+), 331 deletions(-)
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp.h b/drivers/net/nfp/nfpcore/nfp_cpp.h
index 8f87c09327..54bef3cb6b 100644
--- a/drivers/net/nfp/nfpcore/nfp_cpp.h
+++ b/drivers/net/nfp/nfpcore/nfp_cpp.h
@@ -56,7 +56,8 @@ struct nfp_cpp_operations {
size_t area_priv_size;
/* Instance an NFP CPP */
- int (*init)(struct nfp_cpp *cpp, struct rte_pci_device *dev);
+ int (*init)(struct nfp_cpp *cpp,
+ struct rte_pci_device *dev);
/*
* Free the bus.
@@ -69,9 +70,9 @@ struct nfp_cpp_operations {
* NOTE: This is _not_ serialized
*/
int (*area_init)(struct nfp_cpp_area *area,
- uint32_t dest,
- unsigned long long address,
- unsigned long size);
+ uint32_t dest,
+ unsigned long long address,
+ unsigned long size);
/*
* Clean up a NFP CPP area before it is freed
* NOTE: This is _not_ serialized
@@ -101,17 +102,17 @@ struct nfp_cpp_operations {
* Serialized
*/
int (*area_read)(struct nfp_cpp_area *area,
- void *kernel_vaddr,
- unsigned long offset,
- unsigned int length);
+ void *kernel_vaddr,
+ unsigned long offset,
+ unsigned int length);
/*
* Perform a write to a NFP CPP area
* Serialized
*/
int (*area_write)(struct nfp_cpp_area *area,
- const void *kernel_vaddr,
- unsigned long offset,
- unsigned int length);
+ const void *kernel_vaddr,
+ unsigned long offset,
+ unsigned int length);
};
/*
@@ -239,7 +240,7 @@ void nfp_cpp_interface_set(struct nfp_cpp *cpp, uint32_t interface);
* @param len Length of the serial byte array
*/
int nfp_cpp_serial_set(struct nfp_cpp *cpp, const uint8_t *serial,
- size_t serial_len);
+ size_t serial_len);
/*
* Set the private data of the nfp_cpp instance
@@ -279,7 +280,7 @@ uint32_t __nfp_cpp_model_autodetect(struct nfp_cpp *cpp, uint32_t *model);
* @return NFP CPP handle, or NULL on failure.
*/
struct nfp_cpp *nfp_cpp_from_device_name(struct rte_pci_device *dev,
- int driver_lock_needed);
+ int driver_lock_needed);
/*
* Free a NFP CPP handle
@@ -397,8 +398,7 @@ int nfp_cpp_serial(struct nfp_cpp *cpp, const uint8_t **serial);
* @return NFP CPP handle, or NULL on failure.
*/
struct nfp_cpp_area *nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address,
- unsigned long size);
+ unsigned long long address, unsigned long size);
/*
* Allocate a NFP CPP area handle, as an offset into a CPP ID, by a named owner
@@ -411,10 +411,8 @@ struct nfp_cpp_area *nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return NFP CPP handle, or NULL on failure.
*/
struct nfp_cpp_area *nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
- uint32_t cpp_id,
- const char *name,
- unsigned long long address,
- unsigned long size);
+ uint32_t cpp_id, const char *name, unsigned long long address,
+ unsigned long size);
/*
* Free an allocated NFP CPP area handle
@@ -448,9 +446,7 @@ void nfp_cpp_area_release(struct nfp_cpp_area *area);
* @return NFP CPP handle, or NULL on failure.
*/
struct nfp_cpp_area *nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp,
- uint32_t cpp_id,
- unsigned long long address,
- unsigned long size);
+ uint32_t cpp_id, unsigned long long address, unsigned long size);
/*
* Release the resources, then free the NFP CPP area handle
@@ -459,8 +455,7 @@ struct nfp_cpp_area *nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp,
void nfp_cpp_area_release_free(struct nfp_cpp_area *area);
uint8_t *nfp_cpp_map_area(struct nfp_cpp *cpp, uint32_t cpp_id,
- uint64_t addr, unsigned long size,
- struct nfp_cpp_area **area);
+ uint64_t addr, unsigned long size, struct nfp_cpp_area **area);
/*
* Return an IO pointer to the beginning of the NFP CPP area handle. The area
* must be acquired with 'nfp_cpp_area_acquire()' before calling this operation.
@@ -484,7 +479,7 @@ void *nfp_cpp_area_mapped(struct nfp_cpp_area *area);
*
*/
int nfp_cpp_area_read(struct nfp_cpp_area *area, unsigned long offset,
- void *buffer, size_t length);
+ void *buffer, size_t length);
/*
* Write to a NFP CPP area handle from a buffer. The area must be acquired with
@@ -498,7 +493,7 @@ int nfp_cpp_area_read(struct nfp_cpp_area *area, unsigned long offset,
* @return bytes written on success, negative value on failure.
*/
int nfp_cpp_area_write(struct nfp_cpp_area *area, unsigned long offset,
- const void *buffer, size_t length);
+ const void *buffer, size_t length);
/*
* nfp_cpp_area_iomem() - get IOMEM region for CPP area
@@ -522,7 +517,7 @@ void *nfp_cpp_area_iomem(struct nfp_cpp_area *area);
* @return 0 on success, negative value on failure.
*/
int nfp_cpp_area_check_range(struct nfp_cpp_area *area,
- unsigned long long offset, unsigned long size);
+ unsigned long long offset, unsigned long size);
/*
* Get the NFP CPP handle that is the parent of a NFP CPP area handle
@@ -552,7 +547,7 @@ const char *nfp_cpp_area_name(struct nfp_cpp_area *cpp_area);
* @return bytes read on success, -1 on failure.
*/
int nfp_cpp_read(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, void *kernel_vaddr, size_t length);
+ unsigned long long address, void *kernel_vaddr, size_t length);
/*
* Write a block of data to a NFP CPP ID
@@ -566,8 +561,8 @@ int nfp_cpp_read(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return bytes written on success, -1 on failure.
*/
int nfp_cpp_write(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, const void *kernel_vaddr,
- size_t length);
+ unsigned long long address, const void *kernel_vaddr,
+ size_t length);
@@ -582,7 +577,7 @@ int nfp_cpp_write(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return bytes written on success, negative value on failure.
*/
int nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t value, size_t length);
+ uint32_t value, size_t length);
/*
* Read a single 32-bit value from a NFP CPP area handle
@@ -599,7 +594,7 @@ int nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
* @return 0 on success, or -1 on error.
*/
int nfp_cpp_area_readl(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t *value);
+ uint32_t *value);
/*
* Write a single 32-bit value to a NFP CPP area handle
@@ -616,7 +611,7 @@ int nfp_cpp_area_readl(struct nfp_cpp_area *area, unsigned long offset,
* @return 0 on success, or -1 on error.
*/
int nfp_cpp_area_writel(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t value);
+ uint32_t value);
/*
* Read a single 64-bit value from a NFP CPP area handle
@@ -633,7 +628,7 @@ int nfp_cpp_area_writel(struct nfp_cpp_area *area, unsigned long offset,
* @return 0 on success, or -1 on error.
*/
int nfp_cpp_area_readq(struct nfp_cpp_area *area, unsigned long offset,
- uint64_t *value);
+ uint64_t *value);
/*
* Write a single 64-bit value to a NFP CPP area handle
@@ -650,7 +645,7 @@ int nfp_cpp_area_readq(struct nfp_cpp_area *area, unsigned long offset,
* @return 0 on success, or -1 on error.
*/
int nfp_cpp_area_writeq(struct nfp_cpp_area *area, unsigned long offset,
- uint64_t value);
+ uint64_t value);
/*
* Write a single 32-bit value on the XPB bus
@@ -685,7 +680,7 @@ int nfp_xpb_readl(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t *value);
* @return 0 on success, or -1 on failure.
*/
int nfp_xpb_writelm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
- uint32_t value);
+ uint32_t value);
/*
* Modify bits of a 32-bit value from the XPB bus
@@ -699,7 +694,7 @@ int nfp_xpb_writelm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
* @return >= 0 on success, negative value on failure.
*/
int nfp_xpb_waitlm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
- uint32_t value, int timeout_us);
+ uint32_t value, int timeout_us);
/*
* Read a 32-bit word from a NFP CPP ID
@@ -712,7 +707,7 @@ int nfp_xpb_waitlm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
* @return 0 on success, or -1 on failure.
*/
int nfp_cpp_readl(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, uint32_t *value);
+ unsigned long long address, uint32_t *value);
/*
* Write a 32-bit value to a NFP CPP ID
@@ -726,7 +721,7 @@ int nfp_cpp_readl(struct nfp_cpp *cpp, uint32_t cpp_id,
*
*/
int nfp_cpp_writel(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, uint32_t value);
+ unsigned long long address, uint32_t value);
/*
* Read a 64-bit work from a NFP CPP ID
@@ -739,7 +734,7 @@ int nfp_cpp_writel(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return 0 on success, or -1 on failure.
*/
int nfp_cpp_readq(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, uint64_t *value);
+ unsigned long long address, uint64_t *value);
/*
* Write a 64-bit value to a NFP CPP ID
@@ -752,7 +747,7 @@ int nfp_cpp_readq(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return 0 on success, or -1 on failure.
*/
int nfp_cpp_writeq(struct nfp_cpp *cpp, uint32_t cpp_id,
- unsigned long long address, uint64_t value);
+ unsigned long long address, uint64_t value);
/*
* Initialize a mutex location
@@ -773,7 +768,7 @@ int nfp_cpp_writeq(struct nfp_cpp *cpp, uint32_t cpp_id,
* @return 0 on success, negative value on failure.
*/
int nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target,
- unsigned long long address, uint32_t key_id);
+ unsigned long long address, uint32_t key_id);
/*
* Create a mutex handle from an address controlled by a MU Atomic engine
@@ -793,8 +788,7 @@ int nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target,
* failure.
*/
struct nfp_cpp_mutex *nfp_cpp_mutex_alloc(struct nfp_cpp *cpp, int target,
- unsigned long long address,
- uint32_t key_id);
+ unsigned long long address, uint32_t key_id);
/*
* Get the NFP CPP handle the mutex was created with
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
index 2ee60eefc3..884cc84eaa 100644
--- a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
+++ b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
@@ -130,9 +130,15 @@ nfp_bar_maptype(struct nfp_bar *bar)
#define TARGET_WIDTH_64 8
static int
-nfp_compute_bar(const struct nfp_bar *bar, uint32_t *bar_config,
- uint64_t *bar_base, int tgt, int act, int tok,
- uint64_t offset, size_t size, int width)
+nfp_compute_bar(const struct nfp_bar *bar,
+ uint32_t *bar_config,
+ uint64_t *bar_base,
+ int tgt,
+ int act,
+ int tok,
+ uint64_t offset,
+ size_t size,
+ int width)
{
uint32_t bitsize;
uint32_t newcfg;
@@ -143,19 +149,16 @@ nfp_compute_bar(const struct nfp_bar *bar, uint32_t *bar_config,
switch (width) {
case 8:
- newcfg =
- NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
- (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_64BIT);
+ newcfg = NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
+ (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_64BIT);
break;
case 4:
- newcfg =
- NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
- (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_32BIT);
+ newcfg = NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
+ (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_32BIT);
break;
case 0:
- newcfg =
- NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
- (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_0BYTE);
+ newcfg = NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT
+ (NFP_PCIE_BAR_PCIE2CPP_LENGTHSELECT_0BYTE);
break;
default:
return -EINVAL;
@@ -165,60 +168,58 @@ nfp_compute_bar(const struct nfp_bar *bar, uint32_t *bar_config,
/* Fixed CPP mapping with specific action */
mask = ~(NFP_PCIE_P2C_FIXED_SIZE(bar) - 1);
- newcfg |=
- NFP_PCIE_BAR_PCIE2CPP_MAPTYPE
- (NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_FIXED);
+ newcfg |= NFP_PCIE_BAR_PCIE2CPP_MAPTYPE
+ (NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_FIXED);
newcfg |= NFP_PCIE_BAR_PCIE2CPP_TARGET_BASEADDRESS(tgt);
newcfg |= NFP_PCIE_BAR_PCIE2CPP_ACTION_BASEADDRESS(act);
newcfg |= NFP_PCIE_BAR_PCIE2CPP_TOKEN_BASEADDRESS(tok);
if ((offset & mask) != ((offset + size - 1) & mask)) {
PMD_DRV_LOG(ERR, "BAR%d: Won't use for Fixed mapping <%#llx,%#llx>, action=%d BAR too small (0x%llx)",
- bar->index, (unsigned long long)offset,
- (unsigned long long)(offset + size), act,
- (unsigned long long)mask);
+ bar->index, (unsigned long long)offset,
+ (unsigned long long)(offset + size), act,
+ (unsigned long long)mask);
return -EINVAL;
}
offset &= mask;
PMD_DRV_LOG(DEBUG, "BAR%d: Created Fixed mapping %d:%d:%d:0x%#llx-0x%#llx>",
- bar->index, tgt, act, tok, (unsigned long long)offset,
- (unsigned long long)(offset + mask));
+ bar->index, tgt, act, tok, (unsigned long long)offset,
+ (unsigned long long)(offset + mask));
bitsize = 40 - 16;
} else {
mask = ~(NFP_PCIE_P2C_BULK_SIZE(bar) - 1);
/* Bulk mapping */
- newcfg |=
- NFP_PCIE_BAR_PCIE2CPP_MAPTYPE
- (NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_BULK);
+ newcfg |= NFP_PCIE_BAR_PCIE2CPP_MAPTYPE
+ (NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_BULK);
newcfg |= NFP_PCIE_BAR_PCIE2CPP_TARGET_BASEADDRESS(tgt);
newcfg |= NFP_PCIE_BAR_PCIE2CPP_TOKEN_BASEADDRESS(tok);
if ((offset & mask) != ((offset + size - 1) & mask)) {
PMD_DRV_LOG(ERR, "BAR%d: Won't use for bulk mapping <%#llx,%#llx> target=%d, token=%d BAR too small (%#llx) - (%#llx != %#llx).",
- bar->index, (unsigned long long)offset,
- (unsigned long long)(offset + size),
- tgt, tok, (unsigned long long)mask,
- (unsigned long long)(offset & mask),
- (unsigned long long)(offset + size - 1) & mask);
+ bar->index, (unsigned long long)offset,
+ (unsigned long long)(offset + size),
+ tgt, tok, (unsigned long long)mask,
+ (unsigned long long)(offset & mask),
+ (unsigned long long)(offset + size - 1) & mask);
return -EINVAL;
}
offset &= mask;
PMD_DRV_LOG(DEBUG, "BAR%d: Created bulk mapping %d:x:%d:%#llx-%#llx",
- bar->index, tgt, tok, (unsigned long long)offset,
- (unsigned long long)(offset + ~mask));
+ bar->index, tgt, tok, (unsigned long long)offset,
+ (unsigned long long)(offset + ~mask));
bitsize = 40 - 21;
}
if (bar->bitsize < bitsize) {
PMD_DRV_LOG(ERR, "BAR%d: Too small for %d:%d:%d", bar->index,
- tgt, tok, act);
+ tgt, tok, act);
return -EINVAL;
}
@@ -234,8 +235,9 @@ nfp_compute_bar(const struct nfp_bar *bar, uint32_t *bar_config,
}
static int
-nfp_bar_write(struct nfp_pcie_user *nfp, struct nfp_bar *bar,
- uint32_t newcfg)
+nfp_bar_write(struct nfp_pcie_user *nfp,
+ struct nfp_bar *bar,
+ uint32_t newcfg)
{
int base, slot;
@@ -246,7 +248,7 @@ nfp_bar_write(struct nfp_pcie_user *nfp, struct nfp_bar *bar,
return (-ENOMEM);
bar->csr = nfp->cfg +
- NFP_PCIE_CFG_BAR_PCIETOCPPEXPBAR(nfp->dev_id, base, slot);
+ NFP_PCIE_CFG_BAR_PCIETOCPPEXPBAR(nfp->dev_id, base, slot);
*(uint32_t *)(bar->csr) = newcfg;
@@ -257,15 +259,21 @@ nfp_bar_write(struct nfp_pcie_user *nfp, struct nfp_bar *bar,
}
static int
-nfp_reconfigure_bar(struct nfp_pcie_user *nfp, struct nfp_bar *bar, int tgt,
- int act, int tok, uint64_t offset, size_t size, int width)
+nfp_reconfigure_bar(struct nfp_pcie_user *nfp,
+ struct nfp_bar *bar,
+ int tgt,
+ int act,
+ int tok,
+ uint64_t offset,
+ size_t size,
+ int width)
{
uint64_t newbase;
uint32_t newcfg;
int err;
err = nfp_compute_bar(bar, &newcfg, &newbase, tgt, act, tok, offset,
- size, width);
+ size, width);
if (err != 0)
return err;
@@ -390,8 +398,10 @@ struct nfp6000_area_priv {
};
static int
-nfp6000_area_init(struct nfp_cpp_area *area, uint32_t dest,
- unsigned long long address, unsigned long size)
+nfp6000_area_init(struct nfp_cpp_area *area,
+ uint32_t dest,
+ unsigned long long address,
+ unsigned long size)
{
struct nfp_pcie_user *nfp = nfp_cpp_priv(nfp_cpp_area_cpp(area));
struct nfp6000_area_priv *priv = nfp_cpp_area_priv(area);
@@ -400,8 +410,7 @@ nfp6000_area_init(struct nfp_cpp_area *area, uint32_t dest,
uint32_t token = NFP_CPP_ID_TOKEN_of(dest);
int pp, ret = 0;
- pp = nfp_target_pushpull(NFP_CPP_ID(target, action, token),
- address);
+ pp = nfp_target_pushpull(NFP_CPP_ID(target, action, token), address);
if (pp < 0)
return pp;
@@ -409,7 +418,8 @@ nfp6000_area_init(struct nfp_cpp_area *area, uint32_t dest,
priv->width.write = PULL_WIDTH(pp);
if (priv->width.read > 0 &&
- priv->width.write > 0 && priv->width.read != priv->width.write)
+ priv->width.write > 0 &&
+ priv->width.read != priv->width.write)
return -EINVAL;
if (priv->width.read > 0)
@@ -428,8 +438,8 @@ nfp6000_area_init(struct nfp_cpp_area *area, uint32_t dest,
priv->size = size;
ret = nfp_reconfigure_bar(nfp, priv->bar, priv->target, priv->action,
- priv->token, priv->offset, priv->size,
- priv->width.bar);
+ priv->token, priv->offset, priv->size,
+ priv->width.bar);
return ret;
}
@@ -441,14 +451,13 @@ nfp6000_area_acquire(struct nfp_cpp_area *area)
/* Calculate offset into BAR. */
if (nfp_bar_maptype(priv->bar) ==
- NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_GENERAL) {
+ NFP_PCIE_BAR_PCIE2CPP_MAPTYPE_GENERAL) {
priv->bar_offset = priv->offset &
- (NFP_PCIE_P2C_GENERAL_SIZE(priv->bar) - 1);
- priv->bar_offset +=
- NFP_PCIE_P2C_GENERAL_TARGET_OFFSET(priv->bar,
- priv->target);
- priv->bar_offset +=
- NFP_PCIE_P2C_GENERAL_TOKEN_OFFSET(priv->bar, priv->token);
+ (NFP_PCIE_P2C_GENERAL_SIZE(priv->bar) - 1);
+ priv->bar_offset += NFP_PCIE_P2C_GENERAL_TARGET_OFFSET(priv->bar,
+ priv->target);
+ priv->bar_offset += NFP_PCIE_P2C_GENERAL_TOKEN_OFFSET(priv->bar,
+ priv->token);
} else {
priv->bar_offset = priv->offset & priv->bar->mask;
}
@@ -490,8 +499,10 @@ nfp6000_area_iomem(struct nfp_cpp_area *area)
}
static int
-nfp6000_area_read(struct nfp_cpp_area *area, void *kernel_vaddr,
- unsigned long offset, unsigned int length)
+nfp6000_area_read(struct nfp_cpp_area *area,
+ void *kernel_vaddr,
+ unsigned long offset,
+ unsigned int length)
{
uint64_t *wrptr64 = kernel_vaddr;
const volatile uint64_t *rdptr64;
@@ -524,17 +535,17 @@ nfp6000_area_read(struct nfp_cpp_area *area, void *kernel_vaddr,
/* MU reads via a PCIe2CPP BAR supports 32bit (and other) lengths */
if (priv->target == (NFP_CPP_TARGET_ID_MASK & NFP_CPP_TARGET_MU) &&
- priv->action == NFP_CPP_ACTION_RW) {
+ priv->action == NFP_CPP_ACTION_RW) {
is_64 = false;
}
if (is_64) {
if (offset % sizeof(uint64_t) != 0 ||
- length % sizeof(uint64_t) != 0)
+ length % sizeof(uint64_t) != 0)
return -EINVAL;
} else {
if (offset % sizeof(uint32_t) != 0 ||
- length % sizeof(uint32_t) != 0)
+ length % sizeof(uint32_t) != 0)
return -EINVAL;
}
@@ -558,8 +569,10 @@ nfp6000_area_read(struct nfp_cpp_area *area, void *kernel_vaddr,
}
static int
-nfp6000_area_write(struct nfp_cpp_area *area, const void *kernel_vaddr,
- unsigned long offset, unsigned int length)
+nfp6000_area_write(struct nfp_cpp_area *area,
+ const void *kernel_vaddr,
+ unsigned long offset,
+ unsigned int length)
{
const uint64_t *rdptr64 = kernel_vaddr;
uint64_t *wrptr64;
@@ -590,16 +603,16 @@ nfp6000_area_write(struct nfp_cpp_area *area, const void *kernel_vaddr,
/* MU writes via a PCIe2CPP BAR supports 32bit (and other) lengths */
if (priv->target == (NFP_CPP_TARGET_ID_MASK & NFP_CPP_TARGET_MU) &&
- priv->action == NFP_CPP_ACTION_RW)
+ priv->action == NFP_CPP_ACTION_RW)
is_64 = false;
if (is_64) {
if (offset % sizeof(uint64_t) != 0 ||
- length % sizeof(uint64_t) != 0)
+ length % sizeof(uint64_t) != 0)
return -EINVAL;
} else {
if (offset % sizeof(uint32_t) != 0 ||
- length % sizeof(uint32_t) != 0)
+ length % sizeof(uint32_t) != 0)
return -EINVAL;
}
@@ -655,7 +668,8 @@ nfp_acquire_process_lock(struct nfp_pcie_user *desc)
}
static int
-nfp6000_set_model(struct rte_pci_device *dev, struct nfp_cpp *cpp)
+nfp6000_set_model(struct rte_pci_device *dev,
+ struct nfp_cpp *cpp)
{
uint32_t model;
@@ -671,7 +685,8 @@ nfp6000_set_model(struct rte_pci_device *dev, struct nfp_cpp *cpp)
}
static int
-nfp6000_set_interface(struct rte_pci_device *dev, struct nfp_cpp *cpp)
+nfp6000_set_interface(struct rte_pci_device *dev,
+ struct nfp_cpp *cpp)
{
uint16_t interface;
@@ -686,7 +701,8 @@ nfp6000_set_interface(struct rte_pci_device *dev, struct nfp_cpp *cpp)
}
static int
-nfp6000_set_serial(struct rte_pci_device *dev, struct nfp_cpp *cpp)
+nfp6000_set_serial(struct rte_pci_device *dev,
+ struct nfp_cpp *cpp)
{
uint16_t tmp;
uint8_t serial[6];
@@ -733,7 +749,8 @@ nfp6000_set_serial(struct rte_pci_device *dev, struct nfp_cpp *cpp)
}
static int
-nfp6000_set_barsz(struct rte_pci_device *dev, struct nfp_pcie_user *desc)
+nfp6000_set_barsz(struct rte_pci_device *dev,
+ struct nfp_pcie_user *desc)
{
unsigned long tmp;
int i = 0;
@@ -748,7 +765,8 @@ nfp6000_set_barsz(struct rte_pci_device *dev, struct nfp_pcie_user *desc)
}
static int
-nfp6000_init(struct nfp_cpp *cpp, struct rte_pci_device *dev)
+nfp6000_init(struct nfp_cpp *cpp,
+ struct rte_pci_device *dev)
{
int ret = 0;
struct nfp_pcie_user *desc;
@@ -762,7 +780,7 @@ nfp6000_init(struct nfp_cpp *cpp, struct rte_pci_device *dev)
strlcpy(desc->busdev, dev->device.name, sizeof(desc->busdev));
if (rte_eal_process_type() == RTE_PROC_PRIMARY &&
- cpp->driver_lock_needed) {
+ cpp->driver_lock_needed) {
ret = nfp_acquire_process_lock(desc);
if (ret != 0)
goto error;
diff --git a/drivers/net/nfp/nfpcore/nfp_cppcore.c b/drivers/net/nfp/nfpcore/nfp_cppcore.c
index 31338e0047..f764208a9a 100644
--- a/drivers/net/nfp/nfpcore/nfp_cppcore.c
+++ b/drivers/net/nfp/nfpcore/nfp_cppcore.c
@@ -27,7 +27,8 @@
NFP_PL_DEVICE_ID_MASK)
void
-nfp_cpp_priv_set(struct nfp_cpp *cpp, void *priv)
+nfp_cpp_priv_set(struct nfp_cpp *cpp,
+ void *priv)
{
cpp->priv = priv;
}
@@ -39,7 +40,8 @@ nfp_cpp_priv(struct nfp_cpp *cpp)
}
void
-nfp_cpp_model_set(struct nfp_cpp *cpp, uint32_t model)
+nfp_cpp_model_set(struct nfp_cpp *cpp,
+ uint32_t model)
{
cpp->model = model;
}
@@ -62,21 +64,24 @@ nfp_cpp_model(struct nfp_cpp *cpp)
}
void
-nfp_cpp_interface_set(struct nfp_cpp *cpp, uint32_t interface)
+nfp_cpp_interface_set(struct nfp_cpp *cpp,
+ uint32_t interface)
{
cpp->interface = interface;
}
int
-nfp_cpp_serial(struct nfp_cpp *cpp, const uint8_t **serial)
+nfp_cpp_serial(struct nfp_cpp *cpp,
+ const uint8_t **serial)
{
*serial = cpp->serial;
return cpp->serial_len;
}
int
-nfp_cpp_serial_set(struct nfp_cpp *cpp, const uint8_t *serial,
- size_t serial_len)
+nfp_cpp_serial_set(struct nfp_cpp *cpp,
+ const uint8_t *serial,
+ size_t serial_len)
{
if (cpp->serial_len)
free(cpp->serial);
@@ -161,9 +166,11 @@ nfp_cpp_mu_locality_lsb(struct nfp_cpp *cpp)
* NOTE: @address and @size must be 32-bit aligned values.
*/
struct nfp_cpp_area *
-nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp, uint32_t dest,
- const char *name, unsigned long long address,
- unsigned long size)
+nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
+ uint32_t dest,
+ const char *name,
+ unsigned long long address,
+ unsigned long size)
{
struct nfp_cpp_area *area;
uint64_t tmp64 = (uint64_t)address;
@@ -183,7 +190,7 @@ nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp, uint32_t dest,
name = "";
area = calloc(1, sizeof(*area) + cpp->op->area_priv_size +
- strlen(name) + 1);
+ strlen(name) + 1);
if (area == NULL)
return NULL;
@@ -204,8 +211,10 @@ nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp, uint32_t dest,
}
struct nfp_cpp_area *
-nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t dest,
- unsigned long long address, unsigned long size)
+nfp_cpp_area_alloc(struct nfp_cpp *cpp,
+ uint32_t dest,
+ unsigned long long address,
+ unsigned long size)
{
return nfp_cpp_area_alloc_with_name(cpp, dest, NULL, address, size);
}
@@ -226,8 +235,10 @@ nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t dest,
* NOTE: The area must also be 'released' when the structure is freed.
*/
struct nfp_cpp_area *
-nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp, uint32_t destination,
- unsigned long long address, unsigned long size)
+nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp,
+ uint32_t destination,
+ unsigned long long address,
+ unsigned long size)
{
struct nfp_cpp_area *area;
@@ -340,8 +351,10 @@ nfp_cpp_area_iomem(struct nfp_cpp_area *area)
* NOTE: Area must have been locked down with an 'acquire'.
*/
int
-nfp_cpp_area_read(struct nfp_cpp_area *area, unsigned long offset,
- void *kernel_vaddr, size_t length)
+nfp_cpp_area_read(struct nfp_cpp_area *area,
+ unsigned long offset,
+ void *kernel_vaddr,
+ size_t length)
{
if ((offset + length) > area->size)
return -EFAULT;
@@ -364,8 +377,10 @@ nfp_cpp_area_read(struct nfp_cpp_area *area, unsigned long offset,
* NOTE: Area must have been locked down with an 'acquire'.
*/
int
-nfp_cpp_area_write(struct nfp_cpp_area *area, unsigned long offset,
- const void *kernel_vaddr, size_t length)
+nfp_cpp_area_write(struct nfp_cpp_area *area,
+ unsigned long offset,
+ const void *kernel_vaddr,
+ size_t length)
{
if ((offset + length) > area->size)
return -EFAULT;
@@ -392,8 +407,9 @@ nfp_cpp_area_mapped(struct nfp_cpp_area *area)
* or negative value on error.
*/
int
-nfp_cpp_area_check_range(struct nfp_cpp_area *area, unsigned long long offset,
- unsigned long length)
+nfp_cpp_area_check_range(struct nfp_cpp_area *area,
+ unsigned long long offset,
+ unsigned long length)
{
if (((offset + length) > area->size))
return -EFAULT;
@@ -406,7 +422,8 @@ nfp_cpp_area_check_range(struct nfp_cpp_area *area, unsigned long long offset,
* based upon NFP model.
*/
static uint32_t
-nfp_xpb_to_cpp(struct nfp_cpp *cpp, uint32_t *xpb_addr)
+nfp_xpb_to_cpp(struct nfp_cpp *cpp,
+ uint32_t *xpb_addr)
{
uint32_t xpb;
int island;
@@ -433,7 +450,7 @@ nfp_xpb_to_cpp(struct nfp_cpp *cpp, uint32_t *xpb_addr)
else
/* And only non-ARM interfaces use island id = 1 */
if (NFP_CPP_INTERFACE_TYPE_of(nfp_cpp_interface(cpp)) !=
- NFP_CPP_INTERFACE_TYPE_ARM)
+ NFP_CPP_INTERFACE_TYPE_ARM)
*xpb_addr |= (1 << 24);
} else {
(*xpb_addr) |= (1 << 30);
@@ -443,8 +460,9 @@ nfp_xpb_to_cpp(struct nfp_cpp *cpp, uint32_t *xpb_addr)
}
int
-nfp_cpp_area_readl(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t *value)
+nfp_cpp_area_readl(struct nfp_cpp_area *area,
+ unsigned long offset,
+ uint32_t *value)
{
int sz;
uint32_t tmp = 0;
@@ -456,8 +474,9 @@ nfp_cpp_area_readl(struct nfp_cpp_area *area, unsigned long offset,
}
int
-nfp_cpp_area_writel(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t value)
+nfp_cpp_area_writel(struct nfp_cpp_area *area,
+ unsigned long offset,
+ uint32_t value)
{
int sz;
@@ -467,8 +486,9 @@ nfp_cpp_area_writel(struct nfp_cpp_area *area, unsigned long offset,
}
int
-nfp_cpp_area_readq(struct nfp_cpp_area *area, unsigned long offset,
- uint64_t *value)
+nfp_cpp_area_readq(struct nfp_cpp_area *area,
+ unsigned long offset,
+ uint64_t *value)
{
int sz;
uint64_t tmp = 0;
@@ -480,8 +500,9 @@ nfp_cpp_area_readq(struct nfp_cpp_area *area, unsigned long offset,
}
int
-nfp_cpp_area_writeq(struct nfp_cpp_area *area, unsigned long offset,
- uint64_t value)
+nfp_cpp_area_writeq(struct nfp_cpp_area *area,
+ unsigned long offset,
+ uint64_t value)
{
int sz;
@@ -492,8 +513,10 @@ nfp_cpp_area_writeq(struct nfp_cpp_area *area, unsigned long offset,
}
int
-nfp_cpp_readl(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
- uint32_t *value)
+nfp_cpp_readl(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ unsigned long long address,
+ uint32_t *value)
{
int sz;
uint32_t tmp;
@@ -505,8 +528,10 @@ nfp_cpp_readl(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
}
int
-nfp_cpp_writel(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
- uint32_t value)
+nfp_cpp_writel(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ unsigned long long address,
+ uint32_t value)
{
int sz;
@@ -517,8 +542,10 @@ nfp_cpp_writel(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
}
int
-nfp_cpp_readq(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
- uint64_t *value)
+nfp_cpp_readq(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ unsigned long long address,
+ uint64_t *value)
{
int sz;
uint64_t tmp;
@@ -530,8 +557,10 @@ nfp_cpp_readq(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
}
int
-nfp_cpp_writeq(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
- uint64_t value)
+nfp_cpp_writeq(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ unsigned long long address,
+ uint64_t value)
{
int sz;
@@ -542,7 +571,9 @@ nfp_cpp_writeq(struct nfp_cpp *cpp, uint32_t cpp_id, unsigned long long address,
}
int
-nfp_xpb_writel(struct nfp_cpp *cpp, uint32_t xpb_addr, uint32_t value)
+nfp_xpb_writel(struct nfp_cpp *cpp,
+ uint32_t xpb_addr,
+ uint32_t value)
{
uint32_t cpp_dest;
@@ -552,7 +583,9 @@ nfp_xpb_writel(struct nfp_cpp *cpp, uint32_t xpb_addr, uint32_t value)
}
int
-nfp_xpb_readl(struct nfp_cpp *cpp, uint32_t xpb_addr, uint32_t *value)
+nfp_xpb_readl(struct nfp_cpp *cpp,
+ uint32_t xpb_addr,
+ uint32_t *value)
{
uint32_t cpp_dest;
@@ -562,7 +595,8 @@ nfp_xpb_readl(struct nfp_cpp *cpp, uint32_t xpb_addr, uint32_t *value)
}
static struct nfp_cpp *
-nfp_cpp_alloc(struct rte_pci_device *dev, int driver_lock_needed)
+nfp_cpp_alloc(struct rte_pci_device *dev,
+ int driver_lock_needed)
{
const struct nfp_cpp_operations *ops;
struct nfp_cpp *cpp;
@@ -596,7 +630,7 @@ nfp_cpp_alloc(struct rte_pci_device *dev, int driver_lock_needed)
/* Hardcoded XPB IMB Base, island 0 */
xpbaddr = 0x000a0000 + (tgt * 4);
err = nfp_xpb_readl(cpp, xpbaddr,
- (uint32_t *)&cpp->imb_cat_table[tgt]);
+ (uint32_t *)&cpp->imb_cat_table[tgt]);
if (err < 0) {
free(cpp);
return NULL;
@@ -631,7 +665,8 @@ nfp_cpp_free(struct nfp_cpp *cpp)
}
struct nfp_cpp *
-nfp_cpp_from_device_name(struct rte_pci_device *dev, int driver_lock_needed)
+nfp_cpp_from_device_name(struct rte_pci_device *dev,
+ int driver_lock_needed)
{
return nfp_cpp_alloc(dev, driver_lock_needed);
}
@@ -647,7 +682,9 @@ nfp_cpp_from_device_name(struct rte_pci_device *dev, int driver_lock_needed)
* @return 0 on success, or -1 on failure.
*/
int
-nfp_xpb_writelm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
+nfp_xpb_writelm(struct nfp_cpp *cpp,
+ uint32_t xpb_tgt,
+ uint32_t mask,
uint32_t value)
{
int err;
@@ -674,8 +711,11 @@ nfp_xpb_writelm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
* @return >= 0 on success, or negative value on failure.
*/
int
-nfp_xpb_waitlm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
- uint32_t value, int timeout_us)
+nfp_xpb_waitlm(struct nfp_cpp *cpp,
+ uint32_t xpb_tgt,
+ uint32_t mask,
+ uint32_t value,
+ int timeout_us)
{
uint32_t tmp;
int err;
@@ -716,8 +756,11 @@ nfp_xpb_waitlm(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t mask,
* @length: number of bytes to read
*/
int
-nfp_cpp_read(struct nfp_cpp *cpp, uint32_t destination,
- unsigned long long address, void *kernel_vaddr, size_t length)
+nfp_cpp_read(struct nfp_cpp *cpp,
+ uint32_t destination,
+ unsigned long long address,
+ void *kernel_vaddr,
+ size_t length)
{
struct nfp_cpp_area *area;
int err;
@@ -743,9 +786,11 @@ nfp_cpp_read(struct nfp_cpp *cpp, uint32_t destination,
* @length: number of bytes to write
*/
int
-nfp_cpp_write(struct nfp_cpp *cpp, uint32_t destination,
- unsigned long long address, const void *kernel_vaddr,
- size_t length)
+nfp_cpp_write(struct nfp_cpp *cpp,
+ uint32_t destination,
+ unsigned long long address,
+ const void *kernel_vaddr,
+ size_t length)
{
struct nfp_cpp_area *area;
int err;
@@ -768,8 +813,10 @@ nfp_cpp_write(struct nfp_cpp *cpp, uint32_t destination,
* @length: length of area to fill
*/
int
-nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
- uint32_t value, size_t length)
+nfp_cpp_area_fill(struct nfp_cpp_area *area,
+ unsigned long offset,
+ uint32_t value,
+ size_t length)
{
int err;
size_t i;
@@ -795,9 +842,8 @@ nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
}
for (i = 0; (i + sizeof(value)) < length; i += sizeof(value64)) {
- err =
- nfp_cpp_area_write(area, offset + i, &value64,
- sizeof(value64));
+ err = nfp_cpp_area_write(area, offset + i, &value64,
+ sizeof(value64));
if (err < 0)
return err;
if (err != sizeof(value64))
@@ -805,8 +851,7 @@ nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
}
if ((i + sizeof(value)) <= length) {
- err =
- nfp_cpp_area_write(area, offset + i, &value, sizeof(value));
+ err = nfp_cpp_area_write(area, offset + i, &value, sizeof(value));
if (err < 0)
return err;
if (err != sizeof(value))
@@ -822,13 +867,14 @@ nfp_cpp_area_fill(struct nfp_cpp_area *area, unsigned long offset,
* as those are model-specific
*/
uint32_t
-__nfp_cpp_model_autodetect(struct nfp_cpp *cpp, uint32_t *model)
+__nfp_cpp_model_autodetect(struct nfp_cpp *cpp,
+ uint32_t *model)
{
uint32_t reg;
int err;
err = nfp_xpb_readl(cpp, NFP_XPB_DEVICE(1, 1, 16) + NFP_PL_DEVICE_ID,
- ®);
+ ®);
if (err < 0)
return err;
@@ -853,8 +899,11 @@ __nfp_cpp_model_autodetect(struct nfp_cpp *cpp, uint32_t *model)
* Return: Pointer to memory mapped area or NULL
*/
uint8_t *
-nfp_cpp_map_area(struct nfp_cpp *cpp, uint32_t cpp_id, uint64_t addr,
- unsigned long size, struct nfp_cpp_area **area)
+nfp_cpp_map_area(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ uint64_t addr,
+ unsigned long size,
+ struct nfp_cpp_area **area)
{
uint8_t *res;
diff --git a/drivers/net/nfp/nfpcore/nfp_crc.c b/drivers/net/nfp/nfpcore/nfp_crc.c
index 20431bf845..2cd8866253 100644
--- a/drivers/net/nfp/nfpcore/nfp_crc.c
+++ b/drivers/net/nfp/nfpcore/nfp_crc.c
@@ -9,27 +9,31 @@
#include "nfp_crc.h"
static inline uint32_t
-nfp_crc32_be_generic(uint32_t crc, unsigned char const *p, size_t len,
- uint32_t polynomial)
+nfp_crc32_be_generic(uint32_t crc,
+ unsigned char const *p,
+ size_t len,
+ uint32_t polynomial)
{
int i;
while (len--) {
crc ^= *p++ << 24;
for (i = 0; i < 8; i++)
- crc = (crc << 1) ^ ((crc & 0x80000000) ? polynomial :
- 0);
+ crc = (crc << 1) ^ ((crc & 0x80000000) ? polynomial : 0);
}
return crc;
}
static inline uint32_t
-nfp_crc32_be(uint32_t crc, unsigned char const *p, size_t len)
+nfp_crc32_be(uint32_t crc,
+ unsigned char const *p,
+ size_t len)
{
return nfp_crc32_be_generic(crc, p, len, CRCPOLY_BE);
}
static uint32_t
-nfp_crc32_posix_end(uint32_t crc, size_t total_len)
+nfp_crc32_posix_end(uint32_t crc,
+ size_t total_len)
{
/* Extend with the length of the string. */
while (total_len != 0) {
@@ -43,7 +47,8 @@ nfp_crc32_posix_end(uint32_t crc, size_t total_len)
}
uint32_t
-nfp_crc32_posix(const void *buff, size_t len)
+nfp_crc32_posix(const void *buff,
+ size_t len)
{
return nfp_crc32_posix_end(nfp_crc32_be(0, buff, len), len);
}
diff --git a/drivers/net/nfp/nfpcore/nfp_hwinfo.c b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
index a9d166c4dc..ea4c7d6a9e 100644
--- a/drivers/net/nfp/nfpcore/nfp_hwinfo.c
+++ b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
@@ -33,12 +33,13 @@ nfp_hwinfo_is_updating(struct nfp_hwinfo *hwinfo)
}
static int
-nfp_hwinfo_db_walk(struct nfp_hwinfo *hwinfo, uint32_t size)
+nfp_hwinfo_db_walk(struct nfp_hwinfo *hwinfo,
+ uint32_t size)
{
const char *key, *val, *end = hwinfo->data + size;
for (key = hwinfo->data; *key != 0 && key < end;
- key = val + strlen(val) + 1) {
+ key = val + strlen(val) + 1) {
val = key + strlen(key) + 1;
if (val >= end) {
PMD_DRV_LOG(ERR, "Bad HWINFO - overflowing value");
@@ -54,7 +55,8 @@ nfp_hwinfo_db_walk(struct nfp_hwinfo *hwinfo, uint32_t size)
}
static int
-nfp_hwinfo_db_validate(struct nfp_hwinfo *db, uint32_t len)
+nfp_hwinfo_db_validate(struct nfp_hwinfo *db,
+ uint32_t len)
{
uint32_t size, new_crc, *crc;
@@ -69,7 +71,7 @@ nfp_hwinfo_db_validate(struct nfp_hwinfo *db, uint32_t len)
crc = (uint32_t *)(db->start + size);
if (new_crc != *crc) {
PMD_DRV_LOG(ERR, "Corrupt hwinfo table (CRC mismatch) calculated 0x%x, expected 0x%x",
- new_crc, *crc);
+ new_crc, *crc);
return -EINVAL;
}
@@ -77,7 +79,8 @@ nfp_hwinfo_db_validate(struct nfp_hwinfo *db, uint32_t len)
}
static struct nfp_hwinfo *
-nfp_hwinfo_try_fetch(struct nfp_cpp *cpp, size_t *cpp_size)
+nfp_hwinfo_try_fetch(struct nfp_cpp *cpp,
+ size_t *cpp_size)
{
struct nfp_hwinfo *header;
void *res;
@@ -115,7 +118,7 @@ nfp_hwinfo_try_fetch(struct nfp_cpp *cpp, size_t *cpp_size)
if (header->version != NFP_HWINFO_VERSION_2) {
PMD_DRV_LOG(DEBUG, "Unknown HWInfo version: 0x%08x",
- header->version);
+ header->version);
goto exit_free;
}
@@ -129,7 +132,8 @@ nfp_hwinfo_try_fetch(struct nfp_cpp *cpp, size_t *cpp_size)
}
static struct nfp_hwinfo *
-nfp_hwinfo_fetch(struct nfp_cpp *cpp, size_t *hwdb_size)
+nfp_hwinfo_fetch(struct nfp_cpp *cpp,
+ size_t *hwdb_size)
{
struct timespec wait;
struct nfp_hwinfo *db;
@@ -179,7 +183,8 @@ nfp_hwinfo_read(struct nfp_cpp *cpp)
* Return: Value of the HWInfo name, or NULL
*/
const char *
-nfp_hwinfo_lookup(struct nfp_hwinfo *hwinfo, const char *lookup)
+nfp_hwinfo_lookup(struct nfp_hwinfo *hwinfo,
+ const char *lookup)
{
const char *key, *val, *end;
@@ -189,7 +194,7 @@ nfp_hwinfo_lookup(struct nfp_hwinfo *hwinfo, const char *lookup)
end = hwinfo->data + hwinfo->size - sizeof(uint32_t);
for (key = hwinfo->data; *key != 0 && key < end;
- key = val + strlen(val) + 1) {
+ key = val + strlen(val) + 1) {
val = key + strlen(key) + 1;
if (strcmp(key, lookup) == 0)
diff --git a/drivers/net/nfp/nfpcore/nfp_mip.c b/drivers/net/nfp/nfpcore/nfp_mip.c
index f9723dd136..0071d3fc37 100644
--- a/drivers/net/nfp/nfpcore/nfp_mip.c
+++ b/drivers/net/nfp/nfpcore/nfp_mip.c
@@ -37,8 +37,10 @@ struct nfp_mip {
/* Read memory and check if it could be a valid MIP */
static int
-nfp_mip_try_read(struct nfp_cpp *cpp, uint32_t cpp_id, uint64_t addr,
- struct nfp_mip *mip)
+nfp_mip_try_read(struct nfp_cpp *cpp,
+ uint32_t cpp_id,
+ uint64_t addr,
+ struct nfp_mip *mip)
{
int ret;
@@ -49,12 +51,12 @@ nfp_mip_try_read(struct nfp_cpp *cpp, uint32_t cpp_id, uint64_t addr,
}
if (mip->signature != NFP_MIP_SIGNATURE) {
PMD_DRV_LOG(ERR, "Incorrect MIP signature (0x%08x)",
- rte_le_to_cpu_32(mip->signature));
+ rte_le_to_cpu_32(mip->signature));
return -EINVAL;
}
if (mip->mip_version != NFP_MIP_VERSION) {
PMD_DRV_LOG(ERR, "Unsupported MIP version (%d)",
- rte_le_to_cpu_32(mip->mip_version));
+ rte_le_to_cpu_32(mip->mip_version));
return -EINVAL;
}
@@ -63,7 +65,8 @@ nfp_mip_try_read(struct nfp_cpp *cpp, uint32_t cpp_id, uint64_t addr,
/* Try to locate MIP using the resource table */
static int
-nfp_mip_read_resource(struct nfp_cpp *cpp, struct nfp_mip *mip)
+nfp_mip_read_resource(struct nfp_cpp *cpp,
+ struct nfp_mip *mip)
{
struct nfp_nffw_info *nffw_info;
uint32_t cpp_id;
@@ -134,7 +137,9 @@ nfp_mip_name(const struct nfp_mip *mip)
* @size: Location for size of MIP symbol table
*/
void
-nfp_mip_symtab(const struct nfp_mip *mip, uint32_t *addr, uint32_t *size)
+nfp_mip_symtab(const struct nfp_mip *mip,
+ uint32_t *addr,
+ uint32_t *size)
{
*addr = rte_le_to_cpu_32(mip->symtab_addr);
*size = rte_le_to_cpu_32(mip->symtab_size);
@@ -147,7 +152,9 @@ nfp_mip_symtab(const struct nfp_mip *mip, uint32_t *addr, uint32_t *size)
* @size: Location for size of MIP symbol name table
*/
void
-nfp_mip_strtab(const struct nfp_mip *mip, uint32_t *addr, uint32_t *size)
+nfp_mip_strtab(const struct nfp_mip *mip,
+ uint32_t *addr,
+ uint32_t *size)
{
*addr = rte_le_to_cpu_32(mip->strtab_addr);
*size = rte_le_to_cpu_32(mip->strtab_size);
diff --git a/drivers/net/nfp/nfpcore/nfp_mip.h b/drivers/net/nfp/nfpcore/nfp_mip.h
index d0919b58fe..980abc2517 100644
--- a/drivers/net/nfp/nfpcore/nfp_mip.h
+++ b/drivers/net/nfp/nfpcore/nfp_mip.h
@@ -17,5 +17,5 @@ const char *nfp_mip_name(const struct nfp_mip *mip);
void nfp_mip_symtab(const struct nfp_mip *mip, uint32_t *addr, uint32_t *size);
void nfp_mip_strtab(const struct nfp_mip *mip, uint32_t *addr, uint32_t *size);
int nfp_nffw_info_mip_first(struct nfp_nffw_info *state, uint32_t *cpp_id,
- uint64_t *off);
+ uint64_t *off);
#endif
diff --git a/drivers/net/nfp/nfpcore/nfp_mutex.c b/drivers/net/nfp/nfpcore/nfp_mutex.c
index 0410a00856..047e755416 100644
--- a/drivers/net/nfp/nfpcore/nfp_mutex.c
+++ b/drivers/net/nfp/nfpcore/nfp_mutex.c
@@ -35,7 +35,9 @@ struct nfp_cpp_mutex {
};
static int
-_nfp_cpp_mutex_validate(uint32_t model, int *target, unsigned long long address)
+_nfp_cpp_mutex_validate(uint32_t model,
+ int *target,
+ unsigned long long address)
{
/* Address must be 64-bit aligned */
if ((address & 7) != 0)
@@ -72,8 +74,10 @@ _nfp_cpp_mutex_validate(uint32_t model, int *target, unsigned long long address)
* @return 0 on success, or negative value on failure.
*/
int
-nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target, unsigned long long address,
- uint32_t key)
+nfp_cpp_mutex_init(struct nfp_cpp *cpp,
+ int target,
+ unsigned long long address,
+ uint32_t key)
{
uint32_t model = nfp_cpp_model(cpp);
uint32_t muw = NFP_CPP_ID(target, 4, 0); /* atomic_write */
@@ -87,9 +91,8 @@ nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target, unsigned long long address,
if (err < 0)
return err;
- err =
- nfp_cpp_writel(cpp, muw, address + 0,
- MUTEX_LOCKED(nfp_cpp_interface(cpp)));
+ err = nfp_cpp_writel(cpp, muw, address + 0,
+ MUTEX_LOCKED(nfp_cpp_interface(cpp)));
if (err < 0)
return err;
@@ -114,8 +117,10 @@ nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target, unsigned long long address,
* @return A non-NULL struct nfp_cpp_mutex * on success, NULL on failure.
*/
struct nfp_cpp_mutex *
-nfp_cpp_mutex_alloc(struct nfp_cpp *cpp, int target,
- unsigned long long address, uint32_t key)
+nfp_cpp_mutex_alloc(struct nfp_cpp *cpp,
+ int target,
+ unsigned long long address,
+ uint32_t key)
{
uint32_t model = nfp_cpp_model(cpp);
struct nfp_cpp_mutex *mutex;
@@ -265,8 +270,8 @@ nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
return err;
if (time(NULL) >= warn_at) {
PMD_DRV_LOG(ERR, "Warning: waiting for NFP mutex usage:%u depth:%hd] target:%d addr:%llx key:%08x]",
- mutex->usage, mutex->depth, mutex->target,
- mutex->address, mutex->key);
+ mutex->usage, mutex->depth, mutex->target,
+ mutex->address, mutex->key);
warn_at = time(NULL) + 60;
}
sched_yield();
diff --git a/drivers/net/nfp/nfpcore/nfp_nffw.c b/drivers/net/nfp/nfpcore/nfp_nffw.c
index 433780a5e7..fa65956baa 100644
--- a/drivers/net/nfp/nfpcore/nfp_nffw.c
+++ b/drivers/net/nfp/nfpcore/nfp_nffw.c
@@ -85,7 +85,8 @@ nfp_mip_mu_locality_lsb(struct nfp_cpp *cpp)
}
static unsigned int
-nffw_res_fwinfos(struct nfp_nffw_info_data *fwinf, struct nffw_fwinfo **arr)
+nffw_res_fwinfos(struct nfp_nffw_info_data *fwinf,
+ struct nffw_fwinfo **arr)
{
/*
* For the this code, version 0 is most likely to be version 1 in this
@@ -138,8 +139,8 @@ nfp_nffw_info_open(struct nfp_cpp *cpp)
goto err_release;
err = nfp_cpp_read(cpp, nfp_resource_cpp_id(state->res),
- nfp_resource_address(state->res),
- fwinf, sizeof(*fwinf));
+ nfp_resource_address(state->res),
+ fwinf, sizeof(*fwinf));
if (err < (int)sizeof(*fwinf))
goto err_release;
@@ -205,8 +206,9 @@ nfp_nffw_info_fwid_first(struct nfp_nffw_info *state)
* Return: 0, or -ERRNO
*/
int
-nfp_nffw_info_mip_first(struct nfp_nffw_info *state, uint32_t *cpp_id,
- uint64_t *off)
+nfp_nffw_info_mip_first(struct nfp_nffw_info *state,
+ uint32_t *cpp_id,
+ uint64_t *off)
{
struct nffw_fwinfo *fwinfo;
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.c b/drivers/net/nfp/nfpcore/nfp_nsp.c
index 6474abf0c2..4f476f6f2b 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.c
@@ -22,7 +22,8 @@ nfp_nsp_config_modified(struct nfp_nsp *state)
}
void
-nfp_nsp_config_set_modified(struct nfp_nsp *state, int modified)
+nfp_nsp_config_set_modified(struct nfp_nsp *state,
+ int modified)
{
state->modified = modified;
}
@@ -40,7 +41,9 @@ nfp_nsp_config_idx(struct nfp_nsp *state)
}
void
-nfp_nsp_config_set_state(struct nfp_nsp *state, void *entries, unsigned int idx)
+nfp_nsp_config_set_state(struct nfp_nsp *state,
+ void *entries,
+ unsigned int idx)
{
state->entries = entries;
state->idx = idx;
@@ -91,7 +94,7 @@ nfp_nsp_check(struct nfp_nsp *state)
if (state->ver.major != NSP_MAJOR || state->ver.minor < NSP_MINOR) {
PMD_DRV_LOG(ERR, "Unsupported ABI %hu.%hu", state->ver.major,
- state->ver.minor);
+ state->ver.minor);
return -EINVAL;
}
@@ -160,8 +163,12 @@ nfp_nsp_get_abi_ver_minor(struct nfp_nsp *state)
}
static int
-nfp_nsp_wait_reg(struct nfp_cpp *cpp, uint64_t *reg, uint32_t nsp_cpp,
- uint64_t addr, uint64_t mask, uint64_t val)
+nfp_nsp_wait_reg(struct nfp_cpp *cpp,
+ uint64_t *reg,
+ uint32_t nsp_cpp,
+ uint64_t addr,
+ uint64_t mask,
+ uint64_t val)
{
struct timespec wait;
int count;
@@ -204,8 +211,11 @@ nfp_nsp_wait_reg(struct nfp_cpp *cpp, uint64_t *reg, uint32_t nsp_cpp,
* -ETIMEDOUT if the NSP took longer than 30 seconds to complete
*/
static int
-nfp_nsp_command(struct nfp_nsp *state, uint16_t code, uint32_t option,
- uint32_t buff_cpp, uint64_t buff_addr)
+nfp_nsp_command(struct nfp_nsp *state,
+ uint16_t code,
+ uint32_t option,
+ uint32_t buff_cpp,
+ uint64_t buff_addr)
{
uint64_t reg, ret_val, nsp_base, nsp_buffer, nsp_status, nsp_command;
struct nfp_cpp *cpp = state->cpp;
@@ -223,40 +233,40 @@ nfp_nsp_command(struct nfp_nsp *state, uint16_t code, uint32_t option,
return err;
if (!FIELD_FIT(NSP_BUFFER_CPP, buff_cpp >> 8) ||
- !FIELD_FIT(NSP_BUFFER_ADDRESS, buff_addr)) {
+ !FIELD_FIT(NSP_BUFFER_ADDRESS, buff_addr)) {
PMD_DRV_LOG(ERR, "Host buffer out of reach %08x %" PRIx64,
- buff_cpp, buff_addr);
+ buff_cpp, buff_addr);
return -EINVAL;
}
err = nfp_cpp_writeq(cpp, nsp_cpp, nsp_buffer,
- FIELD_PREP(NSP_BUFFER_CPP, buff_cpp >> 8) |
- FIELD_PREP(NSP_BUFFER_ADDRESS, buff_addr));
+ FIELD_PREP(NSP_BUFFER_CPP, buff_cpp >> 8) |
+ FIELD_PREP(NSP_BUFFER_ADDRESS, buff_addr));
if (err < 0)
return err;
err = nfp_cpp_writeq(cpp, nsp_cpp, nsp_command,
- FIELD_PREP(NSP_COMMAND_OPTION, option) |
- FIELD_PREP(NSP_COMMAND_CODE, code) |
- FIELD_PREP(NSP_COMMAND_START, 1));
+ FIELD_PREP(NSP_COMMAND_OPTION, option) |
+ FIELD_PREP(NSP_COMMAND_CODE, code) |
+ FIELD_PREP(NSP_COMMAND_START, 1));
if (err < 0)
return err;
/* Wait for NSP_COMMAND_START to go to 0 */
err = nfp_nsp_wait_reg(cpp, ®, nsp_cpp, nsp_command,
- NSP_COMMAND_START, 0);
+ NSP_COMMAND_START, 0);
if (err != 0) {
PMD_DRV_LOG(ERR, "Error %d waiting for code 0x%04x to start",
- err, code);
+ err, code);
return err;
}
/* Wait for NSP_STATUS_BUSY to go to 0 */
- err = nfp_nsp_wait_reg(cpp, ®, nsp_cpp, nsp_status, NSP_STATUS_BUSY,
- 0);
+ err = nfp_nsp_wait_reg(cpp, ®, nsp_cpp, nsp_status,
+ NSP_STATUS_BUSY, 0);
if (err != 0) {
PMD_DRV_LOG(ERR, "Error %d waiting for code 0x%04x to start",
- err, code);
+ err, code);
return err;
}
@@ -268,7 +278,7 @@ nfp_nsp_command(struct nfp_nsp *state, uint16_t code, uint32_t option,
err = FIELD_GET(NSP_STATUS_RESULT, reg);
if (err != 0) {
PMD_DRV_LOG(ERR, "Result (error) code set: %d (%d) command: %d",
- -err, (int)ret_val, code);
+ -err, (int)ret_val, code);
nfp_nsp_print_extended_error(ret_val);
return -err;
}
@@ -279,9 +289,12 @@ nfp_nsp_command(struct nfp_nsp *state, uint16_t code, uint32_t option,
#define SZ_1M 0x00100000
static int
-nfp_nsp_command_buf(struct nfp_nsp *nsp, uint16_t code, uint32_t option,
- const void *in_buf, unsigned int in_size, void *out_buf,
- unsigned int out_size)
+nfp_nsp_command_buf(struct nfp_nsp *nsp,
+ uint16_t code, uint32_t option,
+ const void *in_buf,
+ unsigned int in_size,
+ void *out_buf,
+ unsigned int out_size)
{
struct nfp_cpp *cpp = nsp->cpp;
unsigned int max_size;
@@ -291,28 +304,26 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp, uint16_t code, uint32_t option,
if (nsp->ver.minor < 13) {
PMD_DRV_LOG(ERR, "NSP: Code 0x%04x with buffer not supported ABI %hu.%hu)",
- code, nsp->ver.major, nsp->ver.minor);
+ code, nsp->ver.major, nsp->ver.minor);
return -EOPNOTSUPP;
}
err = nfp_cpp_readq(cpp, nfp_resource_cpp_id(nsp->res),
- nfp_resource_address(nsp->res) +
- NSP_DFLT_BUFFER_CONFIG,
- ®);
+ nfp_resource_address(nsp->res) + NSP_DFLT_BUFFER_CONFIG,
+ ®);
if (err < 0)
return err;
max_size = RTE_MAX(in_size, out_size);
if (FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M < max_size) {
PMD_DRV_LOG(ERR, "NSP: default buffer too small for command 0x%04x (%llu < %u)",
- code, FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M, max_size);
+ code, FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M, max_size);
return -EINVAL;
}
err = nfp_cpp_readq(cpp, nfp_resource_cpp_id(nsp->res),
- nfp_resource_address(nsp->res) +
- NSP_DFLT_BUFFER,
- ®);
+ nfp_resource_address(nsp->res) + NSP_DFLT_BUFFER,
+ ®);
if (err < 0)
return err;
@@ -328,7 +339,7 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp, uint16_t code, uint32_t option,
if (out_buf != NULL && out_size > 0 && out_size > in_size) {
memset(out_buf, 0, out_size - in_size);
err = nfp_cpp_write(cpp, cpp_id, cpp_buf + in_size, out_buf,
- out_size - in_size);
+ out_size - in_size);
if (err < 0)
return err;
}
@@ -388,38 +399,47 @@ nfp_nsp_mac_reinit(struct nfp_nsp *state)
}
int
-nfp_nsp_load_fw(struct nfp_nsp *state, void *buf, unsigned int size)
+nfp_nsp_load_fw(struct nfp_nsp *state,
+ void *buf,
+ unsigned int size)
{
return nfp_nsp_command_buf(state, SPCODE_FW_LOAD, size, buf, size,
- NULL, 0);
+ NULL, 0);
}
int
-nfp_nsp_read_eth_table(struct nfp_nsp *state, void *buf, unsigned int size)
+nfp_nsp_read_eth_table(struct nfp_nsp *state,
+ void *buf,
+ unsigned int size)
{
return nfp_nsp_command_buf(state, SPCODE_ETH_RESCAN, size, NULL, 0,
- buf, size);
+ buf, size);
}
int
-nfp_nsp_write_eth_table(struct nfp_nsp *state, const void *buf,
- unsigned int size)
+nfp_nsp_write_eth_table(struct nfp_nsp *state,
+ const void *buf,
+ unsigned int size)
{
return nfp_nsp_command_buf(state, SPCODE_ETH_CONTROL, size, buf, size,
- NULL, 0);
+ NULL, 0);
}
int
-nfp_nsp_read_identify(struct nfp_nsp *state, void *buf, unsigned int size)
+nfp_nsp_read_identify(struct nfp_nsp *state,
+ void *buf,
+ unsigned int size)
{
return nfp_nsp_command_buf(state, SPCODE_NSP_IDENTIFY, size, NULL, 0,
- buf, size);
+ buf, size);
}
int
-nfp_nsp_read_sensors(struct nfp_nsp *state, unsigned int sensor_mask, void *buf,
- unsigned int size)
+nfp_nsp_read_sensors(struct nfp_nsp *state,
+ unsigned int sensor_mask,
+ void *buf,
+ unsigned int size)
{
return nfp_nsp_command_buf(state, SPCODE_NSP_SENSORS, sensor_mask, NULL,
- 0, buf, size);
+ 0, buf, size);
}
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.h b/drivers/net/nfp/nfpcore/nfp_nsp.h
index 9905b2d3d3..1e2deaabb4 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.h
@@ -114,9 +114,10 @@ int nfp_nsp_load_fw(struct nfp_nsp *state, void *buf, unsigned int size);
int nfp_nsp_mac_reinit(struct nfp_nsp *state);
int nfp_nsp_read_identify(struct nfp_nsp *state, void *buf, unsigned int size);
int nfp_nsp_read_sensors(struct nfp_nsp *state, unsigned int sensor_mask,
- void *buf, unsigned int size);
+ void *buf, unsigned int size);
-static inline int nfp_nsp_has_mac_reinit(struct nfp_nsp *state)
+static inline int
+nfp_nsp_has_mac_reinit(struct nfp_nsp *state)
{
return nfp_nsp_get_abi_ver_minor(state) > 20;
}
@@ -229,22 +230,22 @@ struct nfp_eth_table *nfp_eth_read_ports(struct nfp_cpp *cpp);
int nfp_eth_set_mod_enable(struct nfp_cpp *cpp, unsigned int idx, int enable);
int nfp_eth_set_configured(struct nfp_cpp *cpp, unsigned int idx,
- int configed);
-int
-nfp_eth_set_fec(struct nfp_cpp *cpp, unsigned int idx, enum nfp_eth_fec mode);
+ int configed);
+int nfp_eth_set_fec(struct nfp_cpp *cpp, unsigned int idx, enum nfp_eth_fec mode);
int nfp_nsp_read_eth_table(struct nfp_nsp *state, void *buf, unsigned int size);
int nfp_nsp_write_eth_table(struct nfp_nsp *state, const void *buf,
- unsigned int size);
+ unsigned int size);
void nfp_nsp_config_set_state(struct nfp_nsp *state, void *entries,
- unsigned int idx);
+ unsigned int idx);
void nfp_nsp_config_clear_state(struct nfp_nsp *state);
void nfp_nsp_config_set_modified(struct nfp_nsp *state, int modified);
void *nfp_nsp_config_entries(struct nfp_nsp *state);
int nfp_nsp_config_modified(struct nfp_nsp *state);
unsigned int nfp_nsp_config_idx(struct nfp_nsp *state);
-static inline int nfp_eth_can_support_fec(struct nfp_eth_table_port *eth_port)
+static inline int
+nfp_eth_can_support_fec(struct nfp_eth_table_port *eth_port)
{
return !!eth_port->fec_modes_supported;
}
@@ -297,6 +298,6 @@ enum nfp_nsp_sensor_id {
};
int nfp_hwmon_read_sensor(struct nfp_cpp *cpp, enum nfp_nsp_sensor_id id,
- long *val);
+ long *val);
#endif
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
index 21b338461e..28dba27124 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
@@ -73,7 +73,9 @@ struct nfp_sensors {
};
int
-nfp_hwmon_read_sensor(struct nfp_cpp *cpp, enum nfp_nsp_sensor_id id, long *val)
+nfp_hwmon_read_sensor(struct nfp_cpp *cpp,
+ enum nfp_nsp_sensor_id id,
+ long *val)
{
struct nfp_sensors s;
struct nfp_nsp *nsp;
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
index 825a84a8cd..51bd57033e 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
@@ -159,7 +159,8 @@ nfp_eth_speed2rate(unsigned int speed)
}
static void
-nfp_eth_copy_mac_reverse(uint8_t *dst, const uint8_t *src)
+nfp_eth_copy_mac_reverse(uint8_t *dst,
+ const uint8_t *src)
{
int i;
@@ -168,8 +169,10 @@ nfp_eth_copy_mac_reverse(uint8_t *dst, const uint8_t *src)
}
static void
-nfp_eth_port_translate(struct nfp_nsp *nsp, const union eth_table_entry *src,
- unsigned int index, struct nfp_eth_table_port *dst)
+nfp_eth_port_translate(struct nfp_nsp *nsp,
+ const union eth_table_entry *src,
+ unsigned int index,
+ struct nfp_eth_table_port *dst)
{
unsigned int rate;
unsigned int fec;
@@ -225,21 +228,21 @@ nfp_eth_calc_port_geometry(struct nfp_eth_table *table)
for (i = 0; i < table->count; i++) {
table->max_index = RTE_MAX(table->max_index,
- table->ports[i].index);
+ table->ports[i].index);
for (j = 0; j < table->count; j++) {
if (table->ports[i].label_port !=
- table->ports[j].label_port)
+ table->ports[j].label_port)
continue;
table->ports[i].port_lanes += table->ports[j].lanes;
if (i == j)
continue;
if (table->ports[i].label_subport ==
- table->ports[j].label_subport)
+ table->ports[j].label_subport)
PMD_DRV_LOG(DEBUG, "Port %d subport %d is a duplicate",
- table->ports[i].label_port,
- table->ports[i].label_subport);
+ table->ports[i].label_port,
+ table->ports[i].label_subport);
table->ports[i].is_split = 1;
}
@@ -296,7 +299,7 @@ __nfp_eth_read_ports(struct nfp_nsp *nsp)
*/
if (ret != 0 && ret != cnt) {
PMD_DRV_LOG(ERR, "table entry count (%d) unmatch entries present (%d)",
- ret, cnt);
+ ret, cnt);
goto err;
}
@@ -354,7 +357,8 @@ nfp_eth_read_ports(struct nfp_cpp *cpp)
}
struct nfp_nsp *
-nfp_eth_config_start(struct nfp_cpp *cpp, unsigned int idx)
+nfp_eth_config_start(struct nfp_cpp *cpp,
+ unsigned int idx)
{
union eth_table_entry *entries;
struct nfp_nsp *nsp;
@@ -447,7 +451,9 @@ nfp_eth_config_commit_end(struct nfp_nsp *nsp)
* -ERRNO - configuration failed.
*/
int
-nfp_eth_set_mod_enable(struct nfp_cpp *cpp, unsigned int idx, int enable)
+nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
+ unsigned int idx,
+ int enable)
{
union eth_table_entry *entries;
struct nfp_nsp *nsp;
@@ -487,7 +493,9 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp, unsigned int idx, int enable)
* -ERRNO - configuration failed.
*/
int
-nfp_eth_set_configured(struct nfp_cpp *cpp, unsigned int idx, int configed)
+nfp_eth_set_configured(struct nfp_cpp *cpp,
+ unsigned int idx,
+ int configed)
{
union eth_table_entry *entries;
struct nfp_nsp *nsp;
@@ -523,9 +531,12 @@ nfp_eth_set_configured(struct nfp_cpp *cpp, unsigned int idx, int configed)
}
static int
-nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
- const uint64_t mask, const unsigned int shift,
- unsigned int val, const uint64_t ctrl_bit)
+nfp_eth_set_bit_config(struct nfp_nsp *nsp,
+ unsigned int raw_idx,
+ const uint64_t mask,
+ const unsigned int shift,
+ unsigned int val,
+ const uint64_t ctrl_bit)
{
union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
unsigned int idx = nfp_nsp_config_idx(nsp);
@@ -560,7 +571,7 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
(__extension__ ({ \
typeof(mask) _x = (mask); \
nfp_eth_set_bit_config(nsp, raw_idx, _x, __bf_shf(_x), \
- val, ctrl_bit); \
+ val, ctrl_bit); \
}))
/*
@@ -574,11 +585,11 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
* Return: 0 or -ERRNO.
*/
int
-__nfp_eth_set_aneg(struct nfp_nsp *nsp, enum nfp_eth_aneg mode)
+__nfp_eth_set_aneg(struct nfp_nsp *nsp,
+ enum nfp_eth_aneg mode)
{
return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_STATE,
- NSP_ETH_STATE_ANEG, mode,
- NSP_ETH_CTRL_SET_ANEG);
+ NSP_ETH_STATE_ANEG, mode, NSP_ETH_CTRL_SET_ANEG);
}
/*
@@ -592,11 +603,11 @@ __nfp_eth_set_aneg(struct nfp_nsp *nsp, enum nfp_eth_aneg mode)
* Return: 0 or -ERRNO.
*/
static int
-__nfp_eth_set_fec(struct nfp_nsp *nsp, enum nfp_eth_fec mode)
+__nfp_eth_set_fec(struct nfp_nsp *nsp,
+ enum nfp_eth_fec mode)
{
return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_STATE,
- NSP_ETH_STATE_FEC, mode,
- NSP_ETH_CTRL_SET_FEC);
+ NSP_ETH_STATE_FEC, mode, NSP_ETH_CTRL_SET_FEC);
}
/*
@@ -611,7 +622,9 @@ __nfp_eth_set_fec(struct nfp_nsp *nsp, enum nfp_eth_fec mode)
* -ERRNO - configuration failed.
*/
int
-nfp_eth_set_fec(struct nfp_cpp *cpp, unsigned int idx, enum nfp_eth_fec mode)
+nfp_eth_set_fec(struct nfp_cpp *cpp,
+ unsigned int idx,
+ enum nfp_eth_fec mode)
{
struct nfp_nsp *nsp;
int err;
@@ -642,7 +655,8 @@ nfp_eth_set_fec(struct nfp_cpp *cpp, unsigned int idx, enum nfp_eth_fec mode)
* Return: 0 or -ERRNO.
*/
int
-__nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
+__nfp_eth_set_speed(struct nfp_nsp *nsp,
+ unsigned int speed)
{
enum nfp_eth_rate rate;
@@ -653,8 +667,7 @@ __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
}
return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_STATE,
- NSP_ETH_STATE_RATE, rate,
- NSP_ETH_CTRL_SET_RATE);
+ NSP_ETH_STATE_RATE, rate, NSP_ETH_CTRL_SET_RATE);
}
/*
@@ -668,8 +681,9 @@ __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
* Return: 0 or -ERRNO.
*/
int
-__nfp_eth_set_split(struct nfp_nsp *nsp, unsigned int lanes)
+__nfp_eth_set_split(struct nfp_nsp *nsp,
+ unsigned int lanes)
{
- return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
- lanes, NSP_ETH_CTRL_SET_LANES);
+ return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT,
+ NSP_ETH_PORT_LANES, lanes, NSP_ETH_CTRL_SET_LANES);
}
diff --git a/drivers/net/nfp/nfpcore/nfp_resource.c b/drivers/net/nfp/nfpcore/nfp_resource.c
index 838cd6e0ef..57089c770f 100644
--- a/drivers/net/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/nfp/nfpcore/nfp_resource.c
@@ -64,7 +64,8 @@ struct nfp_resource {
};
static int
-nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res)
+nfp_cpp_resource_find(struct nfp_cpp *cpp,
+ struct nfp_resource *res)
{
char name_pad[NFP_RESOURCE_ENTRY_NAME_SZ + 2];
struct nfp_resource_entry entry;
@@ -85,7 +86,7 @@ nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res)
for (i = 0; i < NFP_RESOURCE_TBL_ENTRIES; i++) {
uint64_t addr = NFP_RESOURCE_TBL_BASE +
- sizeof(struct nfp_resource_entry) * i;
+ sizeof(struct nfp_resource_entry) * i;
ret = nfp_cpp_read(cpp, cpp_id, addr, &entry, sizeof(entry));
if (ret != sizeof(entry))
@@ -95,12 +96,11 @@ nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res)
continue;
/* Found key! */
- res->mutex =
- nfp_cpp_mutex_alloc(cpp,
- NFP_RESOURCE_TBL_TARGET, addr, key);
+ res->mutex = nfp_cpp_mutex_alloc(cpp, NFP_RESOURCE_TBL_TARGET,
+ addr, key);
res->cpp_id = NFP_CPP_ID(entry.region.cpp_target,
- entry.region.cpp_action,
- entry.region.cpp_token);
+ entry.region.cpp_action,
+ entry.region.cpp_token);
res->addr = ((uint64_t)entry.region.page_offset) << 8;
res->size = (uint64_t)entry.region.page_size << 8;
return 0;
@@ -110,8 +110,9 @@ nfp_cpp_resource_find(struct nfp_cpp *cpp, struct nfp_resource *res)
}
static int
-nfp_resource_try_acquire(struct nfp_cpp *cpp, struct nfp_resource *res,
- struct nfp_cpp_mutex *dev_mutex)
+nfp_resource_try_acquire(struct nfp_cpp *cpp,
+ struct nfp_resource *res,
+ struct nfp_cpp_mutex *dev_mutex)
{
int err;
@@ -148,7 +149,8 @@ nfp_resource_try_acquire(struct nfp_cpp *cpp, struct nfp_resource *res,
* Return: NFP Resource handle, or NULL
*/
struct nfp_resource *
-nfp_resource_acquire(struct nfp_cpp *cpp, const char *name)
+nfp_resource_acquire(struct nfp_cpp *cpp,
+ const char *name)
{
struct nfp_cpp_mutex *dev_mutex;
struct nfp_resource *res;
@@ -165,8 +167,7 @@ nfp_resource_acquire(struct nfp_cpp *cpp, const char *name)
strncpy(res->name, name, NFP_RESOURCE_ENTRY_NAME_SZ);
dev_mutex = nfp_cpp_mutex_alloc(cpp, NFP_RESOURCE_TBL_TARGET,
- NFP_RESOURCE_TBL_BASE,
- NFP_RESOURCE_TBL_KEY);
+ NFP_RESOURCE_TBL_BASE, NFP_RESOURCE_TBL_KEY);
if (dev_mutex == NULL) {
free(res);
return NULL;
@@ -234,8 +235,8 @@ nfp_resource_cpp_id(const struct nfp_resource *res)
*
* Return: const char pointer to the name of the resource
*/
-const char
-*nfp_resource_name(const struct nfp_resource *res)
+const char *
+nfp_resource_name(const struct nfp_resource *res)
{
return res->name;
}
diff --git a/drivers/net/nfp/nfpcore/nfp_resource.h b/drivers/net/nfp/nfpcore/nfp_resource.h
index 06cc6f74f4..009b7359a4 100644
--- a/drivers/net/nfp/nfpcore/nfp_resource.h
+++ b/drivers/net/nfp/nfpcore/nfp_resource.h
@@ -18,7 +18,7 @@
struct nfp_resource;
struct nfp_resource *nfp_resource_acquire(struct nfp_cpp *cpp,
- const char *name);
+ const char *name);
/**
* Release a NFP Resource, and free the handle
diff --git a/drivers/net/nfp/nfpcore/nfp_rtsym.c b/drivers/net/nfp/nfpcore/nfp_rtsym.c
index 4c45aec5c1..aa3b7a483e 100644
--- a/drivers/net/nfp/nfpcore/nfp_rtsym.c
+++ b/drivers/net/nfp/nfpcore/nfp_rtsym.c
@@ -40,22 +40,25 @@ struct nfp_rtsym_table {
};
static int
-nfp_meid(uint8_t island_id, uint8_t menum)
+nfp_meid(uint8_t island_id,
+ uint8_t menum)
{
return (island_id & 0x3F) == island_id && menum < 12 ?
(island_id << 4) | (menum + 4) : -1;
}
static void
-nfp_rtsym_sw_entry_init(struct nfp_rtsym_table *cache, uint32_t strtab_size,
- struct nfp_rtsym *sw, struct nfp_rtsym_entry *fw)
+nfp_rtsym_sw_entry_init(struct nfp_rtsym_table *cache,
+ uint32_t strtab_size,
+ struct nfp_rtsym *sw,
+ struct nfp_rtsym_entry *fw)
{
sw->type = fw->type;
sw->name = cache->strtab + rte_le_to_cpu_16(fw->name) % strtab_size;
sw->addr = ((uint64_t)fw->addr_hi << 32) |
- rte_le_to_cpu_32(fw->addr_lo);
+ rte_le_to_cpu_32(fw->addr_lo);
sw->size = ((uint64_t)fw->size_hi << 32) |
- rte_le_to_cpu_32(fw->size_lo);
+ rte_le_to_cpu_32(fw->size_lo);
PMD_INIT_LOG(DEBUG, "rtsym_entry_init name=%s, addr=%" PRIx64 ", size=%" PRIu64 ", target=%d",
sw->name, sw->addr, sw->size, sw->target);
@@ -93,7 +96,8 @@ nfp_rtsym_table_read(struct nfp_cpp *cpp)
}
struct nfp_rtsym_table *
-__nfp_rtsym_table_read(struct nfp_cpp *cpp, const struct nfp_mip *mip)
+__nfp_rtsym_table_read(struct nfp_cpp *cpp,
+ const struct nfp_mip *mip)
{
uint32_t strtab_addr, symtab_addr, strtab_size, symtab_size;
struct nfp_rtsym_entry *rtsymtab;
@@ -142,7 +146,7 @@ __nfp_rtsym_table_read(struct nfp_cpp *cpp, const struct nfp_mip *mip)
for (n = 0; n < cache->num; n++)
nfp_rtsym_sw_entry_init(cache, strtab_size,
- &cache->symtab[n], &rtsymtab[n]);
+ &cache->symtab[n], &rtsymtab[n]);
free(rtsymtab);
@@ -178,7 +182,8 @@ nfp_rtsym_count(struct nfp_rtsym_table *rtbl)
* Return: const pointer to a struct nfp_rtsym descriptor, or NULL
*/
const struct nfp_rtsym *
-nfp_rtsym_get(struct nfp_rtsym_table *rtbl, int idx)
+nfp_rtsym_get(struct nfp_rtsym_table *rtbl,
+ int idx)
{
if (rtbl == NULL)
return NULL;
@@ -197,7 +202,8 @@ nfp_rtsym_get(struct nfp_rtsym_table *rtbl, int idx)
* Return: const pointer to a struct nfp_rtsym descriptor, or NULL
*/
const struct nfp_rtsym *
-nfp_rtsym_lookup(struct nfp_rtsym_table *rtbl, const char *name)
+nfp_rtsym_lookup(struct nfp_rtsym_table *rtbl,
+ const char *name)
{
int n;
@@ -331,7 +337,9 @@ nfp_rtsym_readq(struct nfp_cpp *cpp,
* Return: value read, on error sets the error and returns ~0ULL.
*/
uint64_t
-nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl, const char *name, int *error)
+nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl,
+ const char *name,
+ int *error)
{
const struct nfp_rtsym *sym;
uint32_t val32;
@@ -354,7 +362,7 @@ nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl, const char *name, int *error)
break;
default:
PMD_DRV_LOG(ERR, "rtsym '%s' unsupported size: %" PRId64,
- name, sym->size);
+ name, sym->size);
err = -EINVAL;
break;
}
@@ -372,8 +380,10 @@ nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl, const char *name, int *error)
}
uint8_t *
-nfp_rtsym_map(struct nfp_rtsym_table *rtbl, const char *name,
- unsigned int min_size, struct nfp_cpp_area **area)
+nfp_rtsym_map(struct nfp_rtsym_table *rtbl,
+ const char *name,
+ unsigned int min_size,
+ struct nfp_cpp_area **area)
{
int ret;
uint8_t *mem;
@@ -397,7 +407,7 @@ nfp_rtsym_map(struct nfp_rtsym_table *rtbl, const char *name,
if (sym->size < min_size) {
PMD_DRV_LOG(ERR, "Symbol %s too small (%" PRIu64 " < %u)", name,
- sym->size, min_size);
+ sym->size, min_size);
return NULL;
}
diff --git a/drivers/net/nfp/nfpcore/nfp_rtsym.h b/drivers/net/nfp/nfpcore/nfp_rtsym.h
index 8b494211bc..30768f1ccf 100644
--- a/drivers/net/nfp/nfpcore/nfp_rtsym.h
+++ b/drivers/net/nfp/nfpcore/nfp_rtsym.h
@@ -43,19 +43,18 @@ struct nfp_rtsym_table;
struct nfp_rtsym_table *nfp_rtsym_table_read(struct nfp_cpp *cpp);
-struct nfp_rtsym_table *
-__nfp_rtsym_table_read(struct nfp_cpp *cpp, const struct nfp_mip *mip);
+struct nfp_rtsym_table *__nfp_rtsym_table_read(struct nfp_cpp *cpp,
+ const struct nfp_mip *mip);
int nfp_rtsym_count(struct nfp_rtsym_table *rtbl);
const struct nfp_rtsym *nfp_rtsym_get(struct nfp_rtsym_table *rtbl, int idx);
-const struct nfp_rtsym *
-nfp_rtsym_lookup(struct nfp_rtsym_table *rtbl, const char *name);
+const struct nfp_rtsym *nfp_rtsym_lookup(struct nfp_rtsym_table *rtbl,
+ const char *name);
uint64_t nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl, const char *name,
- int *error);
-uint8_t *
-nfp_rtsym_map(struct nfp_rtsym_table *rtbl, const char *name,
- unsigned int min_size, struct nfp_cpp_area **area);
+ int *error);
+uint8_t *nfp_rtsym_map(struct nfp_rtsym_table *rtbl, const char *name,
+ unsigned int min_size, struct nfp_cpp_area **area);
#endif
--
2.39.1
^ permalink raw reply [relevance 1%]
* [PATCH v5 05/26] net/nfp: standard the local variable coding style
2023-09-19 9:54 1% ` [PATCH v5 02/26] net/nfp: unify the indent coding style Chaoyong He
@ 2023-09-19 9:54 3% ` Chaoyong He
2023-09-19 9:54 1% ` [PATCH v5 07/26] net/nfp: standard the comment style Chaoyong He
2023-09-19 9:54 5% ` [PATCH v5 18/26] net/nfp: refact the nsp module Chaoyong He
3 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-09-19 9:54 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Chaoyong He
There should only declare one local variable in each line, and the local
variable should be arranged from short to long in the function.
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
---
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 58 ++++++++++++----------
drivers/net/nfp/nfpcore/nfp_cppcore.c | 14 +++---
drivers/net/nfp/nfpcore/nfp_hwinfo.c | 27 ++++++----
drivers/net/nfp/nfpcore/nfp_mip.c | 8 +--
drivers/net/nfp/nfpcore/nfp_mutex.c | 25 ++++++----
drivers/net/nfp/nfpcore/nfp_nffw.c | 15 +++---
drivers/net/nfp/nfpcore/nfp_nsp.c | 40 ++++++++-------
drivers/net/nfp/nfpcore/nfp_nsp_cmds.c | 8 +--
drivers/net/nfp/nfpcore/nfp_nsp_eth.c | 39 ++++++++-------
drivers/net/nfp/nfpcore/nfp_resource.c | 15 +++---
drivers/net/nfp/nfpcore/nfp_rtsym.c | 19 ++++---
11 files changed, 151 insertions(+), 117 deletions(-)
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
index ec14ec45dc..78beee07ef 100644
--- a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
+++ b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
@@ -140,9 +140,9 @@ nfp_compute_bar(const struct nfp_bar *bar,
size_t size,
int width)
{
- uint32_t bitsize;
- uint32_t newcfg;
uint64_t mask;
+ uint32_t newcfg;
+ uint32_t bitsize;
if (tgt >= 16)
return -EINVAL;
@@ -239,7 +239,8 @@ nfp_bar_write(struct nfp_pcie_user *nfp,
struct nfp_bar *bar,
uint32_t newcfg)
{
- int base, slot;
+ int base;
+ int slot;
base = bar->index >> 3;
slot = bar->index & 7;
@@ -268,9 +269,9 @@ nfp_reconfigure_bar(struct nfp_pcie_user *nfp,
size_t size,
int width)
{
- uint64_t newbase;
- uint32_t newcfg;
int err;
+ uint32_t newcfg;
+ uint64_t newbase;
err = nfp_compute_bar(bar, &newcfg, &newbase, tgt, act, tok, offset,
size, width);
@@ -303,8 +304,10 @@ nfp_reconfigure_bar(struct nfp_pcie_user *nfp,
static int
nfp_enable_bars(struct nfp_pcie_user *nfp)
{
+ int x;
+ int end;
+ int start;
struct nfp_bar *bar;
- int x, start, end;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
start = NFP_BAR_MID;
@@ -333,8 +336,10 @@ nfp_enable_bars(struct nfp_pcie_user *nfp)
static struct nfp_bar *
nfp_alloc_bar(struct nfp_pcie_user *nfp)
{
+ int x;
+ int end;
+ int start;
struct nfp_bar *bar;
- int x, start, end;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
start = NFP_BAR_MID;
@@ -356,8 +361,10 @@ nfp_alloc_bar(struct nfp_pcie_user *nfp)
static void
nfp_disable_bars(struct nfp_pcie_user *nfp)
{
+ int x;
+ int end;
+ int start;
struct nfp_bar *bar;
- int x, start, end;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
start = NFP_BAR_MID;
@@ -403,12 +410,13 @@ nfp6000_area_init(struct nfp_cpp_area *area,
uint64_t address,
size_t size)
{
- struct nfp_pcie_user *nfp = nfp_cpp_priv(nfp_cpp_area_cpp(area));
- struct nfp6000_area_priv *priv = nfp_cpp_area_priv(area);
+ int pp;
+ int ret = 0;
+ uint32_t token = NFP_CPP_ID_TOKEN_of(dest);
uint32_t target = NFP_CPP_ID_TARGET_of(dest);
uint32_t action = NFP_CPP_ID_ACTION_of(dest);
- uint32_t token = NFP_CPP_ID_TOKEN_of(dest);
- int pp, ret = 0;
+ struct nfp6000_area_priv *priv = nfp_cpp_area_priv(area);
+ struct nfp_pcie_user *nfp = nfp_cpp_priv(nfp_cpp_area_cpp(area));
pp = nfp_target_pushpull(NFP_CPP_ID(target, action, token), address);
if (pp < 0)
@@ -493,14 +501,14 @@ nfp6000_area_read(struct nfp_cpp_area *area,
uint32_t offset,
size_t length)
{
+ size_t n;
+ int width;
+ bool is_64;
+ uint32_t *wrptr32 = kernel_vaddr;
uint64_t *wrptr64 = kernel_vaddr;
- const volatile uint64_t *rdptr64;
struct nfp6000_area_priv *priv;
- uint32_t *wrptr32 = kernel_vaddr;
const volatile uint32_t *rdptr32;
- int width;
- size_t n;
- bool is_64;
+ const volatile uint64_t *rdptr64;
priv = nfp_cpp_area_priv(area);
rdptr64 = (uint64_t *)(priv->iomem + offset);
@@ -563,14 +571,14 @@ nfp6000_area_write(struct nfp_cpp_area *area,
uint32_t offset,
size_t length)
{
- const uint64_t *rdptr64 = kernel_vaddr;
- uint64_t *wrptr64;
- const uint32_t *rdptr32 = kernel_vaddr;
- struct nfp6000_area_priv *priv;
- uint32_t *wrptr32;
- int width;
size_t n;
+ int width;
bool is_64;
+ uint32_t *wrptr32;
+ uint64_t *wrptr64;
+ struct nfp6000_area_priv *priv;
+ const uint32_t *rdptr32 = kernel_vaddr;
+ const uint64_t *rdptr64 = kernel_vaddr;
priv = nfp_cpp_area_priv(area);
wrptr64 = (uint64_t *)(priv->iomem + offset);
@@ -693,10 +701,10 @@ static int
nfp6000_set_serial(struct rte_pci_device *dev,
struct nfp_cpp *cpp)
{
+ off_t pos;
uint16_t tmp;
uint8_t serial[6];
int serial_len = 6;
- off_t pos;
pos = rte_pci_find_ext_capability(dev, RTE_PCI_EXT_CAP_ID_DSN);
if (pos <= 0) {
@@ -741,8 +749,8 @@ static int
nfp6000_set_barsz(struct rte_pci_device *dev,
struct nfp_pcie_user *desc)
{
- uint64_t tmp;
int i = 0;
+ uint64_t tmp;
tmp = dev->mem_resource[0].len;
diff --git a/drivers/net/nfp/nfpcore/nfp_cppcore.c b/drivers/net/nfp/nfpcore/nfp_cppcore.c
index 7e7c36eda3..2e5a4e7349 100644
--- a/drivers/net/nfp/nfpcore/nfp_cppcore.c
+++ b/drivers/net/nfp/nfpcore/nfp_cppcore.c
@@ -172,9 +172,9 @@ nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
uint64_t address,
uint32_t size)
{
+ int err;
struct nfp_cpp_area *area;
uint64_t tmp64 = (uint64_t)address;
- int err;
if (cpp == NULL)
return NULL;
@@ -396,8 +396,8 @@ static uint32_t
nfp_xpb_to_cpp(struct nfp_cpp *cpp,
uint32_t *xpb_addr)
{
- uint32_t xpb;
int island;
+ uint32_t xpb;
xpb = NFP_CPP_ID(14, NFP_CPP_ACTION_RW, 0);
@@ -569,9 +569,9 @@ static struct nfp_cpp *
nfp_cpp_alloc(struct rte_pci_device *dev,
int driver_lock_needed)
{
- const struct nfp_cpp_operations *ops;
- struct nfp_cpp *cpp;
int err;
+ struct nfp_cpp *cpp;
+ const struct nfp_cpp_operations *ops;
ops = nfp_cpp_transport_operations();
@@ -657,8 +657,8 @@ nfp_cpp_read(struct nfp_cpp *cpp,
void *kernel_vaddr,
size_t length)
{
- struct nfp_cpp_area *area;
int err;
+ struct nfp_cpp_area *area;
area = nfp_cpp_area_alloc_acquire(cpp, destination, address, length);
if (area == NULL) {
@@ -687,8 +687,8 @@ nfp_cpp_write(struct nfp_cpp *cpp,
const void *kernel_vaddr,
size_t length)
{
- struct nfp_cpp_area *area;
int err;
+ struct nfp_cpp_area *area;
area = nfp_cpp_area_alloc_acquire(cpp, destination, address, length);
if (area == NULL)
@@ -708,8 +708,8 @@ uint32_t
__nfp_cpp_model_autodetect(struct nfp_cpp *cpp,
uint32_t *model)
{
- uint32_t reg;
int err;
+ uint32_t reg;
err = nfp_xpb_readl(cpp, NFP_XPB_DEVICE(1, 1, 16) + NFP_PL_DEVICE_ID,
®);
diff --git a/drivers/net/nfp/nfpcore/nfp_hwinfo.c b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
index ea4c7d6a9e..819761eda0 100644
--- a/drivers/net/nfp/nfpcore/nfp_hwinfo.c
+++ b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
@@ -36,7 +36,9 @@ static int
nfp_hwinfo_db_walk(struct nfp_hwinfo *hwinfo,
uint32_t size)
{
- const char *key, *val, *end = hwinfo->data + size;
+ const char *key;
+ const char *val;
+ const char *end = hwinfo->data + size;
for (key = hwinfo->data; *key != 0 && key < end;
key = val + strlen(val) + 1) {
@@ -58,7 +60,9 @@ static int
nfp_hwinfo_db_validate(struct nfp_hwinfo *db,
uint32_t len)
{
- uint32_t size, new_crc, *crc;
+ uint32_t *crc;
+ uint32_t size;
+ uint32_t new_crc;
size = db->size;
if (size > len) {
@@ -82,12 +86,12 @@ static struct nfp_hwinfo *
nfp_hwinfo_try_fetch(struct nfp_cpp *cpp,
size_t *cpp_size)
{
- struct nfp_hwinfo *header;
- void *res;
- uint64_t cpp_addr;
- uint32_t cpp_id;
int err;
+ void *res;
uint8_t *db;
+ uint32_t cpp_id;
+ uint64_t cpp_addr;
+ struct nfp_hwinfo *header;
res = nfp_resource_acquire(cpp, NFP_RESOURCE_NFP_HWINFO);
if (res) {
@@ -135,13 +139,12 @@ static struct nfp_hwinfo *
nfp_hwinfo_fetch(struct nfp_cpp *cpp,
size_t *hwdb_size)
{
+ int count = 0;
struct timespec wait;
struct nfp_hwinfo *db;
- int count;
wait.tv_sec = 0;
wait.tv_nsec = 10000000;
- count = 0;
for (;;) {
db = nfp_hwinfo_try_fetch(cpp, hwdb_size);
@@ -159,9 +162,9 @@ nfp_hwinfo_fetch(struct nfp_cpp *cpp,
struct nfp_hwinfo *
nfp_hwinfo_read(struct nfp_cpp *cpp)
{
- struct nfp_hwinfo *db;
- size_t hwdb_size = 0;
int err;
+ size_t hwdb_size = 0;
+ struct nfp_hwinfo *db;
db = nfp_hwinfo_fetch(cpp, &hwdb_size);
if (db == NULL)
@@ -186,7 +189,9 @@ const char *
nfp_hwinfo_lookup(struct nfp_hwinfo *hwinfo,
const char *lookup)
{
- const char *key, *val, *end;
+ const char *key;
+ const char *val;
+ const char *end;
if (hwinfo == NULL || lookup == NULL)
return NULL;
diff --git a/drivers/net/nfp/nfpcore/nfp_mip.c b/drivers/net/nfp/nfpcore/nfp_mip.c
index 0071d3fc37..1e601313b4 100644
--- a/drivers/net/nfp/nfpcore/nfp_mip.c
+++ b/drivers/net/nfp/nfpcore/nfp_mip.c
@@ -68,10 +68,10 @@ static int
nfp_mip_read_resource(struct nfp_cpp *cpp,
struct nfp_mip *mip)
{
- struct nfp_nffw_info *nffw_info;
- uint32_t cpp_id;
- uint64_t addr;
int err;
+ uint64_t addr;
+ uint32_t cpp_id;
+ struct nfp_nffw_info *nffw_info;
nffw_info = nfp_nffw_info_open(cpp);
if (nffw_info == NULL)
@@ -100,8 +100,8 @@ nfp_mip_read_resource(struct nfp_cpp *cpp,
struct nfp_mip *
nfp_mip_open(struct nfp_cpp *cpp)
{
- struct nfp_mip *mip;
int err;
+ struct nfp_mip *mip;
mip = malloc(sizeof(*mip));
if (mip == NULL)
diff --git a/drivers/net/nfp/nfpcore/nfp_mutex.c b/drivers/net/nfp/nfpcore/nfp_mutex.c
index edc8137304..5be437b354 100644
--- a/drivers/net/nfp/nfpcore/nfp_mutex.c
+++ b/drivers/net/nfp/nfpcore/nfp_mutex.c
@@ -79,9 +79,9 @@ nfp_cpp_mutex_init(struct nfp_cpp *cpp,
uint64_t address,
uint32_t key)
{
+ int err;
uint32_t model = nfp_cpp_model(cpp);
uint32_t muw = NFP_CPP_ID(target, 4, 0); /* atomic_write */
- int err;
err = _nfp_cpp_mutex_validate(model, &target, address);
if (err < 0)
@@ -122,11 +122,11 @@ nfp_cpp_mutex_alloc(struct nfp_cpp *cpp,
uint64_t address,
uint32_t key)
{
- uint32_t model = nfp_cpp_model(cpp);
- struct nfp_cpp_mutex *mutex;
- uint32_t mur = NFP_CPP_ID(target, 3, 0); /* atomic_read */
int err;
uint32_t tmp;
+ struct nfp_cpp_mutex *mutex;
+ uint32_t model = nfp_cpp_model(cpp);
+ uint32_t mur = NFP_CPP_ID(target, 3, 0); /* atomic_read */
/* Look for cached mutex */
for (mutex = cpp->mutex_cache; mutex; mutex = mutex->next) {
@@ -242,12 +242,13 @@ nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
int
nfp_cpp_mutex_unlock(struct nfp_cpp_mutex *mutex)
{
- uint32_t muw = NFP_CPP_ID(mutex->target, 4, 0); /* atomic_write */
- uint32_t mur = NFP_CPP_ID(mutex->target, 3, 0); /* atomic_read */
+ int err;
+ uint32_t key;
+ uint32_t value;
struct nfp_cpp *cpp = mutex->cpp;
- uint32_t key, value;
uint16_t interface = nfp_cpp_interface(cpp);
- int err;
+ uint32_t muw = NFP_CPP_ID(mutex->target, 4, 0); /* atomic_write */
+ uint32_t mur = NFP_CPP_ID(mutex->target, 3, 0); /* atomic_read */
if (mutex->depth > 1) {
mutex->depth--;
@@ -296,12 +297,14 @@ nfp_cpp_mutex_unlock(struct nfp_cpp_mutex *mutex)
int
nfp_cpp_mutex_trylock(struct nfp_cpp_mutex *mutex)
{
+ int err;
+ uint32_t key;
+ uint32_t tmp;
+ uint32_t value;
+ struct nfp_cpp *cpp = mutex->cpp;
uint32_t mur = NFP_CPP_ID(mutex->target, 3, 0); /* atomic_read */
uint32_t muw = NFP_CPP_ID(mutex->target, 4, 0); /* atomic_write */
uint32_t mus = NFP_CPP_ID(mutex->target, 5, 3); /* test_set_imm */
- uint32_t key, value, tmp;
- struct nfp_cpp *cpp = mutex->cpp;
- int err;
if (mutex->depth > 0) {
if (mutex->depth == MUTEX_DEPTH_MAX)
diff --git a/drivers/net/nfp/nfpcore/nfp_nffw.c b/drivers/net/nfp/nfpcore/nfp_nffw.c
index 2412dc0e00..9123fc742a 100644
--- a/drivers/net/nfp/nfpcore/nfp_nffw.c
+++ b/drivers/net/nfp/nfpcore/nfp_nffw.c
@@ -68,9 +68,11 @@ nffw_fwinfo_mip_offset_get(const struct nffw_fwinfo *fi)
static int
nfp_mip_mu_locality_lsb(struct nfp_cpp *cpp)
{
- uint32_t mode, addr40;
- uint32_t xpbaddr, imbcppat;
int err;
+ uint32_t mode;
+ uint32_t addr40;
+ uint32_t xpbaddr;
+ uint32_t imbcppat;
/* Hardcoded XPB IMB Base, island 0 */
xpbaddr = 0x000a0000 + NFP_CPP_TARGET_MU * 4;
@@ -118,10 +120,10 @@ nffw_res_fwinfos(struct nfp_nffw_info_data *fwinf,
struct nfp_nffw_info *
nfp_nffw_info_open(struct nfp_cpp *cpp)
{
- struct nfp_nffw_info_data *fwinf;
- struct nfp_nffw_info *state;
- uint32_t info_ver;
int err;
+ uint32_t info_ver;
+ struct nfp_nffw_info *state;
+ struct nfp_nffw_info_data *fwinf;
state = malloc(sizeof(*state));
if (state == NULL)
@@ -183,8 +185,9 @@ nfp_nffw_info_close(struct nfp_nffw_info *state)
static struct nffw_fwinfo *
nfp_nffw_info_fwid_first(struct nfp_nffw_info *state)
{
+ uint32_t i;
+ uint32_t cnt;
struct nffw_fwinfo *fwinfo;
- uint32_t cnt, i;
cnt = nffw_res_fwinfos(&state->fwinf, &fwinfo);
if (cnt == 0)
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.c b/drivers/net/nfp/nfpcore/nfp_nsp.c
index dfe396c8ac..4861772a98 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.c
@@ -72,10 +72,11 @@ nfp_nsp_print_extended_error(uint32_t ret_val)
static int
nfp_nsp_check(struct nfp_nsp *state)
{
- struct nfp_cpp *cpp = state->cpp;
- uint64_t nsp_status, reg;
- uint32_t nsp_cpp;
int err;
+ uint64_t reg;
+ uint32_t nsp_cpp;
+ uint64_t nsp_status;
+ struct nfp_cpp *cpp = state->cpp;
nsp_cpp = nfp_resource_cpp_id(state->res);
nsp_status = nfp_resource_address(state->res) + NSP_STATUS;
@@ -113,9 +114,9 @@ nfp_nsp_check(struct nfp_nsp *state)
struct nfp_nsp *
nfp_nsp_open(struct nfp_cpp *cpp)
{
- struct nfp_resource *res;
- struct nfp_nsp *state;
int err;
+ struct nfp_nsp *state;
+ struct nfp_resource *res;
res = nfp_resource_acquire(cpp, NFP_RESOURCE_NSP);
if (res == NULL)
@@ -170,13 +171,12 @@ nfp_nsp_wait_reg(struct nfp_cpp *cpp,
uint64_t mask,
uint64_t val)
{
- struct timespec wait;
- uint32_t count;
int err;
+ uint32_t count = 0;
+ struct timespec wait;
wait.tv_sec = 0;
wait.tv_nsec = 25000000;
- count = 0;
for (;;) {
err = nfp_cpp_readq(cpp, nsp_cpp, addr, reg);
@@ -217,10 +217,15 @@ nfp_nsp_command(struct nfp_nsp *state,
uint32_t buff_cpp,
uint64_t buff_addr)
{
- uint64_t reg, ret_val, nsp_base, nsp_buffer, nsp_status, nsp_command;
- struct nfp_cpp *cpp = state->cpp;
- uint32_t nsp_cpp;
int err;
+ uint64_t reg;
+ uint32_t nsp_cpp;
+ uint64_t ret_val;
+ uint64_t nsp_base;
+ uint64_t nsp_buffer;
+ uint64_t nsp_status;
+ uint64_t nsp_command;
+ struct nfp_cpp *cpp = state->cpp;
nsp_cpp = nfp_resource_cpp_id(state->res);
nsp_base = nfp_resource_address(state->res);
@@ -296,11 +301,13 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp,
void *out_buf,
unsigned int out_size)
{
- struct nfp_cpp *cpp = nsp->cpp;
+ int err;
+ int ret;
+ uint64_t reg;
size_t max_size;
- uint64_t reg, cpp_buf;
- int ret, err;
uint32_t cpp_id;
+ uint64_t cpp_buf;
+ struct nfp_cpp *cpp = nsp->cpp;
if (nsp->ver.minor < 13) {
PMD_DRV_LOG(ERR, "NSP: Code 0x%04x with buffer not supported ABI %hu.%hu)",
@@ -360,13 +367,12 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp,
int
nfp_nsp_wait(struct nfp_nsp *state)
{
- struct timespec wait;
- uint32_t count;
int err;
+ int count = 0;
+ struct timespec wait;
wait.tv_sec = 0;
wait.tv_nsec = 25000000;
- count = 0;
for (;;) {
err = nfp_nsp_command(state, SPCODE_NOOP, 0, 0, 0);
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
index 31677b66e6..3081e22dad 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
@@ -26,9 +26,9 @@ struct nsp_identify {
struct nfp_nsp_identify *
__nfp_nsp_identify(struct nfp_nsp *nsp)
{
- struct nfp_nsp_identify *nspi = NULL;
- struct nsp_identify *ni;
int ret;
+ struct nsp_identify *ni;
+ struct nfp_nsp_identify *nspi = NULL;
if (nfp_nsp_get_abi_ver_minor(nsp) < 15)
return NULL;
@@ -77,9 +77,9 @@ nfp_hwmon_read_sensor(struct nfp_cpp *cpp,
enum nfp_nsp_sensor_id id,
uint32_t *val)
{
- struct nfp_sensors s;
- struct nfp_nsp *nsp;
int ret;
+ struct nfp_nsp *nsp;
+ struct nfp_sensors s;
nsp = nfp_nsp_open(cpp);
if (nsp == NULL)
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
index bc155b44d8..9b7c8aa7f8 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
@@ -150,9 +150,10 @@ nfp_eth_port_translate(struct nfp_nsp *nsp,
uint32_t index,
struct nfp_eth_table_port *dst)
{
- uint32_t rate;
uint32_t fec;
- uint64_t port, state;
+ uint64_t port;
+ uint32_t rate;
+ uint64_t state;
port = rte_le_to_cpu_64(src->port);
state = rte_le_to_cpu_64(src->state);
@@ -200,7 +201,8 @@ nfp_eth_port_translate(struct nfp_nsp *nsp,
static void
nfp_eth_calc_port_geometry(struct nfp_eth_table *table)
{
- uint32_t i, j;
+ uint32_t i;
+ uint32_t j;
for (i = 0; i < table->count; i++) {
table->max_index = RTE_MAX(table->max_index,
@@ -242,12 +244,13 @@ nfp_eth_calc_port_type(struct nfp_eth_table_port *entry)
static struct nfp_eth_table *
__nfp_eth_read_ports(struct nfp_nsp *nsp)
{
- union eth_table_entry *entries;
- struct nfp_eth_table *table;
- uint32_t table_sz;
+ int ret;
uint32_t i;
uint32_t j;
- int ret, cnt = 0;
+ int cnt = 0;
+ uint32_t table_sz;
+ struct nfp_eth_table *table;
+ union eth_table_entry *entries;
const struct rte_ether_addr *mac;
entries = malloc(NSP_ETH_TABLE_SIZE);
@@ -321,8 +324,8 @@ __nfp_eth_read_ports(struct nfp_nsp *nsp)
struct nfp_eth_table *
nfp_eth_read_ports(struct nfp_cpp *cpp)
{
- struct nfp_eth_table *ret;
struct nfp_nsp *nsp;
+ struct nfp_eth_table *ret;
nsp = nfp_nsp_open(cpp);
if (nsp == NULL)
@@ -338,9 +341,9 @@ struct nfp_nsp *
nfp_eth_config_start(struct nfp_cpp *cpp,
uint32_t idx)
{
- union eth_table_entry *entries;
- struct nfp_nsp *nsp;
int ret;
+ struct nfp_nsp *nsp;
+ union eth_table_entry *entries;
entries = malloc(NSP_ETH_TABLE_SIZE);
if (entries == NULL)
@@ -401,8 +404,8 @@ nfp_eth_config_cleanup_end(struct nfp_nsp *nsp)
int
nfp_eth_config_commit_end(struct nfp_nsp *nsp)
{
- union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
int ret = 1;
+ union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
if (nfp_nsp_config_modified(nsp)) {
ret = nfp_nsp_write_eth_table(nsp, entries, NSP_ETH_TABLE_SIZE);
@@ -433,9 +436,9 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
uint32_t idx,
int enable)
{
- union eth_table_entry *entries;
- struct nfp_nsp *nsp;
uint64_t reg;
+ struct nfp_nsp *nsp;
+ union eth_table_entry *entries;
nsp = nfp_eth_config_start(cpp, idx);
if (nsp == NULL)
@@ -475,9 +478,9 @@ nfp_eth_set_configured(struct nfp_cpp *cpp,
uint32_t idx,
int configed)
{
- union eth_table_entry *entries;
- struct nfp_nsp *nsp;
uint64_t reg;
+ struct nfp_nsp *nsp;
+ union eth_table_entry *entries;
nsp = nfp_eth_config_start(cpp, idx);
if (nsp == NULL)
@@ -516,9 +519,9 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp,
uint32_t val,
const uint64_t ctrl_bit)
{
- union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
- uint32_t idx = nfp_nsp_config_idx(nsp);
uint64_t reg;
+ uint32_t idx = nfp_nsp_config_idx(nsp);
+ union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
/*
* Note: set features were added in ABI 0.14 but the error
@@ -604,8 +607,8 @@ nfp_eth_set_fec(struct nfp_cpp *cpp,
uint32_t idx,
enum nfp_eth_fec mode)
{
- struct nfp_nsp *nsp;
int err;
+ struct nfp_nsp *nsp;
nsp = nfp_eth_config_start(cpp, idx);
if (nsp == NULL)
diff --git a/drivers/net/nfp/nfpcore/nfp_resource.c b/drivers/net/nfp/nfpcore/nfp_resource.c
index 9dd4832779..fa92f2762e 100644
--- a/drivers/net/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/nfp/nfpcore/nfp_resource.c
@@ -67,10 +67,12 @@ static int
nfp_cpp_resource_find(struct nfp_cpp *cpp,
struct nfp_resource *res)
{
- char name_pad[NFP_RESOURCE_ENTRY_NAME_SZ + 2];
+ int ret;
+ uint32_t i;
+ uint32_t key;
+ uint32_t cpp_id;
struct nfp_resource_entry entry;
- uint32_t cpp_id, key;
- int ret, i;
+ char name_pad[NFP_RESOURCE_ENTRY_NAME_SZ + 2];
cpp_id = NFP_CPP_ID(NFP_RESOURCE_TBL_TARGET, 3, 0); /* Atomic read */
@@ -152,11 +154,11 @@ struct nfp_resource *
nfp_resource_acquire(struct nfp_cpp *cpp,
const char *name)
{
- struct nfp_cpp_mutex *dev_mutex;
- struct nfp_resource *res;
int err;
+ uint16_t count = 0;
struct timespec wait;
- uint16_t count;
+ struct nfp_resource *res;
+ struct nfp_cpp_mutex *dev_mutex;
res = malloc(sizeof(*res));
if (res == NULL)
@@ -175,7 +177,6 @@ nfp_resource_acquire(struct nfp_cpp *cpp,
wait.tv_sec = 0;
wait.tv_nsec = 1000000;
- count = 0;
for (;;) {
err = nfp_resource_try_acquire(cpp, res, dev_mutex);
diff --git a/drivers/net/nfp/nfpcore/nfp_rtsym.c b/drivers/net/nfp/nfpcore/nfp_rtsym.c
index 243d3c9ce5..a34278beca 100644
--- a/drivers/net/nfp/nfpcore/nfp_rtsym.c
+++ b/drivers/net/nfp/nfpcore/nfp_rtsym.c
@@ -85,8 +85,8 @@ nfp_rtsym_sw_entry_init(struct nfp_rtsym_table *cache,
struct nfp_rtsym_table *
nfp_rtsym_table_read(struct nfp_cpp *cpp)
{
- struct nfp_rtsym_table *rtbl;
struct nfp_mip *mip;
+ struct nfp_rtsym_table *rtbl;
mip = nfp_mip_open(cpp);
rtbl = __nfp_rtsym_table_read(cpp, mip);
@@ -99,13 +99,18 @@ struct nfp_rtsym_table *
__nfp_rtsym_table_read(struct nfp_cpp *cpp,
const struct nfp_mip *mip)
{
- uint32_t strtab_addr, symtab_addr, strtab_size, symtab_size;
- struct nfp_rtsym_entry *rtsymtab;
+ int n;
+ int err;
+ uint32_t size;
+ uint32_t strtab_addr;
+ uint32_t symtab_addr;
+ uint32_t strtab_size;
+ uint32_t symtab_size;
struct nfp_rtsym_table *cache;
+ struct nfp_rtsym_entry *rtsymtab;
const uint32_t dram =
NFP_CPP_ID(NFP_CPP_TARGET_MU, NFP_CPP_ACTION_RW, 0) |
NFP_ISL_EMEM0;
- int err, n, size;
if (mip == NULL)
return NULL;
@@ -341,10 +346,10 @@ nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl,
const char *name,
int *error)
{
- const struct nfp_rtsym *sym;
- uint32_t val32;
- uint64_t val;
int err;
+ uint64_t val;
+ uint32_t val32;
+ const struct nfp_rtsym *sym;
sym = nfp_rtsym_lookup(rtbl, name);
if (sym == NULL) {
--
2.39.1
^ permalink raw reply [relevance 3%]
* [PATCH v5 07/26] net/nfp: standard the comment style
2023-09-19 9:54 1% ` [PATCH v5 02/26] net/nfp: unify the indent coding style Chaoyong He
2023-09-19 9:54 3% ` [PATCH v5 05/26] net/nfp: standard the local variable " Chaoyong He
@ 2023-09-19 9:54 1% ` Chaoyong He
2023-09-19 9:54 5% ` [PATCH v5 18/26] net/nfp: refact the nsp module Chaoyong He
3 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-09-19 9:54 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Chaoyong He
Follow the DPDK coding style, use the kdoc comment style.
Also move the comment of the functions to the implement file and
add some comment to help understand logic.
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
---
drivers/net/nfp/nfpcore/nfp_cpp.h | 504 ++++-----------------
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 39 +-
drivers/net/nfp/nfpcore/nfp_cppcore.c | 484 ++++++++++++++++----
drivers/net/nfp/nfpcore/nfp_hwinfo.c | 21 +-
drivers/net/nfp/nfpcore/nfp_hwinfo.h | 2 +
drivers/net/nfp/nfpcore/nfp_mip.c | 43 +-
drivers/net/nfp/nfpcore/nfp_mutex.c | 69 +--
drivers/net/nfp/nfpcore/nfp_nffw.c | 49 +-
drivers/net/nfp/nfpcore/nfp_nffw.h | 6 +-
drivers/net/nfp/nfpcore/nfp_nsp.c | 53 ++-
drivers/net/nfp/nfpcore/nfp_nsp.h | 108 ++---
drivers/net/nfp/nfpcore/nfp_nsp_eth.c | 170 ++++---
drivers/net/nfp/nfpcore/nfp_resource.c | 103 +++--
drivers/net/nfp/nfpcore/nfp_resource.h | 28 +-
drivers/net/nfp/nfpcore/nfp_rtsym.c | 59 ++-
drivers/net/nfp/nfpcore/nfp_rtsym.h | 12 +-
drivers/net/nfp/nfpcore/nfp_target.c | 2 +-
17 files changed, 888 insertions(+), 864 deletions(-)
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp.h b/drivers/net/nfp/nfpcore/nfp_cpp.h
index 139752f85a..82189e9910 100644
--- a/drivers/net/nfp/nfpcore/nfp_cpp.h
+++ b/drivers/net/nfp/nfpcore/nfp_cpp.h
@@ -10,9 +10,7 @@
struct nfp_cpp_mutex;
-/*
- * NFP CPP handle
- */
+/* NFP CPP handle */
struct nfp_cpp {
uint32_t model;
uint32_t interface;
@@ -37,9 +35,7 @@ struct nfp_cpp {
int driver_lock_needed;
};
-/*
- * NFP CPP device area handle
- */
+/* NFP CPP device area handle */
struct nfp_cpp_area {
struct nfp_cpp *cpp;
char *name;
@@ -127,35 +123,45 @@ struct nfp_cpp_operations {
#define NFP_CPP_TARGET_ID_MASK 0x1f
-/*
+/**
* Pack target, token, and action into a CPP ID.
*
* Create a 32-bit CPP identifier representing the access to be made.
* These identifiers are used as parameters to other NFP CPP functions.
* Some CPP devices may allow wildcard identifiers to be specified.
*
- * @target NFP CPP target id
- * @action NFP CPP action id
- * @token NFP CPP token id
+ * @param target
+ * NFP CPP target id
+ * @param action
+ * NFP CPP action id
+ * @param token
+ * NFP CPP token id
*
- * @return NFP CPP ID
+ * @return
+ * NFP CPP ID
*/
#define NFP_CPP_ID(target, action, token) \
((((target) & 0x7f) << 24) | (((token) & 0xff) << 16) | \
(((action) & 0xff) << 8))
-/*
+/**
* Pack target, token, action, and island into a CPP ID.
- * @target NFP CPP target id
- * @action NFP CPP action id
- * @token NFP CPP token id
- * @island NFP CPP island id
*
* Create a 32-bit CPP identifier representing the access to be made.
* These identifiers are used as parameters to other NFP CPP functions.
* Some CPP devices may allow wildcard identifiers to be specified.
*
- * @return NFP CPP ID
+ * @param target
+ * NFP CPP target id
+ * @param action
+ * NFP CPP action id
+ * @param token
+ * NFP CPP token id
+ * @param island
+ * NFP CPP island id
+ *
+ * @return
+ * NFP CPP ID
*/
#define NFP_CPP_ISLAND_ID(target, action, token, island) \
((((target) & 0x7f) << 24) | (((token) & 0xff) << 16) | \
@@ -163,9 +169,12 @@ struct nfp_cpp_operations {
/**
* Return the NFP CPP target of a NFP CPP ID
- * @id NFP CPP ID
*
- * @return NFP CPP target
+ * @param id
+ * NFP CPP ID
+ *
+ * @return
+ * NFP CPP target
*/
static inline uint8_t
NFP_CPP_ID_TARGET_of(uint32_t id)
@@ -173,11 +182,14 @@ NFP_CPP_ID_TARGET_of(uint32_t id)
return (id >> 24) & NFP_CPP_TARGET_ID_MASK;
}
-/*
+/**
* Return the NFP CPP token of a NFP CPP ID
- * @id NFP CPP ID
*
- * @return NFP CPP token
+ * @param id
+ * NFP CPP ID
+ *
+ * @return
+ * NFP CPP token
*/
static inline uint8_t
NFP_CPP_ID_TOKEN_of(uint32_t id)
@@ -185,11 +197,14 @@ NFP_CPP_ID_TOKEN_of(uint32_t id)
return (id >> 16) & 0xff;
}
-/*
+/**
* Return the NFP CPP action of a NFP CPP ID
- * @id NFP CPP ID
*
- * @return NFP CPP action
+ * @param id
+ * NFP CPP ID
+ *
+ * @return
+ * NFP CPP action
*/
static inline uint8_t
NFP_CPP_ID_ACTION_of(uint32_t id)
@@ -197,11 +212,14 @@ NFP_CPP_ID_ACTION_of(uint32_t id)
return (id >> 8) & 0xff;
}
-/*
+/**
* Return the NFP CPP island of a NFP CPP ID
- * @id NFP CPP ID
*
- * @return NFP CPP island
+ * @param id
+ * NFP CPP ID
+ *
+ * @return
+ * NFP CPP island
*/
static inline uint8_t
NFP_CPP_ID_ISLAND_of(uint32_t id)
@@ -215,109 +233,57 @@ NFP_CPP_ID_ISLAND_of(uint32_t id)
*/
const struct nfp_cpp_operations *nfp_cpp_transport_operations(void);
-/*
- * Set the model id
- *
- * @param cpp NFP CPP operations structure
- * @param model Model ID
- */
void nfp_cpp_model_set(struct nfp_cpp *cpp, uint32_t model);
-/*
- * Set the private instance owned data of a nfp_cpp struct
- *
- * @param cpp NFP CPP operations structure
- * @param interface Interface ID
- */
void nfp_cpp_interface_set(struct nfp_cpp *cpp, uint32_t interface);
-/*
- * Set the private instance owned data of a nfp_cpp struct
- *
- * @param cpp NFP CPP operations structure
- * @param serial NFP serial byte array
- * @param len Length of the serial byte array
- */
int nfp_cpp_serial_set(struct nfp_cpp *cpp, const uint8_t *serial,
size_t serial_len);
-/*
- * Set the private data of the nfp_cpp instance
- *
- * @param cpp NFP CPP operations structure
- * @return Opaque device pointer
- */
void nfp_cpp_priv_set(struct nfp_cpp *cpp, void *priv);
-/*
- * Return the private data of the nfp_cpp instance
- *
- * @param cpp NFP CPP operations structure
- * @return Opaque device pointer
- */
void *nfp_cpp_priv(struct nfp_cpp *cpp);
-/*
- * Get the privately allocated portion of a NFP CPP area handle
- *
- * @param cpp_area NFP CPP area handle
- * @return Pointer to the private area, or NULL on failure
- */
void *nfp_cpp_area_priv(struct nfp_cpp_area *cpp_area);
uint32_t __nfp_cpp_model_autodetect(struct nfp_cpp *cpp, uint32_t *model);
-/*
- * NFP CPP core interface for CPP clients.
- */
-
-/*
- * Open a NFP CPP handle to a CPP device
- *
- * @param[in] id 0-based ID for the CPP interface to use
- *
- * @return NFP CPP handle, or NULL on failure.
- */
+/* NFP CPP core interface for CPP clients */
struct nfp_cpp *nfp_cpp_from_device_name(struct rte_pci_device *dev,
int driver_lock_needed);
-/*
- * Free a NFP CPP handle
- *
- * @param[in] cpp NFP CPP handle
- */
void nfp_cpp_free(struct nfp_cpp *cpp);
#define NFP_CPP_MODEL_INVALID 0xffffffff
-/*
- * NFP_CPP_MODEL_CHIP_of - retrieve the chip ID from the model ID
+/**
+ * Retrieve the chip ID from the model ID
*
* The chip ID is a 16-bit BCD+A-F encoding for the chip type.
*
- * @param[in] model NFP CPP model id
- * @return NFP CPP chip id
+ * @param model
+ * NFP CPP model id
+ *
+ * @return
+ * NFP CPP chip id
*/
#define NFP_CPP_MODEL_CHIP_of(model) (((model) >> 16) & 0xffff)
-/*
- * NFP_CPP_MODEL_IS_6000 - Check for the NFP6000 family of devices
+/**
+ * Check for the NFP6000 family of devices
*
* NOTE: The NFP4000 series is considered as a NFP6000 series variant.
*
- * @param[in] model NFP CPP model id
- * @return true if model is in the NFP6000 family, false otherwise.
+ * @param model
+ * NFP CPP model id
+ *
+ * @return
+ * true if model is in the NFP6000 family, false otherwise.
*/
#define NFP_CPP_MODEL_IS_6000(model) \
((NFP_CPP_MODEL_CHIP_of(model) >= 0x3800) && \
(NFP_CPP_MODEL_CHIP_of(model) < 0x7000))
-/*
- * nfp_cpp_model - Retrieve the Model ID of the NFP
- *
- * @param[in] cpp NFP CPP handle
- * @return NFP CPP Model ID
- */
uint32_t nfp_cpp_model(struct nfp_cpp *cpp);
/*
@@ -330,7 +296,7 @@ uint32_t nfp_cpp_model(struct nfp_cpp *cpp);
#define NFP_CPP_INTERFACE_TYPE_RPC 0x3
#define NFP_CPP_INTERFACE_TYPE_ILA 0x4
-/*
+/**
* Construct a 16-bit NFP Interface ID
*
* Interface IDs consists of 4 bits of interface type, 4 bits of unit
@@ -340,422 +306,138 @@ uint32_t nfp_cpp_model(struct nfp_cpp *cpp);
* which use the MU Atomic CompareAndWrite operation - hence the limit to 16
* bits to be able to use the NFP Interface ID as a lock owner.
*
- * @param[in] type NFP Interface Type
- * @param[in] unit Unit identifier for the interface type
- * @param[in] channel Channel identifier for the interface unit
- * @return Interface ID
+ * @param type
+ * NFP Interface Type
+ * @param unit
+ * Unit identifier for the interface type
+ * @param channel
+ * Channel identifier for the interface unit
+ *
+ * @return
+ * Interface ID
*/
#define NFP_CPP_INTERFACE(type, unit, channel) \
((((type) & 0xf) << 12) | \
(((unit) & 0xf) << 8) | \
(((channel) & 0xff) << 0))
-/*
+/**
* Get the interface type of a NFP Interface ID
- * @param[in] interface NFP Interface ID
- * @return NFP Interface ID's type
+ *
+ * @param interface
+ * NFP Interface ID
+ *
+ * @return
+ * NFP Interface ID's type
*/
#define NFP_CPP_INTERFACE_TYPE_of(interface) (((interface) >> 12) & 0xf)
-/*
+/**
* Get the interface unit of a NFP Interface ID
- * @param[in] interface NFP Interface ID
- * @return NFP Interface ID's unit
+ *
+ * @param interface
+ * NFP Interface ID
+ *
+ * @return
+ * NFP Interface ID's unit
*/
#define NFP_CPP_INTERFACE_UNIT_of(interface) (((interface) >> 8) & 0xf)
-/*
+/**
* Get the interface channel of a NFP Interface ID
- * @param[in] interface NFP Interface ID
- * @return NFP Interface ID's channel
+ *
+ * @param interface
+ * NFP Interface ID
+ *
+ * @return
+ * NFP Interface ID's channel
*/
#define NFP_CPP_INTERFACE_CHANNEL_of(interface) (((interface) >> 0) & 0xff)
-/*
- * Retrieve the Interface ID of the NFP
- * @param[in] cpp NFP CPP handle
- * @return NFP CPP Interface ID
- */
+
uint16_t nfp_cpp_interface(struct nfp_cpp *cpp);
-/*
- * Retrieve the NFP Serial Number (unique per NFP)
- * @param[in] cpp NFP CPP handle
- * @param[out] serial Pointer to reference the serial number array
- *
- * @return size of the NFP6000 serial number, in bytes
- */
int nfp_cpp_serial(struct nfp_cpp *cpp, const uint8_t **serial);
-/*
- * Allocate a NFP CPP area handle, as an offset into a CPP ID
- * @param[in] cpp NFP CPP handle
- * @param[in] cpp_id NFP CPP ID
- * @param[in] address Offset into the NFP CPP ID address space
- * @param[in] size Size of the area to reserve
- *
- * @return NFP CPP handle, or NULL on failure.
- */
struct nfp_cpp_area *nfp_cpp_area_alloc(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, size_t size);
-/*
- * Allocate a NFP CPP area handle, as an offset into a CPP ID, by a named owner
- * @param[in] cpp NFP CPP handle
- * @param[in] cpp_id NFP CPP ID
- * @param[in] name Name of owner of the area
- * @param[in] address Offset into the NFP CPP ID address space
- * @param[in] size Size of the area to reserve
- *
- * @return NFP CPP handle, or NULL on failure.
- */
struct nfp_cpp_area *nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
uint32_t cpp_id, const char *name, uint64_t address,
uint32_t size);
-/*
- * Free an allocated NFP CPP area handle
- * @param[in] area NFP CPP area handle
- */
void nfp_cpp_area_free(struct nfp_cpp_area *area);
-/*
- * Acquire the resources needed to access the NFP CPP area handle
- *
- * @param[in] area NFP CPP area handle
- *
- * @return 0 on success, -1 on failure.
- */
int nfp_cpp_area_acquire(struct nfp_cpp_area *area);
-/*
- * Release the resources needed to access the NFP CPP area handle
- *
- * @param[in] area NFP CPP area handle
- */
void nfp_cpp_area_release(struct nfp_cpp_area *area);
-/*
- * Allocate, then acquire the resources needed to access the NFP CPP area handle
- * @param[in] cpp NFP CPP handle
- * @param[in] cpp_id NFP CPP ID
- * @param[in] address Offset into the NFP CPP ID address space
- * @param[in] size Size of the area to reserve
- *
- * @return NFP CPP handle, or NULL on failure.
- */
struct nfp_cpp_area *nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp,
uint32_t cpp_id, uint64_t address, size_t size);
-/*
- * Release the resources, then free the NFP CPP area handle
- * @param[in] area NFP CPP area handle
- */
void nfp_cpp_area_release_free(struct nfp_cpp_area *area);
uint8_t *nfp_cpp_map_area(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t addr, uint32_t size, struct nfp_cpp_area **area);
-/*
- * Read from a NFP CPP area handle into a buffer. The area must be acquired with
- * 'nfp_cpp_area_acquire()' before calling this operation.
- *
- * @param[in] area NFP CPP area handle
- * @param[in] offset Offset into the area
- * @param[in] buffer Location of buffer to receive the data
- * @param[in] length Length of the data to read
- *
- * @return bytes read on success, negative value on failure.
- *
- */
int nfp_cpp_area_read(struct nfp_cpp_area *area, uint32_t offset,
void *buffer, size_t length);
-/*
- * Write to a NFP CPP area handle from a buffer. The area must be acquired with
- * 'nfp_cpp_area_acquire()' before calling this operation.
- *
- * @param[in] area NFP CPP area handle
- * @param[in] offset Offset into the area
- * @param[in] buffer Location of buffer that holds the data
- * @param[in] length Length of the data to read
- *
- * @return bytes written on success, negative value on failure.
- */
int nfp_cpp_area_write(struct nfp_cpp_area *area, uint32_t offset,
const void *buffer, size_t length);
-/*
- * nfp_cpp_area_iomem() - get IOMEM region for CPP area
- * @area: CPP area handle
- *
- * Returns an iomem pointer for use with readl()/writel() style operations.
- *
- * NOTE: Area must have been locked down with an 'acquire'.
- *
- * Return: pointer to the area, or NULL
- */
void *nfp_cpp_area_iomem(struct nfp_cpp_area *area);
-/*
- * Get the NFP CPP handle that is the parent of a NFP CPP area handle
- *
- * @param cpp_area NFP CPP area handle
- * @return NFP CPP handle
- */
struct nfp_cpp *nfp_cpp_area_cpp(struct nfp_cpp_area *cpp_area);
-/*
- * Get the name passed during allocation of the NFP CPP area handle
- *
- * @param cpp_area NFP CPP area handle
- * @return Pointer to the area's name
- */
const char *nfp_cpp_area_name(struct nfp_cpp_area *cpp_area);
-/*
- * Read a block of data from a NFP CPP ID
- *
- * @param[in] cpp NFP CPP handle
- * @param[in] cpp_id NFP CPP ID
- * @param[in] address Offset into the NFP CPP ID address space
- * @param[in] kernel_vaddr Buffer to copy read data to
- * @param[in] length Size of the area to reserve
- *
- * @return bytes read on success, -1 on failure.
- */
int nfp_cpp_read(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, void *kernel_vaddr, size_t length);
-/*
- * Write a block of data to a NFP CPP ID
- *
- * @param[in] cpp NFP CPP handle
- * @param[in] cpp_id NFP CPP ID
- * @param[in] address Offset into the NFP CPP ID address space
- * @param[in] kernel_vaddr Buffer to copy write data from
- * @param[in] length Size of the area to reserve
- *
- * @return bytes written on success, -1 on failure.
- */
int nfp_cpp_write(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, const void *kernel_vaddr, size_t length);
-/*
- * Read a single 32-bit value from a NFP CPP area handle
- *
- * @param area NFP CPP area handle
- * @param offset offset into NFP CPP area handle
- * @param value output value
- *
- * The area must be acquired with 'nfp_cpp_area_acquire()' before calling this
- * operation.
- *
- * NOTE: offset must be 32-bit aligned.
- *
- * @return 0 on success, or -1 on error.
- */
int nfp_cpp_area_readl(struct nfp_cpp_area *area, uint32_t offset,
uint32_t *value);
-/*
- * Write a single 32-bit value to a NFP CPP area handle
- *
- * @param area NFP CPP area handle
- * @param offset offset into NFP CPP area handle
- * @param value value to write
- *
- * The area must be acquired with 'nfp_cpp_area_acquire()' before calling this
- * operation.
- *
- * NOTE: offset must be 32-bit aligned.
- *
- * @return 0 on success, or -1 on error.
- */
int nfp_cpp_area_writel(struct nfp_cpp_area *area, uint32_t offset,
uint32_t value);
-/*
- * Read a single 64-bit value from a NFP CPP area handle
- *
- * @param area NFP CPP area handle
- * @param offset offset into NFP CPP area handle
- * @param value output value
- *
- * The area must be acquired with 'nfp_cpp_area_acquire()' before calling this
- * operation.
- *
- * NOTE: offset must be 64-bit aligned.
- *
- * @return 0 on success, or -1 on error.
- */
int nfp_cpp_area_readq(struct nfp_cpp_area *area, uint32_t offset,
uint64_t *value);
-/*
- * Write a single 64-bit value to a NFP CPP area handle
- *
- * @param area NFP CPP area handle
- * @param offset offset into NFP CPP area handle
- * @param value value to write
- *
- * The area must be acquired with 'nfp_cpp_area_acquire()' before calling this
- * operation.
- *
- * NOTE: offset must be 64-bit aligned.
- *
- * @return 0 on success, or -1 on error.
- */
int nfp_cpp_area_writeq(struct nfp_cpp_area *area, uint32_t offset,
uint64_t value);
-/*
- * Write a single 32-bit value on the XPB bus
- *
- * @param cpp NFP CPP device handle
- * @param xpb_tgt XPB target and address
- * @param value value to write
- *
- * @return 0 on success, or -1 on failure.
- */
int nfp_xpb_writel(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t value);
-/*
- * Read a single 32-bit value from the XPB bus
- *
- * @param cpp NFP CPP device handle
- * @param xpb_tgt XPB target and address
- * @param value output value
- *
- * @return 0 on success, or -1 on failure.
- */
int nfp_xpb_readl(struct nfp_cpp *cpp, uint32_t xpb_tgt, uint32_t *value);
-/*
- * Read a 32-bit word from a NFP CPP ID
- *
- * @param cpp NFP CPP handle
- * @param cpp_id NFP CPP ID
- * @param address offset into the NFP CPP ID address space
- * @param value output value
- *
- * @return 0 on success, or -1 on failure.
- */
int nfp_cpp_readl(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, uint32_t *value);
-/*
- * Write a 32-bit value to a NFP CPP ID
- *
- * @param cpp NFP CPP handle
- * @param cpp_id NFP CPP ID
- * @param address offset into the NFP CPP ID address space
- * @param value value to write
- *
- * @return 0 on success, or -1 on failure.
- *
- */
int nfp_cpp_writel(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, uint32_t value);
-/*
- * Read a 64-bit work from a NFP CPP ID
- *
- * @param cpp NFP CPP handle
- * @param cpp_id NFP CPP ID
- * @param address offset into the NFP CPP ID address space
- * @param value output value
- *
- * @return 0 on success, or -1 on failure.
- */
int nfp_cpp_readq(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, uint64_t *value);
-/*
- * Write a 64-bit value to a NFP CPP ID
- *
- * @param cpp NFP CPP handle
- * @param cpp_id NFP CPP ID
- * @param address offset into the NFP CPP ID address space
- * @param value value to write
- *
- * @return 0 on success, or -1 on failure.
- */
int nfp_cpp_writeq(struct nfp_cpp *cpp, uint32_t cpp_id,
uint64_t address, uint64_t value);
-/*
- * Initialize a mutex location
-
- * The CPP target:address must point to a 64-bit aligned location, and will
- * initialize 64 bits of data at the location.
- *
- * This creates the initial mutex state, as locked by this nfp_cpp_interface().
- *
- * This function should only be called when setting up the initial lock state
- * upon boot-up of the system.
- *
- * @param cpp NFP CPP handle
- * @param target NFP CPP target ID
- * @param address Offset into the address space of the NFP CPP target ID
- * @param key_id Unique 32-bit value for this mutex
- *
- * @return 0 on success, negative value on failure.
- */
int nfp_cpp_mutex_init(struct nfp_cpp *cpp, int target,
uint64_t address, uint32_t key_id);
-/*
- * Create a mutex handle from an address controlled by a MU Atomic engine
- *
- * The CPP target:address must point to a 64-bit aligned location, and reserve
- * 64 bits of data at the location for use by the handle.
- *
- * Only target/address pairs that point to entities that support the MU Atomic
- * Engine's CmpAndSwap32 command are supported.
- *
- * @param cpp NFP CPP handle
- * @param target NFP CPP target ID
- * @param address Offset into the address space of the NFP CPP target ID
- * @param key_id 32-bit unique key (must match the key at this location)
- *
- * @return A non-NULL struct nfp_cpp_mutex * on success, NULL on
- * failure.
- */
struct nfp_cpp_mutex *nfp_cpp_mutex_alloc(struct nfp_cpp *cpp, int target,
uint64_t address, uint32_t key_id);
-/*
- * Free a mutex handle - does not alter the lock state
- *
- * @param mutex NFP CPP Mutex handle
- */
void nfp_cpp_mutex_free(struct nfp_cpp_mutex *mutex);
-/*
- * Lock a mutex handle, using the NFP MU Atomic Engine
- *
- * @param mutex NFP CPP Mutex handle
- *
- * @return 0 on success, negative value on failure.
- */
int nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex);
-/*
- * Unlock a mutex handle, using the NFP MU Atomic Engine
- *
- * @param mutex NFP CPP Mutex handle
- *
- * @return 0 on success, negative value on failure.
- */
int nfp_cpp_mutex_unlock(struct nfp_cpp_mutex *mutex);
-/*
- * Attempt to lock a mutex handle, using the NFP MU Atomic Engine
- *
- * @param mutex NFP CPP Mutex handle
- * @return 0 if the lock succeeded, negative value on failure.
- */
int nfp_cpp_mutex_trylock(struct nfp_cpp_mutex *mutex);
uint32_t nfp_cpp_mu_locality_lsb(struct nfp_cpp *cpp);
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
index bdf4a658f5..7e94bfb611 100644
--- a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
+++ b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
@@ -58,7 +58,7 @@
* Minimal size of the PCIe cfg memory we depend on being mapped,
* queue controller and DMA controller don't have to be covered.
*/
-#define NFP_PCI_MIN_MAP_SIZE 0x080000
+#define NFP_PCI_MIN_MAP_SIZE 0x080000 /* 512K */
#define NFP_PCIE_P2C_FIXED_SIZE(bar) (1 << (bar)->bitsize)
#define NFP_PCIE_P2C_BULK_SIZE(bar) (1 << (bar)->bitsize)
@@ -72,40 +72,25 @@
#define NFP_PCIE_CPP_BAR_PCIETOCPPEXPBAR(bar, slot) \
(((bar) * 8 + (slot)) * 4)
-/*
- * Define to enable a bit more verbose debug output.
- * Set to 1 to enable a bit more verbose debug output.
- */
struct nfp_pcie_user;
struct nfp6000_area_priv;
-/*
- * struct nfp_bar - describes BAR configuration and usage
- * @nfp: backlink to owner
- * @barcfg: cached contents of BAR config CSR
- * @base: the BAR's base CPP offset
- * @mask: mask for the BAR aperture (read only)
- * @bitsize: bitsize of BAR aperture (read only)
- * @index: index of the BAR
- * @lock: lock to specify if bar is in use
- * @refcnt: number of current users
- * @iomem: mapped IO memory
- */
+/* Describes BAR configuration and usage */
#define NFP_BAR_MIN 1
#define NFP_BAR_MID 5
#define NFP_BAR_MAX 7
struct nfp_bar {
- struct nfp_pcie_user *nfp;
- uint32_t barcfg;
- uint64_t base; /* CPP address base */
- uint64_t mask; /* Bit mask of the bar */
- uint32_t bitsize; /* Bit size of the bar */
- uint32_t index;
- int lock;
+ struct nfp_pcie_user *nfp; /**< Backlink to owner */
+ uint32_t barcfg; /**< BAR config CSR */
+ uint64_t base; /**< Base CPP offset */
+ uint64_t mask; /**< Mask of the BAR aperture (read only) */
+ uint32_t bitsize; /**< Bit size of the BAR aperture (read only) */
+ uint32_t index; /**< Index of the BAR */
+ int lock; /**< If the BAR has been locked */
char *csr;
- char *iomem;
+ char *iomem; /**< mapped IO memory */
};
#define BUSDEV_SZ 13
@@ -360,9 +345,7 @@ nfp_disable_bars(struct nfp_pcie_user *nfp)
}
}
-/*
- * Generic CPP bus access interface.
- */
+/* Generic CPP bus access interface. */
struct nfp6000_area_priv {
struct nfp_bar *bar;
diff --git a/drivers/net/nfp/nfpcore/nfp_cppcore.c b/drivers/net/nfp/nfpcore/nfp_cppcore.c
index e2af888a28..0e8372576e 100644
--- a/drivers/net/nfp/nfpcore/nfp_cppcore.c
+++ b/drivers/net/nfp/nfpcore/nfp_cppcore.c
@@ -26,6 +26,15 @@
#define NFP_PL_DEVICE_MODEL_MASK (NFP_PL_DEVICE_PART_MASK | \
NFP_PL_DEVICE_ID_MASK)
+/**
+ * Set the private data of the nfp_cpp instance
+ *
+ * @param cpp
+ * NFP CPP operations structure
+ *
+ * @return
+ * Opaque device pointer
+ */
void
nfp_cpp_priv_set(struct nfp_cpp *cpp,
void *priv)
@@ -33,12 +42,29 @@ nfp_cpp_priv_set(struct nfp_cpp *cpp,
cpp->priv = priv;
}
+/**
+ * Return the private data of the nfp_cpp instance
+ *
+ * @param cpp
+ * NFP CPP operations structure
+ *
+ * @return
+ * Opaque device pointer
+ */
void *
nfp_cpp_priv(struct nfp_cpp *cpp)
{
return cpp->priv;
}
+/**
+ * Set the model id
+ *
+ * @param cpp
+ * NFP CPP operations structure
+ * @param model
+ * Model ID
+ */
void
nfp_cpp_model_set(struct nfp_cpp *cpp,
uint32_t model)
@@ -46,6 +72,15 @@ nfp_cpp_model_set(struct nfp_cpp *cpp,
cpp->model = model;
}
+/**
+ * Retrieve the Model ID of the NFP
+ *
+ * @param cpp
+ * NFP CPP handle
+ *
+ * @return
+ * NFP CPP Model ID
+ */
uint32_t
nfp_cpp_model(struct nfp_cpp *cpp)
{
@@ -63,6 +98,14 @@ nfp_cpp_model(struct nfp_cpp *cpp)
return model;
}
+/**
+ * Set the private instance owned data of a nfp_cpp struct
+ *
+ * @param cpp
+ * NFP CPP operations structure
+ * @param interface
+ * Interface ID
+ */
void
nfp_cpp_interface_set(struct nfp_cpp *cpp,
uint32_t interface)
@@ -70,6 +113,17 @@ nfp_cpp_interface_set(struct nfp_cpp *cpp,
cpp->interface = interface;
}
+/**
+ * Retrieve the Serial ID of the NFP
+ *
+ * @param cpp
+ * NFP CPP handle
+ * @param serial
+ * Pointer to NFP serial number
+ *
+ * @return
+ * Length of NFP serial number
+ */
int
nfp_cpp_serial(struct nfp_cpp *cpp,
const uint8_t **serial)
@@ -78,6 +132,16 @@ nfp_cpp_serial(struct nfp_cpp *cpp,
return cpp->serial_len;
}
+/**
+ * Set the private instance owned data of a nfp_cpp struct
+ *
+ * @param cpp
+ * NFP CPP operations structure
+ * @param serial
+ * NFP serial byte array
+ * @param serial_len
+ * Length of the serial byte array
+ */
int
nfp_cpp_serial_set(struct nfp_cpp *cpp,
const uint8_t *serial,
@@ -96,6 +160,15 @@ nfp_cpp_serial_set(struct nfp_cpp *cpp,
return 0;
}
+/**
+ * Retrieve the Interface ID of the NFP
+ *
+ * @param cpp
+ * NFP CPP handle
+ *
+ * @return
+ * NFP CPP Interface ID
+ */
uint16_t
nfp_cpp_interface(struct nfp_cpp *cpp)
{
@@ -105,18 +178,45 @@ nfp_cpp_interface(struct nfp_cpp *cpp)
return cpp->interface;
}
+/**
+ * Get the privately allocated portion of a NFP CPP area handle
+ *
+ * @param cpp_area
+ * NFP CPP area handle
+ *
+ * @return
+ * Pointer to the private area, or NULL on failure
+ */
void *
nfp_cpp_area_priv(struct nfp_cpp_area *cpp_area)
{
return &cpp_area[1];
}
+/**
+ * Get the NFP CPP handle that is the pci_dev of a NFP CPP area handle
+ *
+ * @param cpp_area
+ * NFP CPP area handle
+ *
+ * @return
+ * NFP CPP handle
+ */
struct nfp_cpp *
nfp_cpp_area_cpp(struct nfp_cpp_area *cpp_area)
{
return cpp_area->cpp;
}
+/**
+ * Get the name passed during allocation of the NFP CPP area handle
+ *
+ * @param cpp_area
+ * NFP CPP area handle
+ *
+ * @return
+ * Pointer to the area's name
+ */
const char *
nfp_cpp_area_name(struct nfp_cpp_area *cpp_area)
{
@@ -153,15 +253,24 @@ nfp_cpp_mu_locality_lsb(struct nfp_cpp *cpp)
return cpp->mu_locality_lsb;
}
-/*
- * nfp_cpp_area_alloc - allocate a new CPP area
- * @cpp: CPP handle
- * @dest: CPP id
- * @address: start address on CPP target
- * @size: size of area in bytes
+/**
+ * Allocate and initialize a CPP area structure.
+ * The area must later be locked down with an 'acquire' before
+ * it can be safely accessed.
*
- * Allocate and initialize a CPP area structure. The area must later
- * be locked down with an 'acquire' before it can be safely accessed.
+ * @param cpp
+ * CPP device handle
+ * @param dest
+ * CPP id
+ * @param name
+ * Name of region
+ * @param address
+ * Address of region
+ * @param size
+ * Size of region
+ *
+ * @return
+ * NFP CPP area handle, or NULL
*
* NOTE: @address and @size must be 32-bit aligned values.
*/
@@ -211,6 +320,25 @@ nfp_cpp_area_alloc_with_name(struct nfp_cpp *cpp,
return area;
}
+/**
+ * Allocate and initialize a CPP area structure.
+ * The area must later be locked down with an 'acquire' before
+ * it can be safely accessed.
+ *
+ * @param cpp
+ * CPP device handle
+ * @param dest
+ * CPP id
+ * @param address
+ * Address of region
+ * @param size
+ * Size of region
+ *
+ * @return
+ * NFP CPP area handle, or NULL
+ *
+ * NOTE: @address and @size must be 32-bit aligned values.
+ */
struct nfp_cpp_area *
nfp_cpp_area_alloc(struct nfp_cpp *cpp,
uint32_t dest,
@@ -220,17 +348,22 @@ nfp_cpp_area_alloc(struct nfp_cpp *cpp,
return nfp_cpp_area_alloc_with_name(cpp, dest, NULL, address, size);
}
-/*
- * nfp_cpp_area_alloc_acquire - allocate a new CPP area and lock it down
- *
- * @cpp: CPP handle
- * @dest: CPP id
- * @address: start address on CPP target
- * @size: size of area
- *
+/**
* Allocate and initialize a CPP area structure, and lock it down so
* that it can be accessed directly.
*
+ * @param cpp
+ * CPP device handle
+ * @param destination
+ * CPP id
+ * @param address
+ * Address of region
+ * @param size
+ * Size of region
+ *
+ * @return
+ * NFP CPP area handle, or NULL
+ *
* NOTE: @address and @size must be 32-bit aligned values.
*
* NOTE: The area must also be 'released' when the structure is freed.
@@ -258,11 +391,11 @@ nfp_cpp_area_alloc_acquire(struct nfp_cpp *cpp,
return area;
}
-/*
- * nfp_cpp_area_free - free up the CPP area
- * area: CPP area handle
- *
+/**
* Frees up memory resources held by the CPP area.
+ *
+ * @param area
+ * CPP area handle
*/
void
nfp_cpp_area_free(struct nfp_cpp_area *area)
@@ -272,11 +405,11 @@ nfp_cpp_area_free(struct nfp_cpp_area *area)
free(area);
}
-/*
- * nfp_cpp_area_release_free - release CPP area and free it
- * area: CPP area handle
+/**
+ * Releases CPP area and frees up memory resources held by it.
*
- * Releases CPP area and frees up memory resources held by the it.
+ * @param area
+ * CPP area handle
*/
void
nfp_cpp_area_release_free(struct nfp_cpp_area *area)
@@ -285,12 +418,15 @@ nfp_cpp_area_release_free(struct nfp_cpp_area *area)
nfp_cpp_area_free(area);
}
-/*
- * nfp_cpp_area_acquire - lock down a CPP area for access
- * @area: CPP area handle
+/**
+ * Locks down the CPP area for a potential long term activity.
+ * Area must always be locked down before being accessed.
*
- * Locks down the CPP area for a potential long term activity. Area
- * must always be locked down before being accessed.
+ * @param area
+ * CPP area handle
+ *
+ * @return
+ * 0 on success, -1 on failure.
*/
int
nfp_cpp_area_acquire(struct nfp_cpp_area *area)
@@ -307,11 +443,11 @@ nfp_cpp_area_acquire(struct nfp_cpp_area *area)
return 0;
}
-/*
- * nfp_cpp_area_release - release a locked down CPP area
- * @area: CPP area handle
- *
+/**
* Releases a previously locked down CPP area.
+ *
+ * @param area
+ * CPP area handle
*/
void
nfp_cpp_area_release(struct nfp_cpp_area *area)
@@ -320,16 +456,16 @@ nfp_cpp_area_release(struct nfp_cpp_area *area)
area->cpp->op->area_release(area);
}
-/*
- * nfp_cpp_area_iomem() - get IOMEM region for CPP area
+/**
+ * Returns an iomem pointer for use with readl()/writel() style operations.
*
- * @area: CPP area handle
+ * @param area
+ * CPP area handle
*
- * Returns an iomem pointer for use with readl()/writel() style operations.
+ * @return
+ * Pointer to the area, or NULL
*
* NOTE: Area must have been locked down with an 'acquire'.
- *
- * Return: pointer to the area, or NULL
*/
void *
nfp_cpp_area_iomem(struct nfp_cpp_area *area)
@@ -342,18 +478,22 @@ nfp_cpp_area_iomem(struct nfp_cpp_area *area)
return iomem;
}
-/*
- * nfp_cpp_area_read - read data from CPP area
+/**
+ * Read data from indicated CPP region.
*
- * @area: CPP area handle
- * @offset: offset into CPP area
- * @kernel_vaddr: kernel address to put data into
- * @length: number of bytes to read
+ * @param area
+ * CPP area handle
+ * @param offset
+ * Offset into CPP area
+ * @param kernel_vaddr
+ * Address to put data into
+ * @param length
+ * Number of bytes to read
*
- * Read data from indicated CPP region.
+ * @return
+ * Length of io, or -ERRNO
*
* NOTE: @offset and @length must be 32-bit aligned values.
- *
* NOTE: Area must have been locked down with an 'acquire'.
*/
int
@@ -368,18 +508,22 @@ nfp_cpp_area_read(struct nfp_cpp_area *area,
return area->cpp->op->area_read(area, kernel_vaddr, offset, length);
}
-/*
- * nfp_cpp_area_write - write data to CPP area
+/**
+ * Write data to indicated CPP region.
*
- * @area: CPP area handle
- * @offset: offset into CPP area
- * @kernel_vaddr: kernel address to read data from
- * @length: number of bytes to write
+ * @param area
+ * CPP area handle
+ * @param offset
+ * Offset into CPP area
+ * @param kernel_vaddr
+ * Address to put data into
+ * @param length
+ * Number of bytes to read
*
- * Write data to indicated CPP region.
+ * @return
+ * Length of io, or -ERRNO
*
* NOTE: @offset and @length must be 32-bit aligned values.
- *
* NOTE: Area must have been locked down with an 'acquire'.
*/
int
@@ -436,6 +580,19 @@ nfp_xpb_to_cpp(struct nfp_cpp *cpp,
return xpb;
}
+/**
+ * Read a uint32_t value from an area
+ *
+ * @param area
+ * CPP Area handle
+ * @param offset
+ * Offset into area
+ * @param value
+ * Pointer to read buffer
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_area_readl(struct nfp_cpp_area *area,
uint32_t offset,
@@ -450,6 +607,19 @@ nfp_cpp_area_readl(struct nfp_cpp_area *area,
return (sz == sizeof(*value)) ? 0 : -1;
}
+/**
+ * Write a uint32_t vale to an area
+ *
+ * @param area
+ * CPP Area handle
+ * @param offset
+ * Offset into area
+ * @param value
+ * Value to write
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_area_writel(struct nfp_cpp_area *area,
uint32_t offset,
@@ -462,6 +632,19 @@ nfp_cpp_area_writel(struct nfp_cpp_area *area,
return (sz == sizeof(value)) ? 0 : -1;
}
+/**
+ * Read a uint64_t value from an area
+ *
+ * @param area
+ * CPP Area handle
+ * @param offset
+ * Offset into area
+ * @param value
+ * Pointer to read buffer
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_area_readq(struct nfp_cpp_area *area,
uint32_t offset,
@@ -476,6 +659,19 @@ nfp_cpp_area_readq(struct nfp_cpp_area *area,
return (sz == sizeof(*value)) ? 0 : -1;
}
+/**
+ * Write a uint64_t vale to an area
+ *
+ * @param area
+ * CPP Area handle
+ * @param offset
+ * Offset into area
+ * @param value
+ * Value to write
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_area_writeq(struct nfp_cpp_area *area,
uint32_t offset,
@@ -489,6 +685,21 @@ nfp_cpp_area_writeq(struct nfp_cpp_area *area,
return (sz == sizeof(value)) ? 0 : -1;
}
+/**
+ * Read a uint32_t value from a CPP location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param cpp_id
+ * CPP ID for operation
+ * @param address
+ * Address for operation
+ * @param value
+ * Pointer to read buffer
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_readl(struct nfp_cpp *cpp,
uint32_t cpp_id,
@@ -504,6 +715,21 @@ nfp_cpp_readl(struct nfp_cpp *cpp,
return (sz == sizeof(*value)) ? 0 : -1;
}
+/**
+ * Write a uint32_t value to a CPP location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param cpp_id
+ * CPP ID for operation
+ * @param address
+ * Address for operation
+ * @param value
+ * Value to write
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_writel(struct nfp_cpp *cpp,
uint32_t cpp_id,
@@ -518,6 +744,21 @@ nfp_cpp_writel(struct nfp_cpp *cpp,
return (sz == sizeof(value)) ? 0 : -1;
}
+/**
+ * Read a uint64_t value from a CPP location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param cpp_id
+ * CPP ID for operation
+ * @param address
+ * Address for operation
+ * @param value
+ * Pointer to read buffer
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_readq(struct nfp_cpp *cpp,
uint32_t cpp_id,
@@ -533,6 +774,21 @@ nfp_cpp_readq(struct nfp_cpp *cpp,
return (sz == sizeof(*value)) ? 0 : -1;
}
+/**
+ * Write a uint64_t value to a CPP location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param cpp_id
+ * CPP ID for operation
+ * @param address
+ * Address for operation
+ * @param value
+ * Value to write
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_cpp_writeq(struct nfp_cpp *cpp,
uint32_t cpp_id,
@@ -547,6 +803,19 @@ nfp_cpp_writeq(struct nfp_cpp *cpp,
return (sz == sizeof(value)) ? 0 : -1;
}
+/**
+ * Write a uint32_t word to a XPB location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param xpb_addr
+ * XPB target and address
+ * @param value
+ * Value to write
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_xpb_writel(struct nfp_cpp *cpp,
uint32_t xpb_addr,
@@ -559,6 +828,19 @@ nfp_xpb_writel(struct nfp_cpp *cpp,
return nfp_cpp_writel(cpp, cpp_dest, xpb_addr, value);
}
+/**
+ * Read a uint32_t value from a XPB location
+ *
+ * @param cpp
+ * CPP device handle
+ * @param xpb_addr
+ * XPB target and address
+ * @param value
+ * Pointer to read buffer
+ *
+ * @return
+ * 0 on success, or -ERRNO
+ */
int
nfp_xpb_readl(struct nfp_cpp *cpp,
uint32_t xpb_addr,
@@ -625,9 +907,11 @@ nfp_cpp_alloc(struct rte_pci_device *dev,
return cpp;
}
-/*
- * nfp_cpp_free - free the CPP handle
- * @cpp: CPP handle
+/**
+ * Free the CPP handle
+ *
+ * @param cpp
+ * CPP handle
*/
void
nfp_cpp_free(struct nfp_cpp *cpp)
@@ -641,6 +925,19 @@ nfp_cpp_free(struct nfp_cpp *cpp)
free(cpp);
}
+/**
+ * Create a NFP CPP handle from device
+ *
+ * @param dev
+ * PCI device
+ * @param driver_lock_needed
+ * Driver lock flag
+ *
+ * @return
+ * NFP CPP handle on success, NULL on failure
+ *
+ * NOTE: On failure, cpp_ops->free will be called!
+ */
struct nfp_cpp *
nfp_cpp_from_device_name(struct rte_pci_device *dev,
int driver_lock_needed)
@@ -648,13 +945,22 @@ nfp_cpp_from_device_name(struct rte_pci_device *dev,
return nfp_cpp_alloc(dev, driver_lock_needed);
}
-/*
- * nfp_cpp_read - read from CPP target
- * @cpp: CPP handle
- * @destination: CPP id
- * @address: offset into CPP target
- * @kernel_vaddr: kernel buffer for result
- * @length: number of bytes to read
+/**
+ * Read from CPP target
+ *
+ * @param cpp
+ * CPP handle
+ * @param destination
+ * CPP id
+ * @param address
+ * Offset into CPP target
+ * @param kernel_vaddr
+ * Buffer for result
+ * @param length
+ * Number of bytes to read
+ *
+ * @return
+ * Length of io, or -ERRNO
*/
int
nfp_cpp_read(struct nfp_cpp *cpp,
@@ -678,13 +984,22 @@ nfp_cpp_read(struct nfp_cpp *cpp,
return err;
}
-/*
- * nfp_cpp_write - write to CPP target
- * @cpp: CPP handle
- * @destination: CPP id
- * @address: offset into CPP target
- * @kernel_vaddr: kernel buffer to read from
- * @length: number of bytes to write
+/**
+ * Write to CPP target
+ *
+ * @param cpp
+ * CPP handle
+ * @param destination
+ * CPP id
+ * @param address
+ * Offset into CPP target
+ * @param kernel_vaddr
+ * Buffer to read from
+ * @param length
+ * Number of bytes to write
+ *
+ * @return
+ * Length of io, or -ERRNO
*/
int
nfp_cpp_write(struct nfp_cpp *cpp,
@@ -731,18 +1046,23 @@ __nfp_cpp_model_autodetect(struct nfp_cpp *cpp,
return 0;
}
-/*
- * nfp_cpp_map_area() - Helper function to map an area
- * @cpp: NFP CPP handler
- * @cpp_id: CPP ID
- * @addr: CPP address
- * @size: Size of the area
- * @area: Area handle (output)
+/**
+ * Map an area of IOMEM access.
+ * To undo the effect of this function call @nfp_cpp_area_release_free(*area).
*
- * Map an area of IOMEM access. To undo the effect of this function call
- * @nfp_cpp_area_release_free(*area).
+ * @param cpp
+ * NFP CPP handler
+ * @param cpp_id
+ * CPP id
+ * @param addr
+ * CPP address
+ * @param size
+ * Size of the area
+ * @param area
+ * Area handle (output)
*
- * Return: Pointer to memory mapped area or NULL
+ * @return
+ * Pointer to memory mapped area or NULL
*/
uint8_t *
nfp_cpp_map_area(struct nfp_cpp *cpp,
diff --git a/drivers/net/nfp/nfpcore/nfp_hwinfo.c b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
index b658b5e900..f5579ab60f 100644
--- a/drivers/net/nfp/nfpcore/nfp_hwinfo.c
+++ b/drivers/net/nfp/nfpcore/nfp_hwinfo.c
@@ -3,7 +3,8 @@
* All rights reserved.
*/
-/* Parse the hwinfo table that the ARM firmware builds in the ARM scratch SRAM
+/*
+ * Parse the hwinfo table that the ARM firmware builds in the ARM scratch SRAM
* after chip reset.
*
* Examples of the fields:
@@ -146,7 +147,7 @@ nfp_hwinfo_fetch(struct nfp_cpp *cpp,
struct nfp_hwinfo *db;
wait.tv_sec = 0;
- wait.tv_nsec = 10000000;
+ wait.tv_nsec = 10000000; /* 10ms */
for (;;) {
db = nfp_hwinfo_try_fetch(cpp, hwdb_size);
@@ -154,7 +155,7 @@ nfp_hwinfo_fetch(struct nfp_cpp *cpp,
return db;
nanosleep(&wait, NULL);
- if (count++ > 200) {
+ if (count++ > 200) { /* 10ms * 200 = 2s */
PMD_DRV_LOG(ERR, "NFP access error");
return NULL;
}
@@ -180,12 +181,16 @@ nfp_hwinfo_read(struct nfp_cpp *cpp)
return db;
}
-/*
- * nfp_hwinfo_lookup() - Find a value in the HWInfo table by name
- * @hwinfo: NFP HWinfo table
- * @lookup: HWInfo name to search for
+/**
+ * Find a value in the HWInfo table by name
+ *
+ * @param hwinfo
+ * NFP HWInfo table
+ * @param lookup
+ * HWInfo name to search for
*
- * Return: Value of the HWInfo name, or NULL
+ * @return
+ * Value of the HWInfo name, or NULL
*/
const char *
nfp_hwinfo_lookup(struct nfp_hwinfo *hwinfo,
diff --git a/drivers/net/nfp/nfpcore/nfp_hwinfo.h b/drivers/net/nfp/nfpcore/nfp_hwinfo.h
index a3da7512db..424db8035d 100644
--- a/drivers/net/nfp/nfpcore/nfp_hwinfo.h
+++ b/drivers/net/nfp/nfpcore/nfp_hwinfo.h
@@ -59,6 +59,8 @@
* Packed UTF8Z strings, ie 'key1\000value1\000key2\000value2\000'
*
* Unsorted.
+ *
+ * Note: Only the HwInfo v2 Table be supported now.
*/
#define NFP_HWINFO_VERSION_1 ('H' << 24 | 'I' << 16 | 1 << 8 | 0 << 1 | 0)
diff --git a/drivers/net/nfp/nfpcore/nfp_mip.c b/drivers/net/nfp/nfpcore/nfp_mip.c
index 086e82db70..0892c99e96 100644
--- a/drivers/net/nfp/nfpcore/nfp_mip.c
+++ b/drivers/net/nfp/nfpcore/nfp_mip.c
@@ -87,15 +87,16 @@ nfp_mip_read_resource(struct nfp_cpp *cpp,
return err;
}
-/*
- * nfp_mip_open() - Get device MIP structure
- * @cpp: NFP CPP Handle
- *
- * Copy MIP structure from NFP device and return it. The returned
+/**
+ * Copy MIP structure from NFP device and return it. The returned
* structure is handled internally by the library and should be
- * freed by calling nfp_mip_close().
+ * freed by calling @nfp_mip_close().
+ *
+ * @param cpp
+ * NFP CPP Handle
*
- * Return: pointer to mip, NULL on failure.
+ * @return
+ * Pointer to MIP, NULL on failure.
*/
struct nfp_mip *
nfp_mip_open(struct nfp_cpp *cpp)
@@ -131,11 +132,15 @@ nfp_mip_name(const struct nfp_mip *mip)
return mip->name;
}
-/*
- * nfp_mip_symtab() - Get the address and size of the MIP symbol table
- * @mip: MIP handle
- * @addr: Location for NFP DDR address of MIP symbol table
- * @size: Location for size of MIP symbol table
+/**
+ * Get the address and size of the MIP symbol table.
+ *
+ * @param mip
+ * MIP handle
+ * @param addr
+ * Location for NFP DDR address of MIP symbol table
+ * @param size
+ * Location for size of MIP symbol table
*/
void
nfp_mip_symtab(const struct nfp_mip *mip,
@@ -146,11 +151,15 @@ nfp_mip_symtab(const struct nfp_mip *mip,
*size = rte_le_to_cpu_32(mip->symtab_size);
}
-/*
- * nfp_mip_strtab() - Get the address and size of the MIP symbol name table
- * @mip: MIP handle
- * @addr: Location for NFP DDR address of MIP symbol name table
- * @size: Location for size of MIP symbol name table
+/**
+ * Get the address and size of the MIP symbol name table.
+ *
+ * @param mip
+ * MIP handle
+ * @param addr
+ * Location for NFP DDR address of MIP symbol name table
+ * @param size
+ * Location for size of MIP symbol name table
*/
void
nfp_mip_strtab(const struct nfp_mip *mip,
diff --git a/drivers/net/nfp/nfpcore/nfp_mutex.c b/drivers/net/nfp/nfpcore/nfp_mutex.c
index 82919d8270..404d4fa938 100644
--- a/drivers/net/nfp/nfpcore/nfp_mutex.c
+++ b/drivers/net/nfp/nfpcore/nfp_mutex.c
@@ -53,7 +53,7 @@ _nfp_cpp_mutex_validate(uint32_t model,
return 0;
}
-/*
+/**
* Initialize a mutex location
*
* The CPP target:address must point to a 64-bit aligned location, and
@@ -65,13 +65,17 @@ _nfp_cpp_mutex_validate(uint32_t model,
* This function should only be called when setting up
* the initial lock state upon boot-up of the system.
*
- * @param mutex NFP CPP Mutex handle
- * @param target NFP CPP target ID (ie NFP_CPP_TARGET_CLS or
- * NFP_CPP_TARGET_MU)
- * @param address Offset into the address space of the NFP CPP target ID
- * @param key Unique 32-bit value for this mutex
+ * @param cpp
+ * NFP CPP handle
+ * @param target
+ * NFP CPP target ID (ie NFP_CPP_TARGET_CLS or NFP_CPP_TARGET_MU)
+ * @param address
+ * Offset into the address space of the NFP CPP target ID
+ * @param key
+ * Unique 32-bit value for this mutex
*
- * @return 0 on success, or negative value on failure.
+ * @return
+ * 0 on success, or negative value on failure
*/
int
nfp_cpp_mutex_init(struct nfp_cpp *cpp,
@@ -99,7 +103,7 @@ nfp_cpp_mutex_init(struct nfp_cpp *cpp,
return 0;
}
-/*
+/**
* Create a mutex handle from an address controlled by a MU Atomic engine
*
* The CPP target:address must point to a 64-bit aligned location, and
@@ -108,13 +112,17 @@ nfp_cpp_mutex_init(struct nfp_cpp *cpp,
* Only target/address pairs that point to entities that support the
* MU Atomic Engine are supported.
*
- * @param cpp NFP CPP handle
- * @param target NFP CPP target ID (ie NFP_CPP_TARGET_CLS or
- * NFP_CPP_TARGET_MU)
- * @param address Offset into the address space of the NFP CPP target ID
- * @param key 32-bit unique key (must match the key at this location)
+ * @param cpp
+ * NFP CPP handle
+ * @param target
+ * NFP CPP target ID (ie NFP_CPP_TARGET_CLS or NFP_CPP_TARGET_MU)
+ * @param address
+ * Offset into the address space of the NFP CPP target ID
+ * @param key
+ * 32-bit unique key (must match the key at this location)
*
- * @return A non-NULL struct nfp_cpp_mutex * on success, NULL on failure.
+ * @return
+ * A non-NULL struct nfp_cpp_mutex * on success, NULL on failure.
*/
struct nfp_cpp_mutex *
nfp_cpp_mutex_alloc(struct nfp_cpp *cpp,
@@ -178,10 +186,11 @@ nfp_cpp_mutex_alloc(struct nfp_cpp *cpp,
return mutex;
}
-/*
+/**
* Free a mutex handle - does not alter the lock state
*
- * @param mutex NFP CPP Mutex handle
+ * @param mutex
+ * NFP CPP Mutex handle
*/
void
nfp_cpp_mutex_free(struct nfp_cpp_mutex *mutex)
@@ -203,12 +212,14 @@ nfp_cpp_mutex_free(struct nfp_cpp_mutex *mutex)
free(mutex);
}
-/*
+/**
* Lock a mutex handle, using the NFP MU Atomic Engine
*
- * @param mutex NFP CPP Mutex handle
+ * @param mutex
+ * NFP CPP Mutex handle
*
- * @return 0 on success, or negative value on failure.
+ * @return
+ * 0 on success, or negative value on failure.
*/
int
nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
@@ -229,12 +240,14 @@ nfp_cpp_mutex_lock(struct nfp_cpp_mutex *mutex)
return 0;
}
-/*
+/**
* Unlock a mutex handle, using the NFP MU Atomic Engine
*
- * @param mutex NFP CPP Mutex handle
+ * @param mutex
+ * NFP CPP Mutex handle
*
- * @return 0 on success, or negative value on failure.
+ * @return
+ * 0 on success, or negative value on failure
*/
int
nfp_cpp_mutex_unlock(struct nfp_cpp_mutex *mutex)
@@ -280,16 +293,18 @@ nfp_cpp_mutex_unlock(struct nfp_cpp_mutex *mutex)
return err;
}
-/*
+/**
* Attempt to lock a mutex handle, using the NFP MU Atomic Engine
*
* Valid lock states:
- *
* 0x....0000 - Unlocked
* 0x....000f - Locked
*
- * @param mutex NFP CPP Mutex handle
- * @return 0 if the lock succeeded, negative value on failure.
+ * @param mutex
+ * NFP CPP Mutex handle
+ *
+ * @return
+ * 0 if the lock succeeded, negative value on failure.
*/
int
nfp_cpp_mutex_trylock(struct nfp_cpp_mutex *mutex)
@@ -352,7 +367,7 @@ nfp_cpp_mutex_trylock(struct nfp_cpp_mutex *mutex)
* If there was another contending for this lock, then
* the lock state would be 0x....000f
*
- * Write our owner ID into the lock
+ * Write our owner ID into the lock.
* While not strictly necessary, this helps with
* debug and bookkeeping.
*/
diff --git a/drivers/net/nfp/nfpcore/nfp_nffw.c b/drivers/net/nfp/nfpcore/nfp_nffw.c
index b5a354137d..5f004e3b21 100644
--- a/drivers/net/nfp/nfpcore/nfp_nffw.c
+++ b/drivers/net/nfp/nfpcore/nfp_nffw.c
@@ -52,7 +52,7 @@ nffw_fwinfo_mip_mu_da_get(const struct nffw_fwinfo *fi)
return (fi->loaded__mu_da__mip_off_hi >> 8) & 1;
}
-/* mip_offset = (loaded__mu_da__mip_off_hi<7:0> << 8) | mip_offset_lo */
+/* mip_offset = (loaded__mu_da__mip_off_hi<7:0> << 32) | mip_offset_lo */
static uint64_t
nffw_fwinfo_mip_offset_get(const struct nffw_fwinfo *fi)
{
@@ -112,11 +112,14 @@ nffw_res_fwinfos(struct nfp_nffw_info_data *fwinf,
}
}
-/*
- * nfp_nffw_info_open() - Acquire the lock on the NFFW table
- * @cpp: NFP CPP handle
+/**
+ * Acquire the lock on the NFFW table
+ *
+ * @param cpp
+ * NFP CPP handle
*
- * Return: nffw info pointer, or NULL on failure
+ * @return
+ * NFFW info pointer, or NULL on failure
*/
struct nfp_nffw_info *
nfp_nffw_info_open(struct nfp_cpp *cpp)
@@ -168,11 +171,11 @@ nfp_nffw_info_open(struct nfp_cpp *cpp)
return NULL;
}
-/*
- * nfp_nffw_info_close() - Release the lock on the NFFW table
- * @state: NFP FW info state
+/**
+ * Release the lock on the NFFW table
*
- * Return: void
+ * @param state
+ * NFFW info pointer
*/
void
nfp_nffw_info_close(struct nfp_nffw_info *state)
@@ -181,11 +184,14 @@ nfp_nffw_info_close(struct nfp_nffw_info *state)
free(state);
}
-/*
- * nfp_nffw_info_fwid_first() - Return the first firmware ID in the NFFW
- * @state: NFP FW info state
+/**
+ * Return the first firmware ID in the NFFW
*
- * Return: First NFFW firmware info, NULL on failure
+ * @param state
+ * NFFW info pointer
+ *
+ * @return:
+ * First NFFW firmware info, NULL on failure
*/
static struct nffw_fwinfo *
nfp_nffw_info_fwid_first(struct nfp_nffw_info *state)
@@ -205,13 +211,18 @@ nfp_nffw_info_fwid_first(struct nfp_nffw_info *state)
return NULL;
}
-/*
- * nfp_nffw_info_mip_first() - Retrieve the location of the first FW's MIP
- * @state: NFP FW info state
- * @cpp_id: Pointer to the CPP ID of the MIP
- * @off: Pointer to the CPP Address of the MIP
+/**
+ * Retrieve the location of the first FW's MIP
+ *
+ * @param state
+ * NFFW info pointer
+ * @param cpp_id
+ * Pointer to the CPP ID of the MIP
+ * @param off
+ * Pointer to the CPP Address of the MIP
*
- * Return: 0, or -ERRNO
+ * @return
+ * 0, or -ERRNO
*/
int
nfp_nffw_info_mip_first(struct nfp_nffw_info *state,
diff --git a/drivers/net/nfp/nfpcore/nfp_nffw.h b/drivers/net/nfp/nfpcore/nfp_nffw.h
index 46ac8a8d07..e032b6cce7 100644
--- a/drivers/net/nfp/nfpcore/nfp_nffw.h
+++ b/drivers/net/nfp/nfpcore/nfp_nffw.h
@@ -8,7 +8,8 @@
#include "nfp_cpp.h"
-/* Init-CSR owner IDs for firmware map to firmware IDs which start at 4.
+/*
+ * Init-CSR owner IDs for firmware map to firmware IDs which start at 4.
* Lower IDs are reserved for target and loader IDs.
*/
#define NFFW_FWID_EXT 3 /* For active MEs that we didn't load. */
@@ -16,7 +17,7 @@
#define NFFW_FWID_ALL 255
-/**
+/*
* NFFW_INFO_VERSION history:
* 0: This was never actually used (before versioning), but it refers to
* the previous struct which had FWINFO_CNT = MEINFO_CNT = 120 that later
@@ -35,6 +36,7 @@
#define NFFW_MEINFO_CNT_V2 200
#define NFFW_FWINFO_CNT_V2 200
+/* nfp.nffw meinfo */
struct nffw_meinfo {
uint32_t ctxmask__fwid__meid;
};
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.c b/drivers/net/nfp/nfpcore/nfp_nsp.c
index ff19446173..a96ccea38b 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.c
@@ -109,9 +109,11 @@ nfp_nsp_check(struct nfp_nsp *state)
return 0;
}
-/*
- * nfp_nsp_open() - Prepare for communication and lock the NSP resource.
- * @cpp: NFP CPP Handle
+/**
+ * Prepare for communication and lock the NSP resource.
+ *
+ * @param cpp
+ * NFP CPP Handle
*/
struct nfp_nsp *
nfp_nsp_open(struct nfp_cpp *cpp)
@@ -145,9 +147,11 @@ nfp_nsp_open(struct nfp_cpp *cpp)
return state;
}
-/*
- * nfp_nsp_close() - Clean up and unlock the NSP resource.
- * @state: NFP SP state
+/**
+ * Clean up and unlock the NSP resource.
+ *
+ * @param state
+ * NFP SP state
*/
void
nfp_nsp_close(struct nfp_nsp *state)
@@ -181,7 +185,7 @@ nfp_nsp_wait_reg(struct nfp_cpp *cpp,
struct timespec wait;
wait.tv_sec = 0;
- wait.tv_nsec = 25000000;
+ wait.tv_nsec = 25000000; /* 25ms */
for (;;) {
err = nfp_cpp_readq(cpp, nsp_cpp, addr, reg);
@@ -194,28 +198,27 @@ nfp_nsp_wait_reg(struct nfp_cpp *cpp,
return 0;
nanosleep(&wait, 0);
- if (count++ > 1000)
+ if (count++ > 1000) /* 25ms * 1000 = 25s */
return -ETIMEDOUT;
}
}
-/*
- * nfp_nsp_command() - Execute a command on the NFP Service Processor
- * @state: NFP SP state
- * @code: NFP SP Command Code
- * @option: NFP SP Command Argument
- * @buff_cpp: NFP SP Buffer CPP Address info
- * @buff_addr: NFP SP Buffer Host address
- *
- * Return: 0 for success with no result
+/**
+ * Execute a command on the NFP Service Processor
*
- * positive value for NSP completion with a result code
+ * @param state
+ * NFP SP state
+ * @param arg
+ * NFP command argument structure
*
- * -EAGAIN if the NSP is not yet present
- * -ENODEV if the NSP is not a supported model
- * -EBUSY if the NSP is stuck
- * -EINTR if interrupted while waiting for completion
- * -ETIMEDOUT if the NSP took longer than 30 seconds to complete
+ * @return
+ * - 0 for success with no result
+ * - Positive value for NSP completion with a result code
+ * - -EAGAIN if the NSP is not yet present
+ * - -ENODEV if the NSP is not a supported model
+ * - -EBUSY if the NSP is stuck
+ * - -EINTR if interrupted while waiting for completion
+ * - -ETIMEDOUT if the NSP took longer than @timeout_sec seconds to complete
*/
static int
nfp_nsp_command(struct nfp_nsp *state,
@@ -383,7 +386,7 @@ nfp_nsp_wait(struct nfp_nsp *state)
struct timespec wait;
wait.tv_sec = 0;
- wait.tv_nsec = 25000000;
+ wait.tv_nsec = 25000000; /* 25ms */
for (;;) {
err = nfp_nsp_command(state, SPCODE_NOOP, 0, 0, 0);
@@ -392,7 +395,7 @@ nfp_nsp_wait(struct nfp_nsp *state)
nanosleep(&wait, 0);
- if (count++ > 1000) {
+ if (count++ > 1000) { /* 25ms * 1000 = 25s */
err = -ETIMEDOUT;
break;
}
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.h b/drivers/net/nfp/nfpcore/nfp_nsp.h
index edb56e26ca..0fcb21e99c 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.h
@@ -158,72 +158,45 @@ enum nfp_eth_fec {
#define NFP_FEC_REED_SOLOMON RTE_BIT32(NFP_FEC_REED_SOLOMON_BIT)
#define NFP_FEC_DISABLED RTE_BIT32(NFP_FEC_DISABLED_BIT)
-/**
- * struct nfp_eth_table - ETH table information
- * @count: number of table entries
- * @max_index: max of @index fields of all @ports
- * @ports: table of ports
- *
- * @eth_index: port index according to legacy ethX numbering
- * @index: chip-wide first channel index
- * @nbi: NBI index
- * @base: first channel index (within NBI)
- * @lanes: number of channels
- * @speed: interface speed (in Mbps)
- * @interface: interface (module) plugged in
- * @media: media type of the @interface
- * @fec: forward error correction mode
- * @aneg: auto negotiation mode
- * @mac_addr: interface MAC address
- * @label_port: port id
- * @label_subport: id of interface within port (for split ports)
- * @enabled: is enabled?
- * @tx_enabled: is TX enabled?
- * @rx_enabled: is RX enabled?
- * @override_changed: is media reconfig pending?
- *
- * @port_type: one of %PORT_* defines for ethtool
- * @port_lanes: total number of lanes on the port (sum of lanes of all subports)
- * @is_split: is interface part of a split port
- * @fec_modes_supported: bitmap of FEC modes supported
- */
+/* ETH table information */
struct nfp_eth_table {
- uint32_t count;
- uint32_t max_index;
+ uint32_t count; /**< Number of table entries */
+ uint32_t max_index; /**< Max of @index fields of all @ports */
struct nfp_eth_table_port {
+ /** Port index according to legacy ethX numbering */
uint32_t eth_index;
- uint32_t index;
- uint32_t nbi;
- uint32_t base;
- uint32_t lanes;
- uint32_t speed;
+ uint32_t index; /**< Chip-wide first channel index */
+ uint32_t nbi; /**< NBI index */
+ uint32_t base; /**< First channel index (within NBI) */
+ uint32_t lanes; /**< Number of channels */
+ uint32_t speed; /**< Interface speed (in Mbps) */
- uint32_t interface;
- enum nfp_eth_media media;
+ uint32_t interface; /**< Interface (module) plugged in */
+ enum nfp_eth_media media; /**< Media type of the @interface */
- enum nfp_eth_fec fec;
- enum nfp_eth_aneg aneg;
+ enum nfp_eth_fec fec; /**< Forward Error Correction mode */
+ enum nfp_eth_aneg aneg; /**< Auto negotiation mode */
- struct rte_ether_addr mac_addr;
+ struct rte_ether_addr mac_addr; /**< Interface MAC address */
- uint8_t label_port;
+ uint8_t label_port; /**< Port id */
+ /** Id of interface within port (for split ports) */
uint8_t label_subport;
- int enabled;
- int tx_enabled;
- int rx_enabled;
-
- int override_changed;
+ int enabled; /**< Enable port */
+ int tx_enabled; /**< Enable TX */
+ int rx_enabled; /**< Enable RX */
- /* Computed fields */
- uint8_t port_type;
+ int override_changed; /**< Media reconfig pending */
+ uint8_t port_type; /**< One of %PORT_* */
+ /** Sum of lanes of all subports of this port */
uint32_t port_lanes;
- int is_split;
+ int is_split; /**< Split port */
- uint32_t fec_modes_supported;
- } ports[];
+ uint32_t fec_modes_supported; /**< Bitmap of FEC modes supported */
+ } ports[]; /**< Table of ports */
};
struct nfp_eth_table *nfp_eth_read_ports(struct nfp_cpp *cpp);
@@ -263,28 +236,17 @@ int __nfp_eth_set_aneg(struct nfp_nsp *nsp, enum nfp_eth_aneg mode);
int __nfp_eth_set_speed(struct nfp_nsp *nsp, uint32_t speed);
int __nfp_eth_set_split(struct nfp_nsp *nsp, uint32_t lanes);
-/**
- * struct nfp_nsp_identify - NSP static information
- * @version: opaque version string
- * @flags: version flags
- * @br_primary: branch id of primary bootloader
- * @br_secondary: branch id of secondary bootloader
- * @br_nsp: branch id of NSP
- * @primary: version of primary bootloader
- * @secondary: version id of secondary bootloader
- * @nsp: version id of NSP
- * @sensor_mask: mask of present sensors available on NIC
- */
+/* NSP static information */
struct nfp_nsp_identify {
- char version[40];
- uint8_t flags;
- uint8_t br_primary;
- uint8_t br_secondary;
- uint8_t br_nsp;
- uint16_t primary;
- uint16_t secondary;
- uint16_t nsp;
- uint64_t sensor_mask;
+ char version[40]; /**< Opaque version string */
+ uint8_t flags; /**< Version flags */
+ uint8_t br_primary; /**< Branch id of primary bootloader */
+ uint8_t br_secondary; /**< Branch id of secondary bootloader */
+ uint8_t br_nsp; /**< Branch id of NSP */
+ uint16_t primary; /**< Version of primary bootloader */
+ uint16_t secondary; /**< Version id of secondary bootloader */
+ uint16_t nsp; /**< Version id of NSP */
+ uint64_t sensor_mask; /**< Mask of present sensors available on NIC */
};
struct nfp_nsp_identify *__nfp_nsp_identify(struct nfp_nsp *nsp);
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
index 74daa92aed..cb090d2a47 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
@@ -264,7 +264,8 @@ __nfp_eth_read_ports(struct nfp_nsp *nsp)
goto err;
}
- /* The NFP3800 NIC support 8 ports, but only 2 ports are valid,
+ /*
+ * The NFP3800 NIC support 8 ports, but only 2 ports are valid,
* the rest 6 ports mac are all 0, ensure we don't use these port
*/
for (i = 0; i < NSP_ETH_MAX_COUNT; i++) {
@@ -274,7 +275,8 @@ __nfp_eth_read_ports(struct nfp_nsp *nsp)
cnt++;
}
- /* Some versions of flash will give us 0 instead of port count. For
+ /*
+ * Some versions of flash will give us 0 instead of port count. For
* those that give a port count, verify it against the value calculated
* above.
*/
@@ -312,14 +314,16 @@ __nfp_eth_read_ports(struct nfp_nsp *nsp)
return NULL;
}
-/*
- * nfp_eth_read_ports() - retrieve port information
- * @cpp: NFP CPP handle
+/**
+ * Read the port information from the device.
+ *
+ * Returned structure should be freed once no longer needed.
*
- * Read the port information from the device. Returned structure should
- * be freed with kfree() once no longer needed.
+ * @param cpp
+ * NFP CPP handle
*
- * Return: populated ETH table or NULL on error.
+ * @return
+ * Populated ETH table or NULL on error.
*/
struct nfp_eth_table *
nfp_eth_read_ports(struct nfp_cpp *cpp)
@@ -387,19 +391,19 @@ nfp_eth_config_cleanup_end(struct nfp_nsp *nsp)
free(entries);
}
-/*
- * nfp_eth_config_commit_end() - perform recorded configuration changes
- * @nsp: NFP NSP handle returned from nfp_eth_config_start()
- *
+/**
* Perform the configuration which was requested with __nfp_eth_set_*()
- * helpers and recorded in @nsp state. If device was already configured
- * as requested or no __nfp_eth_set_*() operations were made no NSP command
+ * helpers and recorded in @nsp state. If device was already configured
+ * as requested or no __nfp_eth_set_*() operations were made, no NSP command
* will be performed.
*
- * Return:
- * 0 - configuration successful;
- * 1 - no changes were needed;
- * -ERRNO - configuration failed.
+ * @param nsp
+ * NFP NSP handle returned from nfp_eth_config_start()
+ *
+ * @return
+ * - (0) Configuration successful
+ * - (1) No changes were needed
+ * - (-ERRNO) Configuration failed
*/
int
nfp_eth_config_commit_end(struct nfp_nsp *nsp)
@@ -417,19 +421,21 @@ nfp_eth_config_commit_end(struct nfp_nsp *nsp)
return ret;
}
-/*
- * nfp_eth_set_mod_enable() - set PHY module enable control bit
- * @cpp: NFP CPP handle
- * @idx: NFP chip-wide port index
- * @enable: Desired state
- *
+/**
* Enable or disable PHY module (this usually means setting the TX lanes
* disable bits).
*
- * Return:
- * 0 - configuration successful;
- * 1 - no changes were needed;
- * -ERRNO - configuration failed.
+ * @param cpp
+ * NFP CPP handle
+ * @param idx
+ * NFP chip-wide port index
+ * @param enable
+ * Desired state
+ *
+ * @return
+ * - (0) Configuration successful
+ * - (1) No changes were needed
+ * - (-ERRNO) Configuration failed
*/
int
nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
@@ -460,18 +466,20 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
return nfp_eth_config_commit_end(nsp);
}
-/*
- * nfp_eth_set_configured() - set PHY module configured control bit
- * @cpp: NFP CPP handle
- * @idx: NFP chip-wide port index
- * @configed: Desired state
- *
+/**
* Set the ifup/ifdown state on the PHY.
*
- * Return:
- * 0 - configuration successful;
- * 1 - no changes were needed;
- * -ERRNO - configuration failed.
+ * @param cpp
+ * NFP CPP handle
+ * @param idx
+ * NFP chip-wide port index
+ * @param configured
+ * Desired state
+ *
+ * @return
+ * - (0) Configuration successful
+ * - (1) No changes were needed
+ * - (-ERRNO) Configuration failed
*/
int
nfp_eth_set_configured(struct nfp_cpp *cpp,
@@ -525,7 +533,7 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp,
/*
* Note: set features were added in ABI 0.14 but the error
- * codes were initially not populated correctly.
+ * codes were initially not populated correctly.
*/
if (nfp_nsp_get_abi_ver_minor(nsp) < 17) {
PMD_DRV_LOG(ERR, "set operations not supported, please update flash");
@@ -555,15 +563,17 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp,
val, ctrl_bit); \
}))
-/*
- * __nfp_eth_set_aneg() - set PHY autonegotiation control bit
- * @nsp: NFP NSP handle returned from nfp_eth_config_start()
- * @mode: Desired autonegotiation mode
- *
+/**
* Allow/disallow PHY module to advertise/perform autonegotiation.
* Will write to hwinfo overrides in the flash (persistent config).
*
- * Return: 0 or -ERRNO.
+ * @param nsp
+ * NFP NSP handle returned from nfp_eth_config_start()
+ * @param mode
+ * Desired autonegotiation mode
+ *
+ * @return
+ * 0 or -ERRNO
*/
int
__nfp_eth_set_aneg(struct nfp_nsp *nsp,
@@ -573,15 +583,17 @@ __nfp_eth_set_aneg(struct nfp_nsp *nsp,
NSP_ETH_STATE_ANEG, mode, NSP_ETH_CTRL_SET_ANEG);
}
-/*
- * __nfp_eth_set_fec() - set PHY forward error correction control bit
- * @nsp: NFP NSP handle returned from nfp_eth_config_start()
- * @mode: Desired fec mode
- *
+/**
* Set the PHY module forward error correction mode.
* Will write to hwinfo overrides in the flash (persistent config).
*
- * Return: 0 or -ERRNO.
+ * @param nsp
+ * NFP NSP handle returned from nfp_eth_config_start()
+ * @param mode
+ * Desired fec mode
+ *
+ * @return
+ * 0 or -ERRNO
*/
static int
__nfp_eth_set_fec(struct nfp_nsp *nsp,
@@ -591,16 +603,20 @@ __nfp_eth_set_fec(struct nfp_nsp *nsp,
NSP_ETH_STATE_FEC, mode, NSP_ETH_CTRL_SET_FEC);
}
-/*
- * nfp_eth_set_fec() - set PHY forward error correction control mode
- * @cpp: NFP CPP handle
- * @idx: NFP chip-wide port index
- * @mode: Desired fec mode
+/**
+ * Set PHY forward error correction control mode
+ *
+ * @param cpp
+ * NFP CPP handle
+ * @param idx
+ * NFP chip-wide port index
+ * @param mode
+ * Desired fec mode
*
- * Return:
- * 0 - configuration successful;
- * 1 - no changes were needed;
- * -ERRNO - configuration failed.
+ * @return
+ * - (0) Configuration successful
+ * - (1) No changes were needed
+ * - (-ERRNO) Configuration failed
*/
int
nfp_eth_set_fec(struct nfp_cpp *cpp,
@@ -623,17 +639,19 @@ nfp_eth_set_fec(struct nfp_cpp *cpp,
return nfp_eth_config_commit_end(nsp);
}
-/*
- * __nfp_eth_set_speed() - set interface speed/rate
- * @nsp: NFP NSP handle returned from nfp_eth_config_start()
- * @speed: Desired speed (per lane)
- *
- * Set lane speed. Provided @speed value should be subport speed divided
- * by number of lanes this subport is spanning (i.e. 10000 for 40G, 25000 for
- * 50G, etc.)
+/**
+ * Set lane speed.
+ * Provided @speed value should be subport speed divided by number of
+ * lanes this subport is spanning (i.e. 10000 for 40G, 25000 for 50G, etc.)
* Will write to hwinfo overrides in the flash (persistent config).
*
- * Return: 0 or -ERRNO.
+ * @param nsp
+ * NFP NSP handle returned from nfp_eth_config_start()
+ * @param speed
+ * Desired speed (per lane)
+ *
+ * @return
+ * 0 or -ERRNO
*/
int
__nfp_eth_set_speed(struct nfp_nsp *nsp,
@@ -651,15 +669,17 @@ __nfp_eth_set_speed(struct nfp_nsp *nsp,
NSP_ETH_STATE_RATE, rate, NSP_ETH_CTRL_SET_RATE);
}
-/*
- * __nfp_eth_set_split() - set interface lane split
- * @nsp: NFP NSP handle returned from nfp_eth_config_start()
- * @lanes: Desired lanes per port
- *
+/**
* Set number of lanes in the port.
* Will write to hwinfo overrides in the flash (persistent config).
*
- * Return: 0 or -ERRNO.
+ * @param nsp
+ * NFP NSP handle returned from nfp_eth_config_start()
+ * @param lanes
+ * Desired lanes per port
+ *
+ * @return
+ * 0 or -ERRNO
*/
int
__nfp_eth_set_split(struct nfp_nsp *nsp,
diff --git a/drivers/net/nfp/nfpcore/nfp_resource.c b/drivers/net/nfp/nfpcore/nfp_resource.c
index 363f7d6198..bdebf5c3aa 100644
--- a/drivers/net/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/nfp/nfpcore/nfp_resource.c
@@ -22,32 +22,23 @@
#define NFP_RESOURCE_ENTRY_NAME_SZ 8
-/*
- * struct nfp_resource_entry - Resource table entry
- * @owner: NFP CPP Lock, interface owner
- * @key: NFP CPP Lock, posix_crc32(name, 8)
- * @region: Memory region descriptor
- * @name: ASCII, zero padded name
- * @reserved
- * @cpp_action: CPP Action
- * @cpp_token: CPP Token
- * @cpp_target: CPP Target ID
- * @page_offset: 256-byte page offset into target's CPP address
- * @page_size: size, in 256-byte pages
- */
+/* Resource table entry */
struct nfp_resource_entry {
struct nfp_resource_entry_mutex {
- uint32_t owner;
- uint32_t key;
+ uint32_t owner; /**< NFP CPP Lock, interface owner */
+ uint32_t key; /**< NFP CPP Lock, posix_crc32(name, 8) */
} mutex;
+ /* Memory region descriptor */
struct nfp_resource_entry_region {
+ /** ASCII, zero padded name */
uint8_t name[NFP_RESOURCE_ENTRY_NAME_SZ];
uint8_t reserved[5];
- uint8_t cpp_action;
- uint8_t cpp_token;
- uint8_t cpp_target;
+ uint8_t cpp_action; /**< CPP Action */
+ uint8_t cpp_token; /**< CPP Token */
+ uint8_t cpp_target; /**< CPP Target ID */
+ /** 256-byte page offset into target's CPP address */
uint32_t page_offset;
- uint32_t page_size;
+ uint32_t page_size; /**< Size, in 256-byte pages */
} region;
};
@@ -147,14 +138,18 @@ nfp_resource_try_acquire(struct nfp_cpp *cpp,
return err;
}
-/*
- * nfp_resource_acquire() - Acquire a resource handle
- * @cpp: NFP CPP handle
- * @name: Name of the resource
+/**
+ * Acquire a resource handle
+ *
+ * Note: This function locks the acquired resource.
*
- * NOTE: This function locks the acquired resource
+ * @param cpp
+ * NFP CPP handle
+ * @param name
+ * Name of the resource
*
- * Return: NFP Resource handle, or NULL
+ * @return
+ * NFP Resource handle, or NULL
*/
struct nfp_resource *
nfp_resource_acquire(struct nfp_cpp *cpp,
@@ -183,7 +178,7 @@ nfp_resource_acquire(struct nfp_cpp *cpp,
}
wait.tv_sec = 0;
- wait.tv_nsec = 1000000;
+ wait.tv_nsec = 1000000; /* 1ms */
for (;;) {
err = nfp_resource_try_acquire(cpp, res, dev_mutex);
@@ -194,7 +189,7 @@ nfp_resource_acquire(struct nfp_cpp *cpp,
goto err_free;
}
- if (count++ > 1000) {
+ if (count++ > 1000) { /* 1ms * 1000 = 1s */
PMD_DRV_LOG(ERR, "Error: resource %s timed out", name);
err = -EBUSY;
goto err_free;
@@ -213,11 +208,13 @@ nfp_resource_acquire(struct nfp_cpp *cpp,
return NULL;
}
-/*
- * nfp_resource_release() - Release a NFP Resource handle
- * @res: NFP Resource handle
+/**
+ * Release a NFP Resource handle
*
- * NOTE: This function implicitly unlocks the resource handle
+ * NOTE: This function implicitly unlocks the resource handle.
+ *
+ * @param res
+ * NFP Resource handle
*/
void
nfp_resource_release(struct nfp_resource *res)
@@ -227,11 +224,14 @@ nfp_resource_release(struct nfp_resource *res)
free(res);
}
-/*
- * nfp_resource_cpp_id() - Return the cpp_id of a resource handle
- * @res: NFP Resource handle
+/**
+ * Return the cpp_id of a resource handle
+ *
+ * @param res
+ * NFP Resource handle
*
- * Return: NFP CPP ID
+ * @return
+ * NFP CPP ID
*/
uint32_t
nfp_resource_cpp_id(const struct nfp_resource *res)
@@ -239,11 +239,14 @@ nfp_resource_cpp_id(const struct nfp_resource *res)
return res->cpp_id;
}
-/*
- * nfp_resource_name() - Return the name of a resource handle
- * @res: NFP Resource handle
+/**
+ * Return the name of a resource handle
*
- * Return: const char pointer to the name of the resource
+ * @param res
+ * NFP Resource handle
+ *
+ * @return
+ * Const char pointer to the name of the resource
*/
const char *
nfp_resource_name(const struct nfp_resource *res)
@@ -251,11 +254,14 @@ nfp_resource_name(const struct nfp_resource *res)
return res->name;
}
-/*
- * nfp_resource_address() - Return the address of a resource handle
- * @res: NFP Resource handle
+/**
+ * Return the address of a resource handle
+ *
+ * @param res
+ * NFP Resource handle
*
- * Return: Address of the resource
+ * @return
+ * Address of the resource
*/
uint64_t
nfp_resource_address(const struct nfp_resource *res)
@@ -263,11 +269,14 @@ nfp_resource_address(const struct nfp_resource *res)
return res->addr;
}
-/*
- * nfp_resource_size() - Return the size in bytes of a resource handle
- * @res: NFP Resource handle
+/**
+ * Return the size in bytes of a resource handle
+ *
+ * @param res
+ * NFP Resource handle
*
- * Return: Size of the resource in bytes
+ * @return
+ * Size of the resource in bytes
*/
uint64_t
nfp_resource_size(const struct nfp_resource *res)
diff --git a/drivers/net/nfp/nfpcore/nfp_resource.h b/drivers/net/nfp/nfpcore/nfp_resource.h
index 009b7359a4..4236950caf 100644
--- a/drivers/net/nfp/nfpcore/nfp_resource.h
+++ b/drivers/net/nfp/nfpcore/nfp_resource.h
@@ -8,43 +8,27 @@
#include "nfp_cpp.h"
+/* Netronone Flow Firmware Table */
#define NFP_RESOURCE_NFP_NFFW "nfp.nffw"
+
+/* NFP Hardware Info Database */
#define NFP_RESOURCE_NFP_HWINFO "nfp.info"
+
+/* Service Processor */
#define NFP_RESOURCE_NSP "nfp.sp"
-/**
- * Opaque handle to a NFP Resource
- */
+/* Opaque handle to a NFP Resource */
struct nfp_resource;
struct nfp_resource *nfp_resource_acquire(struct nfp_cpp *cpp,
const char *name);
-/**
- * Release a NFP Resource, and free the handle
- * @param[in] res NFP Resource handle
- */
void nfp_resource_release(struct nfp_resource *res);
-/**
- * Return the CPP ID of a NFP Resource
- * @param[in] res NFP Resource handle
- * @return CPP ID of the NFP Resource
- */
uint32_t nfp_resource_cpp_id(const struct nfp_resource *res);
-/**
- * Return the name of a NFP Resource
- * @param[in] res NFP Resource handle
- * @return Name of the NFP Resource
- */
const char *nfp_resource_name(const struct nfp_resource *res);
-/**
- * Return the target address of a NFP Resource
- * @param[in] res NFP Resource handle
- * @return Address of the NFP Resource
- */
uint64_t nfp_resource_address(const struct nfp_resource *res);
uint64_t nfp_resource_size(const struct nfp_resource *res);
diff --git a/drivers/net/nfp/nfpcore/nfp_rtsym.c b/drivers/net/nfp/nfpcore/nfp_rtsym.c
index d15a920752..0e6c0f9fe1 100644
--- a/drivers/net/nfp/nfpcore/nfp_rtsym.c
+++ b/drivers/net/nfp/nfpcore/nfp_rtsym.c
@@ -162,11 +162,14 @@ __nfp_rtsym_table_read(struct nfp_cpp *cpp,
return NULL;
}
-/*
- * nfp_rtsym_count() - Get the number of RTSYM descriptors
- * @rtbl: NFP RTsym table
+/**
+ * Get the number of RTSYM descriptors
+ *
+ * @param rtbl
+ * NFP RTSYM table
*
- * Return: Number of RTSYM descriptors
+ * @return
+ * Number of RTSYM descriptors
*/
int
nfp_rtsym_count(struct nfp_rtsym_table *rtbl)
@@ -177,12 +180,16 @@ nfp_rtsym_count(struct nfp_rtsym_table *rtbl)
return rtbl->num;
}
-/*
- * nfp_rtsym_get() - Get the Nth RTSYM descriptor
- * @rtbl: NFP RTsym table
- * @idx: Index (0-based) of the RTSYM descriptor
+/**
+ * Get the Nth RTSYM descriptor
+ *
+ * @param rtbl
+ * NFP RTSYM table
+ * @param idx
+ * Index (0-based) of the RTSYM descriptor
*
- * Return: const pointer to a struct nfp_rtsym descriptor, or NULL
+ * @return
+ * Const pointer to a struct nfp_rtsym descriptor, or NULL
*/
const struct nfp_rtsym *
nfp_rtsym_get(struct nfp_rtsym_table *rtbl,
@@ -197,12 +204,16 @@ nfp_rtsym_get(struct nfp_rtsym_table *rtbl,
return &rtbl->symtab[idx];
}
-/*
- * nfp_rtsym_lookup() - Return the RTSYM descriptor for a symbol name
- * @rtbl: NFP RTsym table
- * @name: Symbol name
+/**
+ * Return the RTSYM descriptor for a symbol name
+ *
+ * @param rtbl
+ * NFP RTSYM table
+ * @param name
+ * Symbol name
*
- * Return: const pointer to a struct nfp_rtsym descriptor, or NULL
+ * @return
+ * Const pointer to a struct nfp_rtsym descriptor, or NULL
*/
const struct nfp_rtsym *
nfp_rtsym_lookup(struct nfp_rtsym_table *rtbl,
@@ -227,7 +238,8 @@ nfp_rtsym_size(const struct nfp_rtsym *sym)
case NFP_RTSYM_TYPE_NONE:
PMD_DRV_LOG(ERR, "The type of rtsym '%s' is NONE", sym->name);
return 0;
- case NFP_RTSYM_TYPE_OBJECT: /* Fall through */
+ case NFP_RTSYM_TYPE_OBJECT:
+ /* FALLTHROUGH */
case NFP_RTSYM_TYPE_FUNCTION:
return sym->size;
case NFP_RTSYM_TYPE_ABS:
@@ -327,17 +339,22 @@ nfp_rtsym_readq(struct nfp_cpp *cpp,
return nfp_cpp_readq(cpp, cpp_id, addr, value);
}
-/*
- * nfp_rtsym_read_le() - Read a simple unsigned scalar value from symbol
- * @rtbl: NFP RTsym table
- * @name: Symbol name
- * @error: Pointer to error code (optional)
+/**
+ * Read a simple unsigned scalar value from symbol
*
* Lookup a symbol, map, read it and return it's value. Value of the symbol
* will be interpreted as a simple little-endian unsigned value. Symbol can
* be 4 or 8 bytes in size.
*
- * Return: value read, on error sets the error and returns ~0ULL.
+ * @param rtbl
+ * NFP RTSYM table
+ * @param name
+ * Symbol name
+ * @param error
+ * Pointer to error code (optional)
+ *
+ * @return
+ * Value read, on error sets the error and returns ~0ULL.
*/
uint64_t
nfp_rtsym_read_le(struct nfp_rtsym_table *rtbl,
diff --git a/drivers/net/nfp/nfpcore/nfp_rtsym.h b/drivers/net/nfp/nfpcore/nfp_rtsym.h
index e7295258b3..ff1facbd17 100644
--- a/drivers/net/nfp/nfpcore/nfp_rtsym.h
+++ b/drivers/net/nfp/nfpcore/nfp_rtsym.h
@@ -31,12 +31,12 @@
* of "sram" symbols for backward compatibility, which are viewed as global.
*/
struct nfp_rtsym {
- const char *name;
- uint64_t addr;
- uint64_t size;
- int type;
- int target;
- int domain;
+ const char *name; /**< Symbol name */
+ uint64_t addr; /**< Address in the domain/target's address space */
+ uint64_t size; /**< Size (in bytes) of the symbol */
+ int type; /**< NFP_RTSYM_TYPE_* of the symbol */
+ int target; /**< CPP target identifier, or NFP_RTSYM_TARGET_* */
+ int domain; /**< CPP target domain */
};
struct nfp_rtsym_table;
diff --git a/drivers/net/nfp/nfpcore/nfp_target.c b/drivers/net/nfp/nfpcore/nfp_target.c
index 611848e233..540b242a43 100644
--- a/drivers/net/nfp/nfpcore/nfp_target.c
+++ b/drivers/net/nfp/nfpcore/nfp_target.c
@@ -767,7 +767,7 @@ nfp_encode_basic(uint64_t *addr,
/*
* Make sure we compare against isldN values by clearing the
* LSB. This is what the silicon does.
- **/
+ */
isld[0] &= ~1;
isld[1] &= ~1;
--
2.39.1
^ permalink raw reply [relevance 1%]
* [PATCH v5 18/26] net/nfp: refact the nsp module
` (2 preceding siblings ...)
2023-09-19 9:54 1% ` [PATCH v5 07/26] net/nfp: standard the comment style Chaoyong He
@ 2023-09-19 9:54 5% ` Chaoyong He
3 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-09-19 9:54 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Chaoyong He
Move the definition of data structure into the implement file.
Also sync the logic from kernel driver and remove the unneeded header
file include statements.
Signed-off-by: Chaoyong He <chaoyong.he@corigine.com>
---
drivers/net/nfp/nfp_ethdev.c | 2 +-
drivers/net/nfp/nfpcore/nfp_nsp.c | 390 +++++++++++++++++++------
drivers/net/nfp/nfpcore/nfp_nsp.h | 140 ++++-----
drivers/net/nfp/nfpcore/nfp_nsp_cmds.c | 4 -
drivers/net/nfp/nfpcore/nfp_nsp_eth.c | 79 ++---
5 files changed, 398 insertions(+), 217 deletions(-)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index e3ff3d8087..efb47c5d56 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -661,7 +661,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
static int
nfp_fw_upload(struct rte_pci_device *dev, struct nfp_nsp *nsp, char *card)
{
- struct nfp_cpp *cpp = nsp->cpp;
+ struct nfp_cpp *cpp = nfp_nsp_cpp(nsp);
void *fw_buf;
char fw_name[125];
char serial[40];
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.c b/drivers/net/nfp/nfpcore/nfp_nsp.c
index 0f67148907..5b804f6174 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.c
@@ -3,20 +3,127 @@
* All rights reserved.
*/
-#define NFP_SUBSYS "nfp_nsp"
-
-#include <stdio.h>
-#include <time.h>
+#include "nfp_nsp.h"
#include <rte_common.h>
-#include "nfp_cpp.h"
#include "nfp_logs.h"
-#include "nfp_nsp.h"
#include "nfp_platform.h"
#include "nfp_resource.h"
-int
+/* Offsets relative to the CSR base */
+#define NSP_STATUS 0x00
+#define NSP_STATUS_MAGIC GENMASK_ULL(63, 48)
+#define NSP_STATUS_MAJOR GENMASK_ULL(47, 44)
+#define NSP_STATUS_MINOR GENMASK_ULL(43, 32)
+#define NSP_STATUS_CODE GENMASK_ULL(31, 16)
+#define NSP_STATUS_RESULT GENMASK_ULL(15, 8)
+#define NSP_STATUS_BUSY RTE_BIT64(0)
+
+#define NSP_COMMAND 0x08
+#define NSP_COMMAND_OPTION GENMASK_ULL(63, 32)
+#define NSP_COMMAND_CODE GENMASK_ULL(31, 16)
+#define NSP_COMMAND_DMA_BUF RTE_BIT64(1)
+#define NSP_COMMAND_START RTE_BIT64(0)
+
+/* CPP address to retrieve the data from */
+#define NSP_BUFFER 0x10
+#define NSP_BUFFER_CPP GENMASK_ULL(63, 40)
+#define NSP_BUFFER_ADDRESS GENMASK_ULL(39, 0)
+
+#define NSP_DFLT_BUFFER 0x18
+#define NSP_DFLT_BUFFER_CPP GENMASK_ULL(63, 40)
+#define NSP_DFLT_BUFFER_ADDRESS GENMASK_ULL(39, 0)
+
+#define NSP_DFLT_BUFFER_CONFIG 0x20
+#define NSP_DFLT_BUFFER_SIZE_4KB GENMASK_ULL(15, 8)
+#define NSP_DFLT_BUFFER_SIZE_MB GENMASK_ULL(7, 0)
+
+#define NSP_MAGIC 0xab10
+#define NSP_MAJOR 0
+#define NSP_MINOR 8
+
+#define NSP_CODE_MAJOR GENMASK_ULL(15, 12)
+#define NSP_CODE_MINOR GENMASK_ULL(11, 0)
+
+#define NFP_FW_LOAD_RET_MAJOR GENMASK_ULL(15, 8)
+#define NFP_FW_LOAD_RET_MINOR GENMASK_ULL(23, 16)
+
+enum nfp_nsp_cmd {
+ SPCODE_NOOP = 0, /* No operation */
+ SPCODE_SOFT_RESET = 1, /* Soft reset the NFP */
+ SPCODE_FW_DEFAULT = 2, /* Load default (UNDI) FW */
+ SPCODE_PHY_INIT = 3, /* Initialize the PHY */
+ SPCODE_MAC_INIT = 4, /* Initialize the MAC */
+ SPCODE_PHY_RXADAPT = 5, /* Re-run PHY RX Adaptation */
+ SPCODE_FW_LOAD = 6, /* Load fw from buffer, len in option */
+ SPCODE_ETH_RESCAN = 7, /* Rescan ETHs, write ETH_TABLE to buf */
+ SPCODE_ETH_CONTROL = 8, /* Update media config from buffer */
+ SPCODE_NSP_WRITE_FLASH = 11, /* Load and flash image from buffer */
+ SPCODE_NSP_SENSORS = 12, /* Read NSP sensor(s) */
+ SPCODE_NSP_IDENTIFY = 13, /* Read NSP version */
+ SPCODE_FW_STORED = 16, /* If no FW loaded, load flash app FW */
+ SPCODE_HWINFO_LOOKUP = 17, /* Lookup HWinfo with overwrites etc. */
+ SPCODE_HWINFO_SET = 18, /* Set HWinfo entry */
+ SPCODE_FW_LOADED = 19, /* Is application firmware loaded */
+ SPCODE_VERSIONS = 21, /* Report FW versions */
+ SPCODE_READ_SFF_EEPROM = 22, /* Read module EEPROM */
+ SPCODE_READ_MEDIA = 23, /* Get the supported/advertised media for a port */
+};
+
+static const struct {
+ uint32_t code;
+ const char *msg;
+} nsp_errors[] = {
+ { 6010, "could not map to phy for port" },
+ { 6011, "not an allowed rate/lanes for port" },
+ { 6012, "not an allowed rate/lanes for port" },
+ { 6013, "high/low error, change other port first" },
+ { 6014, "config not found in flash" },
+};
+
+struct nfp_nsp {
+ struct nfp_cpp *cpp;
+ struct nfp_resource *res;
+ struct {
+ uint16_t major;
+ uint16_t minor;
+ } ver;
+
+ /** Eth table config state */
+ bool modified;
+ uint32_t idx;
+ void *entries;
+};
+
+/* NFP command argument structure */
+struct nfp_nsp_command_arg {
+ uint16_t code; /**< NFP SP Command Code */
+ bool dma; /**< @buf points to a host buffer, not NSP buffer */
+ bool error_quiet; /**< Don't print command error/warning */
+ uint32_t timeout_sec; /**< Timeout value to wait for completion in seconds */
+ uint32_t option; /**< NSP Command Argument */
+ uint64_t buf; /**< NSP Buffer Address */
+ /** Callback for interpreting option if error occurred */
+ void (*error_cb)(struct nfp_nsp *state, uint32_t ret_val);
+};
+
+/* NFP command with buffer argument structure */
+struct nfp_nsp_command_buf_arg {
+ struct nfp_nsp_command_arg arg; /**< NFP command argument structure */
+ const void *in_buf; /**< Buffer with data for input */
+ void *out_buf; /**< Buffer for output data */
+ uint32_t in_size; /**< Size of @in_buf */
+ uint32_t out_size; /**< Size of @out_buf */
+};
+
+struct nfp_cpp *
+nfp_nsp_cpp(struct nfp_nsp *state)
+{
+ return state->cpp;
+}
+
+bool
nfp_nsp_config_modified(struct nfp_nsp *state)
{
return state->modified;
@@ -24,7 +131,7 @@ nfp_nsp_config_modified(struct nfp_nsp *state)
void
nfp_nsp_config_set_modified(struct nfp_nsp *state,
- int modified)
+ bool modified)
{
state->modified = modified;
}
@@ -66,7 +173,7 @@ nfp_nsp_print_extended_error(uint32_t ret_val)
return;
for (i = 0; i < RTE_DIM(nsp_errors); i++)
- if (ret_val == (uint32_t)nsp_errors[i].code)
+ if (ret_val == nsp_errors[i].code)
PMD_DRV_LOG(ERR, "err msg: %s", nsp_errors[i].msg);
}
@@ -222,11 +329,8 @@ nfp_nsp_wait_reg(struct nfp_cpp *cpp,
* - -ETIMEDOUT if the NSP took longer than @timeout_sec seconds to complete
*/
static int
-nfp_nsp_command(struct nfp_nsp *state,
- uint16_t code,
- uint32_t option,
- uint32_t buff_cpp,
- uint64_t buff_addr)
+nfp_nsp_command_real(struct nfp_nsp *state,
+ const struct nfp_nsp_command_arg *arg)
{
int err;
uint64_t reg;
@@ -250,22 +354,14 @@ nfp_nsp_command(struct nfp_nsp *state,
return err;
}
- if (!FIELD_FIT(NSP_BUFFER_CPP, buff_cpp >> 8) ||
- !FIELD_FIT(NSP_BUFFER_ADDRESS, buff_addr)) {
- PMD_DRV_LOG(ERR, "Host buffer out of reach %08x %" PRIx64,
- buff_cpp, buff_addr);
- return -EINVAL;
- }
-
- err = nfp_cpp_writeq(cpp, nsp_cpp, nsp_buffer,
- FIELD_PREP(NSP_BUFFER_CPP, buff_cpp >> 8) |
- FIELD_PREP(NSP_BUFFER_ADDRESS, buff_addr));
+ err = nfp_cpp_writeq(cpp, nsp_cpp, nsp_buffer, arg->buf);
if (err < 0)
return err;
err = nfp_cpp_writeq(cpp, nsp_cpp, nsp_command,
- FIELD_PREP(NSP_COMMAND_OPTION, option) |
- FIELD_PREP(NSP_COMMAND_CODE, code) |
+ FIELD_PREP(NSP_COMMAND_OPTION, arg->option) |
+ FIELD_PREP(NSP_COMMAND_CODE, arg->code) |
+ FIELD_PREP(NSP_COMMAND_DMA_BUF, arg->dma) |
FIELD_PREP(NSP_COMMAND_START, 1));
if (err < 0)
return err;
@@ -275,7 +371,7 @@ nfp_nsp_command(struct nfp_nsp *state,
NSP_COMMAND_START, 0);
if (err != 0) {
PMD_DRV_LOG(ERR, "Error %d waiting for code %#04x to start",
- err, code);
+ err, arg->code);
return err;
}
@@ -284,7 +380,7 @@ nfp_nsp_command(struct nfp_nsp *state,
NSP_STATUS_BUSY, 0);
if (err != 0) {
PMD_DRV_LOG(ERR, "Error %d waiting for code %#04x to complete",
- err, code);
+ err, arg->code);
return err;
}
@@ -296,84 +392,85 @@ nfp_nsp_command(struct nfp_nsp *state,
err = FIELD_GET(NSP_STATUS_RESULT, reg);
if (err != 0) {
- PMD_DRV_LOG(ERR, "Result (error) code set: %d (%d) command: %d",
- -err, (int)ret_val, code);
- nfp_nsp_print_extended_error(ret_val);
+ if (!arg->error_quiet)
+ PMD_DRV_LOG(WARNING, "Result (error) code set: %d (%d) command: %d",
+ -err, (int)ret_val, arg->code);
+
+ if (arg->error_cb != 0)
+ arg->error_cb(state, ret_val);
+ else
+ nfp_nsp_print_extended_error(ret_val);
+
return -err;
}
return ret_val;
}
-#define SZ_1M 0x00100000
+static int
+nfp_nsp_command(struct nfp_nsp *state,
+ uint16_t code)
+{
+ const struct nfp_nsp_command_arg arg = {
+ .code = code,
+ };
+
+ return nfp_nsp_command_real(state, &arg);
+}
static int
-nfp_nsp_command_buf(struct nfp_nsp *nsp,
- uint16_t code, uint32_t option,
- const void *in_buf,
- unsigned int in_size,
- void *out_buf,
- unsigned int out_size)
+nfp_nsp_command_buf_def(struct nfp_nsp *nsp,
+ struct nfp_nsp_command_buf_arg *arg)
{
int err;
int ret;
uint64_t reg;
- size_t max_size;
uint32_t cpp_id;
uint64_t cpp_buf;
struct nfp_cpp *cpp = nsp->cpp;
- if (nsp->ver.minor < 13) {
- PMD_DRV_LOG(ERR, "NSP: Code 0x%04x with buffer not supported ABI %hu.%hu)",
- code, nsp->ver.major, nsp->ver.minor);
- return -EOPNOTSUPP;
- }
-
- err = nfp_cpp_readq(cpp, nfp_resource_cpp_id(nsp->res),
- nfp_resource_address(nsp->res) + NSP_DFLT_BUFFER_CONFIG,
- ®);
- if (err < 0)
- return err;
-
- max_size = RTE_MAX(in_size, out_size);
- if (FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M < max_size) {
- PMD_DRV_LOG(ERR, "NSP: default buffer too small for command 0x%04x (%llu < %zu)",
- code, FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M, max_size);
- return -EINVAL;
- }
-
err = nfp_cpp_readq(cpp, nfp_resource_cpp_id(nsp->res),
nfp_resource_address(nsp->res) + NSP_DFLT_BUFFER,
®);
if (err < 0)
return err;
- cpp_id = FIELD_GET(NSP_BUFFER_CPP, reg) << 8;
- cpp_buf = FIELD_GET(NSP_BUFFER_ADDRESS, reg);
+ cpp_id = FIELD_GET(NSP_DFLT_BUFFER_CPP, reg) << 8;
+ cpp_buf = FIELD_GET(NSP_DFLT_BUFFER_ADDRESS, reg);
- if (in_buf != NULL && in_size > 0) {
- err = nfp_cpp_write(cpp, cpp_id, cpp_buf, in_buf, in_size);
+ if (arg->in_buf != NULL && arg->in_size > 0) {
+ err = nfp_cpp_write(cpp, cpp_id, cpp_buf,
+ arg->in_buf, arg->in_size);
if (err < 0)
return err;
}
/* Zero out remaining part of the buffer */
- if (out_buf != NULL && out_size > 0 && out_size > in_size) {
- memset(out_buf, 0, out_size - in_size);
- err = nfp_cpp_write(cpp, cpp_id, cpp_buf + in_size, out_buf,
- out_size - in_size);
+ if (arg->out_buf != NULL && arg->out_size > arg->in_size) {
+ err = nfp_cpp_write(cpp, cpp_id, cpp_buf + arg->in_size,
+ arg->out_buf, arg->out_size - arg->in_size);
if (err < 0)
return err;
}
- ret = nfp_nsp_command(nsp, code, option, cpp_id, cpp_buf);
+ if (!FIELD_FIT(NSP_BUFFER_CPP, cpp_id >> 8) ||
+ !FIELD_FIT(NSP_BUFFER_ADDRESS, cpp_buf)) {
+ PMD_DRV_LOG(ERR, "Buffer out of reach %#08x %#016lx",
+ cpp_id, cpp_buf);
+ return -EINVAL;
+ }
+
+ arg->arg.buf = FIELD_PREP(NSP_BUFFER_CPP, cpp_id >> 8) |
+ FIELD_PREP(NSP_BUFFER_ADDRESS, cpp_buf);
+ ret = nfp_nsp_command_real(nsp, &arg->arg);
if (ret < 0) {
PMD_DRV_LOG(ERR, "NSP command failed");
return ret;
}
- if (out_buf != NULL && out_size > 0) {
- err = nfp_cpp_read(cpp, cpp_id, cpp_buf, out_buf, out_size);
+ if (arg->out_buf != NULL && arg->out_size > 0) {
+ err = nfp_cpp_read(cpp, cpp_id, cpp_buf,
+ arg->out_buf, arg->out_size);
if (err < 0)
return err;
}
@@ -381,6 +478,43 @@ nfp_nsp_command_buf(struct nfp_nsp *nsp,
return ret;
}
+#define SZ_1M 0x00100000
+#define SZ_4K 0x00001000
+
+static int
+nfp_nsp_command_buf(struct nfp_nsp *nsp,
+ struct nfp_nsp_command_buf_arg *arg)
+{
+ int err;
+ size_t size;
+ uint64_t reg;
+ size_t max_size;
+ struct nfp_cpp *cpp = nsp->cpp;
+
+ if (nsp->ver.minor < 13) {
+ PMD_DRV_LOG(ERR, "NSP: Code %#04x with buffer not supported ABI %hu.%hu)",
+ arg->arg.code, nsp->ver.major, nsp->ver.minor);
+ return -EOPNOTSUPP;
+ }
+
+ err = nfp_cpp_readq(cpp, nfp_resource_cpp_id(nsp->res),
+ nfp_resource_address(nsp->res) + NSP_DFLT_BUFFER_CONFIG,
+ ®);
+ if (err < 0)
+ return err;
+
+ max_size = RTE_MAX(arg->in_size, arg->out_size);
+ size = FIELD_GET(NSP_DFLT_BUFFER_SIZE_MB, reg) * SZ_1M +
+ FIELD_GET(NSP_DFLT_BUFFER_SIZE_4KB, reg) * SZ_4K;
+ if (size < max_size) {
+ PMD_DRV_LOG(ERR, "NSP: default buffer too small for command %#04x (%zu < %zu)",
+ arg->arg.code, size, max_size);
+ return -EINVAL;
+ }
+
+ return nfp_nsp_command_buf_def(nsp, arg);
+}
+
int
nfp_nsp_wait(struct nfp_nsp *state)
{
@@ -392,7 +526,7 @@ nfp_nsp_wait(struct nfp_nsp *state)
wait.tv_nsec = 25000000; /* 25ms */
for (;;) {
- err = nfp_nsp_command(state, SPCODE_NOOP, 0, 0, 0);
+ err = nfp_nsp_command(state, SPCODE_NOOP);
if (err != -EAGAIN)
break;
@@ -413,13 +547,57 @@ nfp_nsp_wait(struct nfp_nsp *state)
int
nfp_nsp_device_soft_reset(struct nfp_nsp *state)
{
- return nfp_nsp_command(state, SPCODE_SOFT_RESET, 0, 0, 0);
+ return nfp_nsp_command(state, SPCODE_SOFT_RESET);
}
int
nfp_nsp_mac_reinit(struct nfp_nsp *state)
{
- return nfp_nsp_command(state, SPCODE_MAC_INIT, 0, 0, 0);
+ return nfp_nsp_command(state, SPCODE_MAC_INIT);
+}
+
+static void
+nfp_nsp_load_fw_extended_msg(struct nfp_nsp *state,
+ uint32_t ret_val)
+{
+ uint32_t minor;
+ uint32_t major;
+ static const char * const major_msg[] = {
+ /* 0 */ "Firmware from driver loaded",
+ /* 1 */ "Firmware from flash loaded",
+ /* 2 */ "Firmware loading failure",
+ };
+ static const char * const minor_msg[] = {
+ /* 0 */ "",
+ /* 1 */ "no named partition on flash",
+ /* 2 */ "error reading from flash",
+ /* 3 */ "can not deflate",
+ /* 4 */ "not a trusted file",
+ /* 5 */ "can not parse FW file",
+ /* 6 */ "MIP not found in FW file",
+ /* 7 */ "null firmware name in MIP",
+ /* 8 */ "FW version none",
+ /* 9 */ "FW build number none",
+ /* 10 */ "no FW selection policy HWInfo key found",
+ /* 11 */ "static FW selection policy",
+ /* 12 */ "FW version has precedence",
+ /* 13 */ "different FW application load requested",
+ /* 14 */ "development build",
+ };
+
+ major = FIELD_GET(NFP_FW_LOAD_RET_MAJOR, ret_val);
+ minor = FIELD_GET(NFP_FW_LOAD_RET_MINOR, ret_val);
+
+ if (!nfp_nsp_has_stored_fw_load(state))
+ return;
+
+ if (major >= RTE_DIM(major_msg))
+ PMD_DRV_LOG(INFO, "FW loading status: %x", ret_val);
+ else if (minor >= RTE_DIM(minor_msg))
+ PMD_DRV_LOG(INFO, "%s, reason code: %d", major_msg[major], minor);
+ else
+ PMD_DRV_LOG(INFO, "%s%c %s", major_msg[major],
+ minor != 0 ? ',' : '.', minor_msg[minor]);
}
int
@@ -427,8 +605,24 @@ nfp_nsp_load_fw(struct nfp_nsp *state,
void *buf,
size_t size)
{
- return nfp_nsp_command_buf(state, SPCODE_FW_LOAD, size, buf, size,
- NULL, 0);
+ int ret;
+ struct nfp_nsp_command_buf_arg load_fw = {
+ {
+ .code = SPCODE_FW_LOAD,
+ .option = size,
+ .error_cb = nfp_nsp_load_fw_extended_msg,
+ },
+ .in_buf = buf,
+ .in_size = size,
+ };
+
+ ret = nfp_nsp_command_buf(state, &load_fw);
+ if (ret < 0)
+ return ret;
+
+ nfp_nsp_load_fw_extended_msg(state, ret);
+
+ return 0;
}
int
@@ -436,8 +630,16 @@ nfp_nsp_read_eth_table(struct nfp_nsp *state,
void *buf,
size_t size)
{
- return nfp_nsp_command_buf(state, SPCODE_ETH_RESCAN, size, NULL, 0,
- buf, size);
+ struct nfp_nsp_command_buf_arg eth_rescan = {
+ {
+ .code = SPCODE_ETH_RESCAN,
+ .option = size,
+ },
+ .out_buf = buf,
+ .out_size = size,
+ };
+
+ return nfp_nsp_command_buf(state, ð_rescan);
}
int
@@ -445,8 +647,16 @@ nfp_nsp_write_eth_table(struct nfp_nsp *state,
const void *buf,
size_t size)
{
- return nfp_nsp_command_buf(state, SPCODE_ETH_CONTROL, size, buf, size,
- NULL, 0);
+ struct nfp_nsp_command_buf_arg eth_ctrl = {
+ {
+ .code = SPCODE_ETH_CONTROL,
+ .option = size,
+ },
+ .in_buf = buf,
+ .in_size = size,
+ };
+
+ return nfp_nsp_command_buf(state, ð_ctrl);
}
int
@@ -454,8 +664,16 @@ nfp_nsp_read_identify(struct nfp_nsp *state,
void *buf,
size_t size)
{
- return nfp_nsp_command_buf(state, SPCODE_NSP_IDENTIFY, size, NULL, 0,
- buf, size);
+ struct nfp_nsp_command_buf_arg identify = {
+ {
+ .code = SPCODE_NSP_IDENTIFY,
+ .option = size,
+ },
+ .out_buf = buf,
+ .out_size = size,
+ };
+
+ return nfp_nsp_command_buf(state, &identify);
}
int
@@ -464,6 +682,14 @@ nfp_nsp_read_sensors(struct nfp_nsp *state,
void *buf,
size_t size)
{
- return nfp_nsp_command_buf(state, SPCODE_NSP_SENSORS, sensor_mask, NULL,
- 0, buf, size);
+ struct nfp_nsp_command_buf_arg sensors = {
+ {
+ .code = SPCODE_NSP_SENSORS,
+ .option = sensor_mask,
+ },
+ .out_buf = buf,
+ .out_size = size,
+ };
+
+ return nfp_nsp_command_buf(state, &sensors);
}
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.h b/drivers/net/nfp/nfpcore/nfp_nsp.h
index 14986a9130..fe52dffeb7 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.h
@@ -7,78 +7,8 @@
#define __NSP_NSP_H__
#include "nfp_cpp.h"
-#include "nfp_nsp.h"
-
-/* Offsets relative to the CSR base */
-#define NSP_STATUS 0x00
-#define NSP_STATUS_MAGIC GENMASK_ULL(63, 48)
-#define NSP_STATUS_MAJOR GENMASK_ULL(47, 44)
-#define NSP_STATUS_MINOR GENMASK_ULL(43, 32)
-#define NSP_STATUS_CODE GENMASK_ULL(31, 16)
-#define NSP_STATUS_RESULT GENMASK_ULL(15, 8)
-#define NSP_STATUS_BUSY RTE_BIT64(0)
-
-#define NSP_COMMAND 0x08
-#define NSP_COMMAND_OPTION GENMASK_ULL(63, 32)
-#define NSP_COMMAND_CODE GENMASK_ULL(31, 16)
-#define NSP_COMMAND_START RTE_BIT64(0)
-
-/* CPP address to retrieve the data from */
-#define NSP_BUFFER 0x10
-#define NSP_BUFFER_CPP GENMASK_ULL(63, 40)
-#define NSP_BUFFER_PCIE GENMASK_ULL(39, 38)
-#define NSP_BUFFER_ADDRESS GENMASK_ULL(37, 0)
-
-#define NSP_DFLT_BUFFER 0x18
-
-#define NSP_DFLT_BUFFER_CONFIG 0x20
-#define NSP_DFLT_BUFFER_SIZE_MB GENMASK_ULL(7, 0)
-
-#define NSP_MAGIC 0xab10
-#define NSP_MAJOR 0
-#define NSP_MINOR 8
-
-#define NSP_CODE_MAJOR GENMASK(15, 12)
-#define NSP_CODE_MINOR GENMASK(11, 0)
-
-enum nfp_nsp_cmd {
- SPCODE_NOOP = 0, /* No operation */
- SPCODE_SOFT_RESET = 1, /* Soft reset the NFP */
- SPCODE_FW_DEFAULT = 2, /* Load default (UNDI) FW */
- SPCODE_PHY_INIT = 3, /* Initialize the PHY */
- SPCODE_MAC_INIT = 4, /* Initialize the MAC */
- SPCODE_PHY_RXADAPT = 5, /* Re-run PHY RX Adaptation */
- SPCODE_FW_LOAD = 6, /* Load fw from buffer, len in option */
- SPCODE_ETH_RESCAN = 7, /* Rescan ETHs, write ETH_TABLE to buf */
- SPCODE_ETH_CONTROL = 8, /* Update media config from buffer */
- SPCODE_NSP_SENSORS = 12, /* Read NSP sensor(s) */
- SPCODE_NSP_IDENTIFY = 13, /* Read NSP version */
-};
-
-static const struct {
- int code;
- const char *msg;
-} nsp_errors[] = {
- { 6010, "could not map to phy for port" },
- { 6011, "not an allowed rate/lanes for port" },
- { 6012, "not an allowed rate/lanes for port" },
- { 6013, "high/low error, change other port first" },
- { 6014, "config not found in flash" },
-};
-struct nfp_nsp {
- struct nfp_cpp *cpp;
- struct nfp_resource *res;
- struct {
- uint16_t major;
- uint16_t minor;
- } ver;
-
- /* Eth table config state */
- int modified;
- unsigned int idx;
- void *entries;
-};
+struct nfp_nsp;
struct nfp_nsp *nfp_nsp_open(struct nfp_cpp *cpp);
void nfp_nsp_close(struct nfp_nsp *state);
@@ -92,18 +22,61 @@ int nfp_nsp_read_identify(struct nfp_nsp *state, void *buf, size_t size);
int nfp_nsp_read_sensors(struct nfp_nsp *state, uint32_t sensor_mask,
void *buf, size_t size);
-static inline int
+static inline bool
nfp_nsp_has_mac_reinit(struct nfp_nsp *state)
{
return nfp_nsp_get_abi_ver_minor(state) > 20;
}
+static inline bool
+nfp_nsp_has_stored_fw_load(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 23;
+}
+
+static inline bool
+nfp_nsp_has_hwinfo_lookup(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 24;
+}
+
+static inline bool
+nfp_nsp_has_hwinfo_set(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 25;
+}
+
+static inline bool
+nfp_nsp_has_fw_loaded(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 25;
+}
+
+static inline bool
+nfp_nsp_has_versions(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 27;
+}
+
+static inline bool
+nfp_nsp_has_read_module_eeprom(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 28;
+}
+
+static inline bool
+nfp_nsp_has_read_media(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 33;
+}
+
enum nfp_eth_interface {
NFP_INTERFACE_NONE = 0,
NFP_INTERFACE_SFP = 1,
NFP_INTERFACE_SFPP = 10,
NFP_INTERFACE_SFP28 = 28,
NFP_INTERFACE_QSFP = 40,
+ NFP_INTERFACE_RJ45 = 45,
NFP_INTERFACE_CXP = 100,
NFP_INTERFACE_QSFP28 = 112,
};
@@ -151,6 +124,7 @@ struct nfp_eth_table {
enum nfp_eth_media media; /**< Media type of the @interface */
enum nfp_eth_fec fec; /**< Forward Error Correction mode */
+ enum nfp_eth_fec act_fec; /**< Active Forward Error Correction mode */
enum nfp_eth_aneg aneg; /**< Auto negotiation mode */
struct rte_ether_addr mac_addr; /**< Interface MAC address */
@@ -159,17 +133,18 @@ struct nfp_eth_table {
/** Id of interface within port (for split ports) */
uint8_t label_subport;
- int enabled; /**< Enable port */
- int tx_enabled; /**< Enable TX */
- int rx_enabled; /**< Enable RX */
+ bool enabled; /**< Enable port */
+ bool tx_enabled; /**< Enable TX */
+ bool rx_enabled; /**< Enable RX */
+ bool supp_aneg; /**< Support auto negotiation */
- int override_changed; /**< Media reconfig pending */
+ bool override_changed; /**< Media reconfig pending */
uint8_t port_type; /**< One of %PORT_* */
/** Sum of lanes of all subports of this port */
uint32_t port_lanes;
- int is_split; /**< Split port */
+ bool is_split; /**< Split port */
uint32_t fec_modes_supported; /**< Bitmap of FEC modes supported */
} ports[]; /**< Table of ports */
@@ -177,8 +152,8 @@ struct nfp_eth_table {
struct nfp_eth_table *nfp_eth_read_ports(struct nfp_cpp *cpp);
-int nfp_eth_set_mod_enable(struct nfp_cpp *cpp, uint32_t idx, int enable);
-int nfp_eth_set_configured(struct nfp_cpp *cpp, uint32_t idx, int configed);
+int nfp_eth_set_mod_enable(struct nfp_cpp *cpp, uint32_t idx, bool enable);
+int nfp_eth_set_configured(struct nfp_cpp *cpp, uint32_t idx, bool configured);
int nfp_eth_set_fec(struct nfp_cpp *cpp, uint32_t idx, enum nfp_eth_fec mode);
int nfp_nsp_read_eth_table(struct nfp_nsp *state, void *buf, size_t size);
@@ -187,12 +162,13 @@ int nfp_nsp_write_eth_table(struct nfp_nsp *state, const void *buf,
void nfp_nsp_config_set_state(struct nfp_nsp *state, void *entries,
uint32_t idx);
void nfp_nsp_config_clear_state(struct nfp_nsp *state);
-void nfp_nsp_config_set_modified(struct nfp_nsp *state, int modified);
+void nfp_nsp_config_set_modified(struct nfp_nsp *state, bool modified);
void *nfp_nsp_config_entries(struct nfp_nsp *state);
-int nfp_nsp_config_modified(struct nfp_nsp *state);
+struct nfp_cpp *nfp_nsp_cpp(struct nfp_nsp *state);
+bool nfp_nsp_config_modified(struct nfp_nsp *state);
uint32_t nfp_nsp_config_idx(struct nfp_nsp *state);
-static inline int
+static inline bool
nfp_eth_can_support_fec(struct nfp_eth_table_port *eth_port)
{
return eth_port->fec_modes_supported != 0;
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
index f656f200f4..46fa5467de 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_cmds.c
@@ -3,12 +3,8 @@
* All rights reserved.
*/
-#include <stdio.h>
-#include <rte_byteorder.h>
-#include "nfp_cpp.h"
#include "nfp_logs.h"
#include "nfp_nsp.h"
-#include "nfp_nffw.h"
struct nsp_identify {
uint8_t version[40];
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
index eb30d8e779..cc472907ca 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp_eth.c
@@ -3,10 +3,6 @@
* All rights reserved.
*/
-#include <stdio.h>
-#include <rte_common.h>
-#include <rte_byteorder.h>
-#include "nfp_cpp.h"
#include "nfp_logs.h"
#include "nfp_nsp.h"
#include "nfp_platform.h"
@@ -21,6 +17,7 @@
#define NSP_ETH_PORT_PHYLABEL GENMASK_ULL(59, 54)
#define NSP_ETH_PORT_FEC_SUPP_BASER RTE_BIT64(60)
#define NSP_ETH_PORT_FEC_SUPP_RS RTE_BIT64(61)
+#define NSP_ETH_PORT_SUPP_ANEG RTE_BIT64(63)
#define NSP_ETH_PORT_LANES_MASK rte_cpu_to_le_64(NSP_ETH_PORT_LANES)
@@ -34,6 +31,7 @@
#define NSP_ETH_STATE_OVRD_CHNG RTE_BIT64(22)
#define NSP_ETH_STATE_ANEG GENMASK_ULL(25, 23)
#define NSP_ETH_STATE_FEC GENMASK_ULL(27, 26)
+#define NSP_ETH_STATE_ACT_FEC GENMASK_ULL(29, 28)
#define NSP_ETH_CTRL_CONFIGURED RTE_BIT64(0)
#define NSP_ETH_CTRL_ENABLED RTE_BIT64(1)
@@ -54,26 +52,12 @@
#define PORT_NONE 0xef
#define PORT_OTHER 0xff
-#define SPEED_10 10
-#define SPEED_100 100
-#define SPEED_1000 1000
-#define SPEED_2500 2500
-#define SPEED_5000 5000
-#define SPEED_10000 10000
-#define SPEED_14000 14000
-#define SPEED_20000 20000
-#define SPEED_25000 25000
-#define SPEED_40000 40000
-#define SPEED_50000 50000
-#define SPEED_56000 56000
-#define SPEED_100000 100000
-
enum nfp_eth_raw {
NSP_ETH_RAW_PORT = 0,
NSP_ETH_RAW_STATE,
NSP_ETH_RAW_MAC,
NSP_ETH_RAW_CONTROL,
- NSP_ETH_NUM_RAW
+ NSP_ETH_NUM_RAW,
};
enum nfp_eth_rate {
@@ -100,12 +84,12 @@ static const struct {
enum nfp_eth_rate rate;
uint32_t speed;
} nsp_eth_rate_tbl[] = {
- { RATE_INVALID, 0, },
- { RATE_10M, SPEED_10, },
- { RATE_100M, SPEED_100, },
- { RATE_1G, SPEED_1000, },
- { RATE_10G, SPEED_10000, },
- { RATE_25G, SPEED_25000, },
+ { RATE_INVALID, RTE_ETH_SPEED_NUM_NONE, },
+ { RATE_10M, RTE_ETH_SPEED_NUM_10M, },
+ { RATE_100M, RTE_ETH_SPEED_NUM_100M, },
+ { RATE_1G, RTE_ETH_SPEED_NUM_1G, },
+ { RATE_10G, RTE_ETH_SPEED_NUM_10G, },
+ { RATE_25G, RTE_ETH_SPEED_NUM_25G, },
};
static uint32_t
@@ -193,7 +177,14 @@ nfp_eth_port_translate(struct nfp_nsp *nsp,
if (dst->fec_modes_supported != 0)
dst->fec_modes_supported |= NFP_FEC_AUTO | NFP_FEC_DISABLED;
- dst->fec = 1 << FIELD_GET(NSP_ETH_STATE_FEC, state);
+ dst->fec = FIELD_GET(NSP_ETH_STATE_FEC, state);
+ dst->act_fec = dst->fec;
+
+ if (nfp_nsp_get_abi_ver_minor(nsp) < 33)
+ return;
+
+ dst->act_fec = FIELD_GET(NSP_ETH_STATE_ACT_FEC, state);
+ dst->supp_aneg = FIELD_GET(NSP_ETH_PORT_SUPP_ANEG, port);
}
static void
@@ -222,7 +213,7 @@ nfp_eth_calc_port_geometry(struct nfp_eth_table *table)
table->ports[i].label_port,
table->ports[i].label_subport);
- table->ports[i].is_split = 1;
+ table->ports[i].is_split = true;
}
}
}
@@ -233,6 +224,9 @@ nfp_eth_calc_port_type(struct nfp_eth_table_port *entry)
if (entry->interface == NFP_INTERFACE_NONE) {
entry->port_type = PORT_NONE;
return;
+ } else if (entry->interface == NFP_INTERFACE_RJ45) {
+ entry->port_type = PORT_TP;
+ return;
}
if (entry->media == NFP_MEDIA_FIBRE)
@@ -251,7 +245,6 @@ nfp_eth_read_ports_real(struct nfp_nsp *nsp)
uint32_t table_sz;
struct nfp_eth_table *table;
union eth_table_entry *entries;
- const struct rte_ether_addr *mac;
entries = malloc(NSP_ETH_TABLE_SIZE);
if (entries == NULL)
@@ -264,16 +257,9 @@ nfp_eth_read_ports_real(struct nfp_nsp *nsp)
goto err;
}
- /*
- * The NFP3800 NIC support 8 ports, but only 2 ports are valid,
- * the rest 6 ports mac are all 0, ensure we don't use these port
- */
- for (i = 0; i < NSP_ETH_MAX_COUNT; i++) {
- mac = (const struct rte_ether_addr *)entries[i].mac_addr;
- if ((entries[i].port & NSP_ETH_PORT_LANES_MASK) != 0 &&
- !rte_is_zero_ether_addr(mac))
+ for (i = 0; i < NSP_ETH_MAX_COUNT; i++)
+ if ((entries[i].port & NSP_ETH_PORT_LANES_MASK) != 0)
cnt++;
- }
/*
* Some versions of flash will give us 0 instead of port count. For
@@ -294,11 +280,8 @@ nfp_eth_read_ports_real(struct nfp_nsp *nsp)
memset(table, 0, table_sz);
table->count = cnt;
for (i = 0, j = 0; i < NSP_ETH_MAX_COUNT; i++) {
- mac = (const struct rte_ether_addr *)entries[i].mac_addr;
- if ((entries[i].port & NSP_ETH_PORT_LANES_MASK) != 0 &&
- !rte_is_zero_ether_addr(mac))
- nfp_eth_port_translate(nsp, &entries[i], i,
- &table->ports[j++]);
+ if ((entries[i].port & NSP_ETH_PORT_LANES_MASK) != 0)
+ nfp_eth_port_translate(nsp, &entries[i], i, &table->ports[j++]);
}
nfp_eth_calc_port_geometry(table);
@@ -440,7 +423,7 @@ nfp_eth_config_commit_end(struct nfp_nsp *nsp)
int
nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
uint32_t idx,
- int enable)
+ bool enable)
{
uint64_t reg;
struct nfp_nsp *nsp;
@@ -448,7 +431,7 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
nsp = nfp_eth_config_start(cpp, idx);
if (nsp == NULL)
- return -1;
+ return -EIO;
entries = nfp_nsp_config_entries(nsp);
@@ -460,7 +443,7 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
reg |= FIELD_PREP(NSP_ETH_CTRL_ENABLED, enable);
entries[idx].control = rte_cpu_to_le_64(reg);
- nfp_nsp_config_set_modified(nsp, 1);
+ nfp_nsp_config_set_modified(nsp, true);
}
return nfp_eth_config_commit_end(nsp);
@@ -484,7 +467,7 @@ nfp_eth_set_mod_enable(struct nfp_cpp *cpp,
int
nfp_eth_set_configured(struct nfp_cpp *cpp,
uint32_t idx,
- int configured)
+ bool configured)
{
uint64_t reg;
struct nfp_nsp *nsp;
@@ -513,7 +496,7 @@ nfp_eth_set_configured(struct nfp_cpp *cpp,
reg |= FIELD_PREP(NSP_ETH_CTRL_CONFIGURED, configured);
entries[idx].control = rte_cpu_to_le_64(reg);
- nfp_nsp_config_set_modified(nsp, 1);
+ nfp_nsp_config_set_modified(nsp, true);
}
return nfp_eth_config_commit_end(nsp);
@@ -551,7 +534,7 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp,
entries[idx].control |= rte_cpu_to_le_64(ctrl_bit);
- nfp_nsp_config_set_modified(nsp, 1);
+ nfp_nsp_config_set_modified(nsp, true);
return 0;
}
--
2.39.1
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
@ 2023-09-19 14:47 0% ` David Marchand
2023-09-20 6:00 4% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-09-19 14:47 UTC (permalink / raw)
To: Stanisław Kardach, Sivaprasad Tummala
Cc: Ruifeng Wang, Min Zhou, David Christensen, Bruce Richardson,
Konstantin Ananyev, dev, Ferruh Yigit, Thomas Monjalon
Hello,
On Tue, Aug 15, 2023 at 8:10 AM Stanisław Kardach <kda@semihalf.com> wrote:
> On Fri, Aug 11, 2023, 08:08 Sivaprasad Tummala <sivaprasad.tummala@amd.com> wrote:
>> diff --git a/lib/eal/arm/include/rte_cpuflags_32.h b/lib/eal/arm/include/rte_cpuflags_32.h
>> index 4e254428a2..41ab0d5f21 100644
>> --- a/lib/eal/arm/include/rte_cpuflags_32.h
>> +++ b/lib/eal/arm/include/rte_cpuflags_32.h
>> @@ -43,7 +43,6 @@ enum rte_cpu_flag_t {
>> RTE_CPUFLAG_V7L,
>> RTE_CPUFLAG_V8L,
>> /* The last item */
>> - RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
>> };
>
> Since there is no description of V1 to V2 changes, could you point me to what has changed?
Siva? I did not see a reply on this question.
> Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS (what I call a last element canary). Why? If you're concerned with ABI, then we're talking about an application linking dynamically with DPDK or talking via some RPC channel with another DPDK application. So clashing with this definition does not come into question. One should rather use rte_cpu_get_flag_enabled().
> Also if you want to introduce new features, one would add them yo the rte_cpuflags headers, unless you'd like to not add those and keep an undocumented list "above" the last defined element.
> Could you explain a bit more Your use-case?
Hey Stanislaw,
Talking generically, one problem with such pattern (having a LAST, or
MAX enum) is when an array sized with such a symbol is exposed.
As I mentionned in the past, this can have unwanted effects:
https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
Another issue is when an existing enum meaning changes: from the
application pov, the (old) MAX value is incorrect, but for the library
pov, a new meaning has been associated.
This may trigger bugs in the application when calling a function that
returns such an enum which never return this MAX value in the past.
For at least those two reasons, removing those canary elements is
being done in DPDK.
This specific removal has been announced:
https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
Now, practically, when I look at the cpuflags API, I don't see us
exposed to those two issues wrt rte_cpu_flag_t, so maybe this change
is unneeded.
But on the other hand, is it really an issue for an application to
lose this (internal) information?
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-19 14:47 0% ` David Marchand
@ 2023-09-20 6:00 4% ` Stanisław Kardach
2023-09-20 7:34 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Stanisław Kardach @ 2023-09-20 6:00 UTC (permalink / raw)
To: David Marchand
Cc: Sivaprasad Tummala, Ruifeng Wang, Min Zhou, David Christensen,
Bruce Richardson, Konstantin Ananyev, dev, Ferruh Yigit,
Thomas Monjalon
[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]
On Tue, Sep 19, 2023 at 4:47 PM David Marchand <david.marchand@redhat.com>
wrote:
<snip>
> > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS (what I call
a last element canary). Why? If you're concerned with ABI, then we're
talking about an application linking dynamically with DPDK or talking via
some RPC channel with another DPDK application. So clashing with this
definition does not come into question. One should rather use
rte_cpu_get_flag_enabled().
> > Also if you want to introduce new features, one would add them yo the
rte_cpuflags headers, unless you'd like to not add those and keep an
undocumented list "above" the last defined element.
> > Could you explain a bit more Your use-case?
>
> Hey Stanislaw,
>
> Talking generically, one problem with such pattern (having a LAST, or
> MAX enum) is when an array sized with such a symbol is exposed.
> As I mentionned in the past, this can have unwanted effects:
>
https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
I agree, though I'd argue "LAST" and "MAX" semantics are a bit different.
"LAST" delimits the known enumeration territory while "MAX" is more of a
`constepxr` value type.
>
> Another issue is when an existing enum meaning changes: from the
> application pov, the (old) MAX value is incorrect, but for the library
> pov, a new meaning has been associated.
> This may trigger bugs in the application when calling a function that
> returns such an enum which never return this MAX value in the past.
>
> For at least those two reasons, removing those canary elements is
> being done in DPDK.
>
> This specific removal has been announced:
>
https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
Thanks for pointing this out but did you mean to link to the patch again
here?
>
> Now, practically, when I look at the cpuflags API, I don't see us
> exposed to those two issues wrt rte_cpu_flag_t, so maybe this change
> is unneeded.
> But on the other hand, is it really an issue for an application to
> lose this (internal) information?
I doubt it, maybe it could be used as a sanity check for choosing proper
functors in the application. Though the initial description of the reason
behind this patch was to not break the ABI and I don't think it does that.
What it does is enforces users to use explicit cpu flag values which is a
good thing. Though if so, then it should be stated in the commit
description.
>
[-- Attachment #2: Type: text/html, Size: 3334 bytes --]
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-20 6:00 4% ` Stanisław Kardach
@ 2023-09-20 7:34 0% ` David Marchand
2023-09-21 13:18 4% ` Tummala, Sivaprasad
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-09-20 7:34 UTC (permalink / raw)
To: Stanisław Kardach, Sivaprasad Tummala
Cc: Ruifeng Wang, Min Zhou, David Christensen, Bruce Richardson,
Konstantin Ananyev, dev, Ferruh Yigit, Thomas Monjalon
On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach <kda@semihalf.com> wrote:
>
> On Tue, Sep 19, 2023 at 4:47 PM David Marchand <david.marchand@redhat.com> wrote:
> <snip>
> > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS (what I call a last element canary). Why? If you're concerned with ABI, then we're talking about an application linking dynamically with DPDK or talking via some RPC channel with another DPDK application. So clashing with this definition does not come into question. One should rather use rte_cpu_get_flag_enabled().
> > > Also if you want to introduce new features, one would add them yo the rte_cpuflags headers, unless you'd like to not add those and keep an undocumented list "above" the last defined element.
> > > Could you explain a bit more Your use-case?
> >
> > Hey Stanislaw,
> >
> > Talking generically, one problem with such pattern (having a LAST, or
> > MAX enum) is when an array sized with such a symbol is exposed.
> > As I mentionned in the past, this can have unwanted effects:
> > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
Argh... who broke copy/paste in my browser ?!
Wrt to MAX and arrays, I wanted to point at:
http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuRTsUw@mail.gmail.com/
> I agree, though I'd argue "LAST" and "MAX" semantics are a bit different. "LAST" delimits the known enumeration territory while "MAX" is more of a `constepxr` value type.
> >
> > Another issue is when an existing enum meaning changes: from the
> > application pov, the (old) MAX value is incorrect, but for the library
> > pov, a new meaning has been associated.
> > This may trigger bugs in the application when calling a function that
> > returns such an enum which never return this MAX value in the past.
> >
> > For at least those two reasons, removing those canary elements is
> > being done in DPDK.
> >
> > This specific removal has been announced:
> > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493-1-david.marchand@redhat.com/
> Thanks for pointing this out but did you mean to link to the patch again here?
Sorry, same here, bad copy/paste :-(.
The intended link is: https://git.dpdk.org/dpdk/commit/?id=5da7c13521
The deprecation notice was badly formulated and this patch here is
consistent with it.
> >
> > Now, practically, when I look at the cpuflags API, I don't see us
> > exposed to those two issues wrt rte_cpu_flag_t, so maybe this change
> > is unneeded.
> > But on the other hand, is it really an issue for an application to
> > lose this (internal) information?
> I doubt it, maybe it could be used as a sanity check for choosing proper functors in the application. Though the initial description of the reason behind this patch was to not break the ABI and I don't think it does that. What it does is enforces users to use explicit cpu flag values which is a good thing. Though if so, then it should be stated in the commit description.
I agree.
Siva, can you work on a new revision?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* RE: [RFC PATCH 2/3] security: add TLS record processing
@ 2023-09-20 9:23 3% ` Van Haaren, Harry
2023-09-20 11:51 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Van Haaren, Harry @ 2023-09-20 9:23 UTC (permalink / raw)
To: Anoob Joseph, Thomas Monjalon, Akhil Goyal, Jerin Jacob,
Konstantin Ananyev
Cc: Hemant Agrawal, dev, Matz, Olivier, Vidya Sagar Velumuri
> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Friday, August 11, 2023 8:17 AM
> To: Thomas Monjalon <thomas@monjalon.net>; Akhil Goyal
> <gakhil@marvell.com>; Jerin Jacob <jerinj@marvell.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> <vvelumuri@marvell.com>
> Subject: [RFC PATCH 2/3] security: add TLS record processing
>
> Add Transport Layer Security (TLS) and Datagram Transport Layer Security
> (DTLS). The protocols provide communications privacy for L4 protocols
> such as TCP & UDP.
>
> TLS (and DTLS) protocol is composed of two layers,
> 1. TLS Record Protocol
> 2. TLS Handshake Protocol
>
> While TLS Handshake Protocol helps in establishing security parameters
> by which client and server can communicate, TLS Record Protocol provides
> the connection security. TLS Record Protocol leverages symmetric
> cryptographic operations such as data encryption and authentication for
> providing security to the communications.
>
> Cryptodevs that are capable of offloading TLS Record Protocol may
> perform other operations like IV generation, header insertion, atomic
> sequence number updates and anti-replay window check in addition to
> cryptographic transformations.
>
> The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
From the code below, my understanding is that *ONLY* the record layer is being
added/supported? The difference is described well above, but the intended
support added is not clearly defined.
Suggest reword the last line to clarify:
"Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and DTLS 1.2."
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> Signed-off-by: Vidya Sagar Velumuri <vvelumuri@marvell.com>
> ---
> doc/guides/prog_guide/rte_security.rst | 58 +++++++++++++
> lib/security/rte_security.c | 4 +
> lib/security/rte_security.h | 110 +++++++++++++++++++++++++
> 3 files changed, 172 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_security.rst
> b/doc/guides/prog_guide/rte_security.rst
> index 7418e35c1b..7716d7239f 100644
> --- a/doc/guides/prog_guide/rte_security.rst
> +++ b/doc/guides/prog_guide/rte_security.rst
> @@ -399,6 +399,64 @@ The API ``rte_security_macsec_sc_create`` returns a
> handle for SC,
> and this handle is set in ``rte_security_macsec_xform``
> to create a MACsec session using ``rte_security_session_create``.
>
> +TLS-Record Protocol
> +~~~~~~~~~~~~~~~~~~~
> +
> +The Transport Layer Protocol provides communications security over the
> Internet. The protocol
> +allows client/server applications to communicate in a way that is designed to
> prevent eavesdropping,
> +tampering, or message forgery.
> +
> +TLS protocol is composed of two layers: the TLS Record Protocol and the TLS
> Handshake Protocol. At
> +the lowest level, layered on top of some reliable transport protocol (e.g., TCP),
> is the TLS Record
> +Protocol. The TLS Record Protocol provides connection security that has two
> basic properties:
> +
> + - The connection is private. Symmetric cryptography is used for data
> + encryption (e.g., AES, DES, etc.). The keys for this symmetric encryption
> + are generated uniquely for each connection and are based on a secret
> + negotiated by another protocol (such as the TLS Handshake Protocol). The
> + Record Protocol can also be used without encryption.
> +
> + - The connection is reliable. Message transport includes a message
> + integrity check using a keyed MAC. Secure hash functions (e.g.,
> + SHA-1, etc.) are used for MAC computations. The Record Protocol
> + can operate without a MAC, but is generally only used in this mode
> + while another protocol is using the Record Protocol as a transport
> + for negotiating security parameters.
> +
> +.. code-block:: c
The code block below isn't C? Is there a better code block type for a text diagram?
> + Record Write Record Read
> + ------------ -----------
> +
> + TLSPlaintext TLSCiphertext
> + | |
> + ~ ~
> + | |
> + V V
> + +---------|----------+ +----------|---------+
> + | Seq. no generation | | Seq. no generation |
> + +---------|----------+ +----------|---------+
> + | |
> + +---------|----------+ +----------|---------+
> + | Header insertion | | Decryption & |
> + +---------|----------+ | MAC verification |
> + | +----------|---------+
> + +---------|----------+ |
> + | MAC generation & | +----------|---------+
> + | Encryption | | TLS Header removal |
> + +---------|----------+ +----------|---------+
> + | |
> + ~ ~
> + | |
> + V V
> + TLSCiphertext TLSPlaintext
> +
> +Supported Versions
> +^^^^^^^^^^^^^^^^^^
> +
> +* TLS 1.2
> +* TLS 1.3
> +* DTLS 1.2
>
> Device Features and Capabilities
> ---------------------------------
> diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
> index c4d64bb8e9..bd7b026547 100644
> --- a/lib/security/rte_security.c
> +++ b/lib/security/rte_security.c
> @@ -282,6 +282,10 @@ rte_security_capability_get(struct rte_security_ctx
> *instance,
> if (capability->docsis.direction ==
> idx->docsis.direction)
> return capability;
> + } else if (idx->protocol ==
> RTE_SECURITY_PROTOCOL_TLS_RECORD) {
> + if (capability->tls_record.ver == idx-
> >tls_record.ver &&
> + capability->tls_record.type == idx-
> >tls_record.type)
> + return capability;
> }
> }
> }
> diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> index 3b2df526ba..b9d064ed84 100644
> --- a/lib/security/rte_security.h
> +++ b/lib/security/rte_security.h
> @@ -620,6 +620,99 @@ struct rte_security_docsis_xform {
> /**< DOCSIS direction */
> };
>
> +/** Salt len to be used with AEAD algos in TLS 1.2 */
> +#define RTE_SECURITY_TLS_1_2_SALT_LEN 4
> +/** Salt len to be used with AEAD algos in TLS 1.3 */
> +#define RTE_SECURITY_TLS_1_3_SALT_LEN 12
> +/** Salt len to be used with AEAD algos in DTLS 1.2 */
> +#define RTE_SECURITY_DTLS_1_2_SALT_LEN 4
> +
> +/** TLS version */
> +enum rte_security_tls_version {
> + RTE_SECURITY_VERSION_TLS_1_2, /**< TLS 1.2 */
> + RTE_SECURITY_VERSION_TLS_1_3, /**< TLS 1.3 */
> + RTE_SECURITY_VERSION_DTLS_1_2, /**< DTLS 1.2 */
> +};
> +
> +/** TLS session type */
> +enum rte_security_tls_sess_type {
> + /** Record read session
> + * - Decrypt & digest verification.
> + */
> + RTE_SECURITY_TLS_SESS_TYPE_READ,
> + /** Record write session
> + * - Encrypt & digest generation.
> + */
> + RTE_SECURITY_TLS_SESS_TYPE_WRITE,
> +};
> +
> +/**
> + * Configure soft and hard lifetime of a TLS record session
> + *
> + * Lifetime of a TLS record session would specify the maximum number of
> packets that can be
> + * processed. TLS record processing operations would start failing once hard
> limit is reached.
> + *
> + * Soft limits can be specified to generate notification when the TLS record
> session is approaching
> + * hard limits for lifetime. This would result in a warning returned in
> ``rte_crypto_op.aux_flags``.
Can we define "a warning" better? Perhaps an example of a soft-limit and
hard-limit, what the user can check aux_flags for, to identify? Or link to the
appropriate part of the crypto_op.aux_flags documentation to help the user.
> + */
> +struct rte_security_tls_record_lifetime {
> + /** Soft expiry limit in number of packets */
> + uint64_t packets_soft_limit;
> + /** Hard expiry limit in number of packets */
> + uint64_t packets_hard_limit;
> +};
> +
> +/**
> + * TLS record protocol session configuration.
> + *
> + * This structure contains data required to create a TLS record security session.
> + */
> +struct rte_security_tls_record_xform {
> + /** TLS record version. */
> + enum rte_security_tls_version ver;
> + /** TLS record session type. */
> + enum rte_security_tls_sess_type type;
> + /** TLS record session lifetime. */
> + struct rte_security_tls_record_lifetime life;
> + union {
> + /** TLS 1.2 parameters. */
> + struct {
> + /** Starting sequence number. */
> + uint64_t seq_no;
> + /** Salt to be used for AEAD algos. */
> + uint8_t salt[RTE_SECURITY_TLS_1_2_SALT_LEN];
> + } tls_1_2;
> +
> + /** TLS 1.3 parameters. */
> + struct {
> + /** Starting sequence number. */
> + uint64_t seq_no;
> + /** Salt to be used for AEAD algos. */
> + uint8_t salt[RTE_SECURITY_TLS_1_3_SALT_LEN];
> + /**
> + * Minimum payload length (in case of write sessions).
> For shorter inputs,
> + * the payload would be padded appropriately before
> performing crypto
Replace "would be" with "must be"? And who must do this step, is it the application?
> + * transformations.
> + */
> + uint32_t min_payload_len;
> + } tls_1_3;
> +
> + /** DTLS 1.2 parameters */
> + struct {
> + /** Epoch value to be used. */
> + uint16_t epoch;
> + /** 6B starting sequence number to be used. */
> + uint64_t seq_no;
> + /** Salt to be used for AEAD algos. */
> + uint8_t salt[RTE_SECURITY_DTLS_1_2_SALT_LEN];
> + /** Anti replay window size to enable sequence replay
> attack handling.
> + * Anti replay check is disabled if the window size is 0.
> + */
> + uint32_t ar_win_sz;
> + } dtls_1_2;
> + };
> +};
> +
> /**
> * Security session action type.
> */
> @@ -654,6 +747,8 @@ enum rte_security_session_protocol {
> /**< PDCP Protocol */
> RTE_SECURITY_PROTOCOL_DOCSIS,
> /**< DOCSIS Protocol */
> + RTE_SECURITY_PROTOCOL_TLS_RECORD,
> + /**< TLS Record Protocol */
> };
>
> /**
> @@ -670,6 +765,7 @@ struct rte_security_session_conf {
> struct rte_security_macsec_xform macsec;
> struct rte_security_pdcp_xform pdcp;
> struct rte_security_docsis_xform docsis;
> + struct rte_security_tls_record_xform tls;
Do we see TLS handshake xform being added in future? If so, is 'tls' a good name, perhaps 'tls_record'?
That would allow 'tls_handshake' in future, with consistent naming scheme without API/ABI break.
> };
> /**< Configuration parameters for security session */
> struct rte_crypto_sym_xform *crypto_xform;
> @@ -1190,6 +1286,16 @@ struct rte_security_capability {
> /**< DOCSIS direction */
> } docsis;
> /**< DOCSIS capability */
> + struct {
> + enum rte_security_tls_version ver;
> + /**< TLS record version. */
> + enum rte_security_tls_sess_type type;
> + /**< TLS record session type. */
> + uint32_t ar_win_size;
> + /**< Maximum anti replay window size supported for
> DTLS 1.2 record read
> + * operation. Value of 0 means anti replay check is not
> supported.
> + */
> + } tls_record;
Missing /**< TLS Record Capability */ docstring here.
> };
>
> const struct rte_cryptodev_capabilities *crypto_capabilities;
> @@ -1251,6 +1357,10 @@ struct rte_security_capability_idx {
> struct {
> enum rte_security_docsis_direction direction;
> } docsis;
> + struct {
> + enum rte_security_tls_version ver;
> + enum rte_security_tls_sess_type type;
> + } tls_record;
> };
> };
>
> --
> 2.25.1
^ permalink raw reply [relevance 3%]
* RE: [RFC PATCH 2/3] security: add TLS record processing
2023-09-20 9:23 3% ` Van Haaren, Harry
@ 2023-09-20 11:51 0% ` Anoob Joseph
2023-09-21 8:38 0% ` Van Haaren, Harry
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2023-09-20 11:51 UTC (permalink / raw)
To: Van Haaren, Harry
Cc: Hemant Agrawal, dev, Matz, Olivier, Vidya Sagar Velumuri,
Thomas Monjalon, Akhil Goyal, Jerin Jacob Kollanukkaran,
Konstantin Ananyev
Hi Harry,
Thanks for the review. Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Van Haaren, Harry <harry.van.haaren@intel.com>
> Sent: Wednesday, September 20, 2023 2:53 PM
> To: Anoob Joseph <anoobj@marvell.com>; Thomas Monjalon
> <thomas@monjalon.net>; Akhil Goyal <gakhil@marvell.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> <vvelumuri@marvell.com>
> Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record processing
>
> External Email
>
> ----------------------------------------------------------------------
> > -----Original Message-----
> > From: Anoob Joseph <anoobj@marvell.com>
> > Sent: Friday, August 11, 2023 8:17 AM
> > To: Thomas Monjalon <thomas@monjalon.net>; Akhil Goyal
> > <gakhil@marvell.com>; Jerin Jacob <jerinj@marvell.com>; Konstantin
> > Ananyev <konstantin.v.ananyev@yandex.ru>
> > Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> > Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> > <vvelumuri@marvell.com>
> > Subject: [RFC PATCH 2/3] security: add TLS record processing
> >
> > Add Transport Layer Security (TLS) and Datagram Transport Layer
> > Security (DTLS). The protocols provide communications privacy for L4
> > protocols such as TCP & UDP.
> >
> > TLS (and DTLS) protocol is composed of two layers, 1. TLS Record
> > Protocol 2. TLS Handshake Protocol
> >
> > While TLS Handshake Protocol helps in establishing security parameters
> > by which client and server can communicate, TLS Record Protocol
> > provides the connection security. TLS Record Protocol leverages
> > symmetric cryptographic operations such as data encryption and
> > authentication for providing security to the communications.
> >
> > Cryptodevs that are capable of offloading TLS Record Protocol may
> > perform other operations like IV generation, header insertion, atomic
> > sequence number updates and anti-replay window check in addition to
> > cryptographic transformations.
> >
> > The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
>
> From the code below, my understanding is that *ONLY* the record layer is
> being added/supported? The difference is described well above, but the
> intended support added is not clearly defined.
>
> Suggest reword the last line to clarify:
> "Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and DTLS 1.2."
[Anoob] Indeed. Will reword as suggested.
>
>
> > Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > Signed-off-by: Vidya Sagar Velumuri <vvelumuri@marvell.com>
> > ---
> > doc/guides/prog_guide/rte_security.rst | 58 +++++++++++++
> > lib/security/rte_security.c | 4 +
> > lib/security/rte_security.h | 110 +++++++++++++++++++++++++
> > 3 files changed, 172 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_security.rst
> > b/doc/guides/prog_guide/rte_security.rst
> > index 7418e35c1b..7716d7239f 100644
> > --- a/doc/guides/prog_guide/rte_security.rst
> > +++ b/doc/guides/prog_guide/rte_security.rst
> > @@ -399,6 +399,64 @@ The API ``rte_security_macsec_sc_create`` returns
> > a handle for SC, and this handle is set in
> > ``rte_security_macsec_xform`` to create a MACsec session using
> > ``rte_security_session_create``.
> >
> > +TLS-Record Protocol
> > +~~~~~~~~~~~~~~~~~~~
> > +
> > +The Transport Layer Protocol provides communications security over
> > +the
> > Internet. The protocol
> > +allows client/server applications to communicate in a way that is
> > +designed to
> > prevent eavesdropping,
> > +tampering, or message forgery.
> > +
> > +TLS protocol is composed of two layers: the TLS Record Protocol and
> > +the TLS
> > Handshake Protocol. At
> > +the lowest level, layered on top of some reliable transport protocol
> > +(e.g., TCP),
> > is the TLS Record
> > +Protocol. The TLS Record Protocol provides connection security that
> > +has two
> > basic properties:
> > +
> > + - The connection is private. Symmetric cryptography is used for data
> > + encryption (e.g., AES, DES, etc.). The keys for this symmetric
> encryption
> > + are generated uniquely for each connection and are based on a secret
> > + negotiated by another protocol (such as the TLS Handshake Protocol).
> The
> > + Record Protocol can also be used without encryption.
> > +
> > + - The connection is reliable. Message transport includes a message
> > + integrity check using a keyed MAC. Secure hash functions (e.g.,
> > + SHA-1, etc.) are used for MAC computations. The Record Protocol
> > + can operate without a MAC, but is generally only used in this mode
> > + while another protocol is using the Record Protocol as a transport
> > + for negotiating security parameters.
> > +
> > +.. code-block:: c
>
> The code block below isn't C? Is there a better code block type for a text
> diagram?
[Anoob] Valid point. I was just following the general scheme followed in this file. May be, I'll introduce a .svg image for newly added code.
>
> > + Record Write Record Read
> > + ------------ -----------
> > +
> > + TLSPlaintext TLSCiphertext
> > + | |
> > + ~ ~
> > + | |
> > + V V
> > + +---------|----------+ +----------|---------+
> > + | Seq. no generation | | Seq. no generation |
> > + +---------|----------+ +----------|---------+
> > + | |
> > + +---------|----------+ +----------|---------+
> > + | Header insertion | | Decryption & |
> > + +---------|----------+ | MAC verification |
> > + | +----------|---------+
> > + +---------|----------+ |
> > + | MAC generation & | +----------|---------+
> > + | Encryption | | TLS Header removal |
> > + +---------|----------+ +----------|---------+
> > + | |
> > + ~ ~
> > + | |
> > + V V
> > + TLSCiphertext TLSPlaintext
> > +
> > +Supported Versions
> > +^^^^^^^^^^^^^^^^^^
> > +
> > +* TLS 1.2
> > +* TLS 1.3
> > +* DTLS 1.2
> >
> > Device Features and Capabilities
> > ---------------------------------
> > diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
> > index c4d64bb8e9..bd7b026547 100644
> > --- a/lib/security/rte_security.c
> > +++ b/lib/security/rte_security.c
> > @@ -282,6 +282,10 @@ rte_security_capability_get(struct
> > rte_security_ctx *instance,
> > if (capability->docsis.direction ==
> > idx->docsis.direction)
> > return capability;
> > + } else if (idx->protocol ==
> > RTE_SECURITY_PROTOCOL_TLS_RECORD) {
> > + if (capability->tls_record.ver == idx-
> > >tls_record.ver &&
> > + capability->tls_record.type == idx-
> > >tls_record.type)
> > + return capability;
> > }
> > }
> > }
> > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> > index 3b2df526ba..b9d064ed84 100644
> > --- a/lib/security/rte_security.h
> > +++ b/lib/security/rte_security.h
> > @@ -620,6 +620,99 @@ struct rte_security_docsis_xform {
> > /**< DOCSIS direction */
> > };
> >
> > +/** Salt len to be used with AEAD algos in TLS 1.2 */ #define
> > +RTE_SECURITY_TLS_1_2_SALT_LEN 4
> > +/** Salt len to be used with AEAD algos in TLS 1.3 */ #define
> > +RTE_SECURITY_TLS_1_3_SALT_LEN 12
> > +/** Salt len to be used with AEAD algos in DTLS 1.2 */ #define
> > +RTE_SECURITY_DTLS_1_2_SALT_LEN 4
> > +
> > +/** TLS version */
> > +enum rte_security_tls_version {
> > + RTE_SECURITY_VERSION_TLS_1_2, /**< TLS 1.2 */
> > + RTE_SECURITY_VERSION_TLS_1_3, /**< TLS 1.3 */
> > + RTE_SECURITY_VERSION_DTLS_1_2, /**< DTLS 1.2 */
> > +};
> > +
> > +/** TLS session type */
> > +enum rte_security_tls_sess_type {
> > + /** Record read session
> > + * - Decrypt & digest verification.
> > + */
> > + RTE_SECURITY_TLS_SESS_TYPE_READ,
> > + /** Record write session
> > + * - Encrypt & digest generation.
> > + */
> > + RTE_SECURITY_TLS_SESS_TYPE_WRITE,
> > +};
> > +
> > +/**
> > + * Configure soft and hard lifetime of a TLS record session
> > + *
> > + * Lifetime of a TLS record session would specify the maximum number
> > +of
> > packets that can be
> > + * processed. TLS record processing operations would start failing
> > + once hard
> > limit is reached.
> > + *
> > + * Soft limits can be specified to generate notification when the TLS
> > + record
> > session is approaching
> > + * hard limits for lifetime. This would result in a warning returned
> > + in
> > ``rte_crypto_op.aux_flags``.
>
> Can we define "a warning" better? Perhaps an example of a soft-limit and
> hard-limit, what the user can check aux_flags for, to identify? Or link to the
> appropriate part of the crypto_op.aux_flags documentation to help the user.
>
[Anoob] The concept of lifetime is present in most protocols. Idea is to limit the max number of operations performed with a session. Soft expiry notification is to help application prepare for an expiry and setup a new session before the current one expires. The idea was borrowed from IPsec which has the 'RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY' flag defined. But I realize, it should be better defined. I can rename the flag to 'RTE_CRYPTO_OP_AUX_FLAGS_SEC_SOFT_EXPIRY' to avoid redefining same flag for each security offload. Do you agree to this suggestion?
https://elixir.bootlin.com/dpdk/latest/source/lib/cryptodev/rte_crypto.h#L67
Do note that once hard expiry is hit, the operation would fail. Expectation is, cryptodev would return 'RTE_CRYPTO_OP_STATUS_ERROR' in case of errors.
> > + */
> > +struct rte_security_tls_record_lifetime {
> > + /** Soft expiry limit in number of packets */
> > + uint64_t packets_soft_limit;
> > + /** Hard expiry limit in number of packets */
> > + uint64_t packets_hard_limit;
> > +};
> > +
> > +/**
> > + * TLS record protocol session configuration.
> > + *
> > + * This structure contains data required to create a TLS record security
> session.
> > + */
> > +struct rte_security_tls_record_xform {
> > + /** TLS record version. */
> > + enum rte_security_tls_version ver;
> > + /** TLS record session type. */
> > + enum rte_security_tls_sess_type type;
> > + /** TLS record session lifetime. */
> > + struct rte_security_tls_record_lifetime life;
> > + union {
> > + /** TLS 1.2 parameters. */
> > + struct {
> > + /** Starting sequence number. */
> > + uint64_t seq_no;
> > + /** Salt to be used for AEAD algos. */
> > + uint8_t salt[RTE_SECURITY_TLS_1_2_SALT_LEN];
> > + } tls_1_2;
> > +
> > + /** TLS 1.3 parameters. */
> > + struct {
> > + /** Starting sequence number. */
> > + uint64_t seq_no;
> > + /** Salt to be used for AEAD algos. */
> > + uint8_t salt[RTE_SECURITY_TLS_1_3_SALT_LEN];
> > + /**
> > + * Minimum payload length (in case of write
> sessions).
> > For shorter inputs,
> > + * the payload would be padded appropriately before
> > performing crypto
>
> Replace "would be" with "must be"? And who must do this step, is it the
> application?
[Anoob] Padding is performed by the PMD/cryptodev device. I'll change "would be" to "will be". Would that address your concern?
>
> > + * transformations.
> > + */
> > + uint32_t min_payload_len;
> > + } tls_1_3;
> > +
> > + /** DTLS 1.2 parameters */
> > + struct {
> > + /** Epoch value to be used. */
> > + uint16_t epoch;
> > + /** 6B starting sequence number to be used. */
> > + uint64_t seq_no;
> > + /** Salt to be used for AEAD algos. */
> > + uint8_t salt[RTE_SECURITY_DTLS_1_2_SALT_LEN];
> > + /** Anti replay window size to enable sequence
> replay
> > attack handling.
> > + * Anti replay check is disabled if the window size is 0.
> > + */
> > + uint32_t ar_win_sz;
> > + } dtls_1_2;
> > + };
> > +};
> > +
> > /**
> > * Security session action type.
> > */
> > @@ -654,6 +747,8 @@ enum rte_security_session_protocol {
> > /**< PDCP Protocol */
> > RTE_SECURITY_PROTOCOL_DOCSIS,
> > /**< DOCSIS Protocol */
> > + RTE_SECURITY_PROTOCOL_TLS_RECORD,
> > + /**< TLS Record Protocol */
> > };
> >
> > /**
> > @@ -670,6 +765,7 @@ struct rte_security_session_conf {
> > struct rte_security_macsec_xform macsec;
> > struct rte_security_pdcp_xform pdcp;
> > struct rte_security_docsis_xform docsis;
> > + struct rte_security_tls_record_xform tls;
>
> Do we see TLS handshake xform being added in future? If so, is 'tls' a good
> name, perhaps 'tls_record'?
> That would allow 'tls_handshake' in future, with consistent naming scheme
> without API/ABI break.
[Anoob] In the future, I would like to see TLS handshake also offloaded in a similar manner. But that would need some fundamental changes in security library. Like, current security library is pretty much tied to symmetric operations but a handshake would involve both symmetric & asymmetric operations.
Said that, I agree with your suggestion to rename the field. Will change it to 'tls_record' in next version.
>
>
> > };
> > /**< Configuration parameters for security session */
> > struct rte_crypto_sym_xform *crypto_xform; @@ -1190,6 +1286,16
> @@
> > struct rte_security_capability {
> > /**< DOCSIS direction */
> > } docsis;
> > /**< DOCSIS capability */
> > + struct {
> > + enum rte_security_tls_version ver;
> > + /**< TLS record version. */
> > + enum rte_security_tls_sess_type type;
> > + /**< TLS record session type. */
> > + uint32_t ar_win_size;
> > + /**< Maximum anti replay window size supported
> for
> > DTLS 1.2 record read
> > + * operation. Value of 0 means anti replay check is
> not
> > supported.
> > + */
> > + } tls_record;
>
> Missing /**< TLS Record Capability */ docstring here.
[Anoob] Agreed. Will add in next version.
>
> > };
> >
> > const struct rte_cryptodev_capabilities *crypto_capabilities; @@
> > -1251,6 +1357,10 @@ struct rte_security_capability_idx {
> > struct {
> > enum rte_security_docsis_direction direction;
> > } docsis;
> > + struct {
> > + enum rte_security_tls_version ver;
> > + enum rte_security_tls_sess_type type;
> > + } tls_record;
> > };
> > };
> >
> > --
> > 2.25.1
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 2/7] ethdev: support setting and querying RSS algorithm
@ 2023-09-20 16:39 3% ` Ferruh Yigit
2023-09-26 13:23 0% ` Jie Hai
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-20 16:39 UTC (permalink / raw)
To: Jie Hai, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam; +Cc: lihuisong
On 9/8/2023 9:00 AM, Jie Hai wrote:
> Currently, rte_eth_rss_conf supports configuring and querying
> RSS hash functions, rss key and it's length, but not RSS hash
> algorithm.
>
> The structure ``rte_eth_rss_conf`` is extended by adding a new
> field "func". This represents the RSS algorithms to apply. The
> following API will be affected:
> - rte_eth_dev_configure
> - rte_eth_dev_rss_hash_update
> - rte_eth_dev_rss_hash_conf_get
>
The problem with adding new configuration fields is, none of the drivers
are using it.
I can see you are updating hns3 driver in next patch, but what about
others, application will set this field and almost all drivers will
ignore it for now.
And in near future, some will be supporting it and some won't, still
frustrating for the application perspective.
In the past I was gathering list of these items and follow
implementation of them with drivers, but as the number of drivers
increased this became very hard to manage.
Another way to manage this is go and update all drivers, and if the
configuration requests anything other than
'RTE_ETH_HASH_FUNCTION_DEFAULT', return error. So that application can
know this is not supported by this driver.
Do you have better solution for this?
> If the value of "func" used for configuration is a gibberish
> value, report the error and return. Do the same for
> rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
>
> To check whether the drivers report the "func" field, it is set
> to default value before querying.
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
> doc/guides/rel_notes/release_23_11.rst | 2 ++
> lib/ethdev/rte_ethdev.c | 17 +++++++++++++++++
> lib/ethdev/rte_ethdev.h | 21 +++++++++++++++++++++
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 22 ++--------------------
> 5 files changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
> index 333e1d95a283..deb019fbe4c1 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -129,6 +129,8 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* ethdev: Added "func" field to ``rte_eth_rss_conf`` structure for RSS hash
> + algorithm.
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 0840d2b5942a..4cbcdb344cac 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1445,6 +1445,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> goto rollback;
> }
>
> + if (dev_conf->rx_adv_conf.rss_conf.func >= RTE_ETH_HASH_FUNCTION_MAX) {
> + RTE_ETHDEV_LOG(ERR,
> + "Ethdev port_id=%u invalid rss hash function (%u)\n",
> + port_id, dev_conf->rx_adv_conf.rss_conf.func);
> + ret = -EINVAL;
> + goto rollback;
> + }
> +
> /* Check if Rx RSS distribution is disabled but RSS hash is enabled. */
> if (((dev_conf->rxmode.mq_mode & RTE_ETH_MQ_RX_RSS_FLAG) == 0) &&
> (dev_conf->rxmode.offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)) {
> @@ -4630,6 +4638,13 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
> return -ENOTSUP;
> }
>
> + if (rss_conf->func >= RTE_ETH_HASH_FUNCTION_MAX) {
> + RTE_ETHDEV_LOG(ERR,
> + "Ethdev port_id=%u invalid rss hash function (%u)\n",
> + port_id, rss_conf->func);
> + return -EINVAL;
> + }
> +
> if (*dev->dev_ops->rss_hash_update == NULL)
> return -ENOTSUP;
> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
> @@ -4657,6 +4672,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
> return -EINVAL;
> }
>
> + rss_conf->func = RTE_ETH_HASH_FUNCTION_DEFAULT;
> +
>
I think setting this in ethdev level is not required if you update all
drivers to not accept anything other than DEFAULT.
> if (*dev->dev_ops->rss_hash_conf_get == NULL)
> return -ENOTSUP;
> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 40cfbb7efddd..33cec3570f85 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -445,6 +445,26 @@ struct rte_vlan_filter_conf {
> uint64_t ids[64];
> };
>
> +/**
> + * Hash function types.
> + */
> +enum rte_eth_hash_function {
> + /**
> + * DEFAULT means that conformance to a specific hash algorithm is
> + * uncared to the caller. The driver can pick the one it deems optimal.
> + */
> + RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> + RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> + RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> + /**
> + * Symmetric Toeplitz: src, dst will be replaced by
> + * xor(src, dst). For the case with src/dst only,
> + * src or dst address will xor with zero pair.
> + */
> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
> + RTE_ETH_HASH_FUNCTION_MAX,
As we are moving this to ethdev.h, when we want to add a new algorithm,
it will cause ABI break because of the 'RTE_ETH_HASH_FUNCTION_MAX', and
it will need to wait. Is there a way to eliminate this MAX enum?
> +};
> +
> /**
> * A structure used to configure the Receive Side Scaling (RSS) feature
> * of an Ethernet port.
> @@ -464,6 +484,7 @@ struct rte_eth_rss_conf {
> * Supplying an *rss_hf* equal to zero disables the RSS feature.
> */
> uint64_t rss_hf;
> + enum rte_eth_hash_function func; /**< Hash algorithm. */
Can we use 'algorithm' as the field name?
I know it won't exactly match type name (rte_eth_hash_function) but I
think this will be more accurate also less confusing for "rss_hf (rss
hash function)" and "func (function)"?
> };
>
> /*
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 271d854f7807..d3f2d466d841 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -12,7 +12,6 @@
> #include <rte_branch_prediction.h>
> #include <rte_string_fns.h>
> #include <rte_mbuf_dyn.h>
> -#include "rte_ethdev.h"
> #include "rte_flow_driver.h"
> #include "rte_flow.h"
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 3bd0dc64fbe2..a7578b1d2eff 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -40,6 +40,8 @@
> #include <rte_macsec.h>
> #include <rte_ib.h>
>
> +#include "rte_ethdev.h"
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -3183,26 +3185,6 @@ struct rte_flow_query_count {
> uint64_t bytes; /**< Number of bytes through this rule [out]. */
> };
>
> -/**
> - * Hash function types.
> - */
> -enum rte_eth_hash_function {
> - /**
> - * DEFAULT means that conformance to a specific hash algorithm is
> - * uncared to the caller. The driver can pick the one it deems optimal.
> - */
> - RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> - RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> - RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> - /**
> - * Symmetric Toeplitz: src, dst will be replaced by
> - * xor(src, dst). For the case with src/dst only,
> - * src or dst address will xor with zero pair.
> - */
> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
> - RTE_ETH_HASH_FUNCTION_MAX,
> -};
> -
> /**
> * RTE_FLOW_ACTION_TYPE_RSS
> *
^ permalink raw reply [relevance 3%]
* [PATCH v2 1/3] security: introduce out of place support for inline ingress
@ 2023-09-21 2:15 4% ` Nithin Dabilpuram
0 siblings, 0 replies; 200+ results
From: Nithin Dabilpuram @ 2023-09-21 2:15 UTC (permalink / raw)
To: gakhil, Cristian Dumitrescu; +Cc: jerinj, dev, Nithin Dabilpuram
Similar to out of place(OOP) processing support that exists for
Lookaside crypto/security sessions, Inline ingress security
sessions may also need out of place processing in usecases
where original encrypted packet needs to be retained for post
processing. So for NIC's which have such a kind of HW support,
a new SA option is provided to indicate whether OOP needs to
be enabled on that Inline ingress security session or not.
Since for inline ingress sessions, packet is not received by
CPU until the processing is done, we can only have per-SA
option and not per-packet option like Lookaside sessions.
Also remove reserved_opts field from the rte_security_ipsec_sa_options
struct as mentioned in deprecation notice.
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
---
v2:
- Fix documentation issue in 1/3 and update release notes
v1:
- Removed reserved_opts field from sa_options struct
doc/guides/rel_notes/deprecation.rst | 5 ----
doc/guides/rel_notes/release_23_11.rst | 8 ++++++
lib/pipeline/rte_swx_ipsec.c | 1 -
lib/security/rte_security.c | 17 +++++++++++
lib/security/rte_security.h | 40 ++++++++++++++++++++++----
lib/security/rte_security_driver.h | 8 ++++++
lib/security/version.map | 2 ++
7 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index bcd02e7762..8311035f2d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -147,11 +147,6 @@ Deprecation Notices
* security: Hide structures ``rte_security_ops`` and ``rte_security_ctx``
as these are internal to DPDK library and drivers.
-* security: New SA option ``ingress_oop`` would be added in structure
- ``rte_security_ipsec_sa_options`` to support out of place processing
- for inline inbound SA from DPDK 23.11. ``reserved_opts`` field in the
- same struct would be removed as discussed in techboard meeting.
-
* eventdev: The single-event (non-burst) enqueue and dequeue operations,
used by static inline burst enqueue and dequeue functions in ``rte_eventdev.h``,
will be removed in DPDK 23.11.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 55ba7c16ae..85d4a929b0 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -86,6 +86,10 @@ New Features
Enabled support for QAT 2.0c (4944) devices in QAT crypto driver.
+* **Added out of place processing support for inline ingress security session.**
+
+ Similar to out of place processing support for lookaside security session, added
+ the same support for inline ingress security session.
Removed Items
-------------
@@ -109,6 +113,8 @@ Removed Items
``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
``rte_crypto_asym_xform_strings``.
+* security: Removed deprecated field ``reserved_opts`` from struct
+ ``rte_security_ipsec_sa_options``.
API Changes
-----------
@@ -141,6 +147,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* security: struct ``rte_security_ipsec_sa_options`` was updated due to inline
+ out-of-place feature addition.
Known Issues
------------
diff --git a/lib/pipeline/rte_swx_ipsec.c b/lib/pipeline/rte_swx_ipsec.c
index 6c217ee797..28576c2a48 100644
--- a/lib/pipeline/rte_swx_ipsec.c
+++ b/lib/pipeline/rte_swx_ipsec.c
@@ -1555,7 +1555,6 @@ ipsec_xform_get(struct rte_swx_ipsec_sa_params *p,
ipsec_xform->options.ip_csum_enable = 0;
ipsec_xform->options.l4_csum_enable = 0;
ipsec_xform->options.ip_reassembly_en = 0;
- ipsec_xform->options.reserved_opts = 0;
ipsec_xform->direction = p->encrypt ?
RTE_SECURITY_IPSEC_SA_DIR_EGRESS :
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index 2d729b735b..42af4a2c35 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -27,7 +27,10 @@
} while (0)
#define RTE_SECURITY_DYNFIELD_NAME "rte_security_dynfield_metadata"
+#define RTE_SECURITY_OOP_DYNFIELD_NAME "rte_security_oop_dynfield_metadata"
+
int rte_security_dynfield_offset = -1;
+int rte_security_oop_dynfield_offset = -1;
int
rte_security_dynfield_register(void)
@@ -42,6 +45,20 @@ rte_security_dynfield_register(void)
return rte_security_dynfield_offset;
}
+int
+rte_security_oop_dynfield_register(void)
+{
+ static const struct rte_mbuf_dynfield dynfield_desc = {
+ .name = RTE_SECURITY_OOP_DYNFIELD_NAME,
+ .size = sizeof(rte_security_oop_dynfield_t),
+ .align = __alignof__(rte_security_oop_dynfield_t),
+ };
+
+ rte_security_oop_dynfield_offset =
+ rte_mbuf_dynfield_register(&dynfield_desc);
+ return rte_security_oop_dynfield_offset;
+}
+
void *
rte_security_session_create(struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 439bbb957f..da58fe1f14 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -273,14 +273,16 @@ struct rte_security_ipsec_sa_options {
*/
uint32_t ip_reassembly_en : 1;
- /** Reserved bit fields for future extension
+ /** Enable out of place processing on inline inbound packets.
*
- * User should ensure reserved_opts is cleared as it may change in
- * subsequent releases to support new options.
- *
- * Note: Reduce number of bits in reserved_opts for every new option.
+ * * 1: Enable driver to perform Out-of-place(OOP) processing for this inline
+ * inbound SA if supported by driver. PMD need to register mbuf
+ * dynamic field using rte_security_oop_dynfield_register()
+ * and security session creation would fail if dynfield is not
+ * registered successfully.
+ * * 0: Disable OOP processing for this session (default).
*/
- uint32_t reserved_opts : 17;
+ uint32_t ingress_oop : 1;
};
/** IPSec security association direction */
@@ -825,6 +827,13 @@ typedef uint64_t rte_security_dynfield_t;
/** Dynamic mbuf field for device-specific metadata */
extern int rte_security_dynfield_offset;
+/** Out-of-Place(OOP) processing field type */
+typedef struct rte_mbuf *rte_security_oop_dynfield_t;
+/** Dynamic mbuf field for pointer to original mbuf for
+ * OOP processing session.
+ */
+extern int rte_security_oop_dynfield_offset;
+
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
@@ -847,6 +856,25 @@ rte_security_dynfield(struct rte_mbuf *mbuf)
rte_security_dynfield_t *);
}
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Get pointer to mbuf field for original mbuf pointer when
+ * Out-Of-Place(OOP) processing is enabled in security session.
+ *
+ * @param mbuf packet to access
+ * @return pointer to mbuf field
+ */
+__rte_experimental
+static inline rte_security_oop_dynfield_t *
+rte_security_oop_dynfield(struct rte_mbuf *mbuf)
+{
+ return RTE_MBUF_DYNFIELD(mbuf,
+ rte_security_oop_dynfield_offset,
+ rte_security_oop_dynfield_t *);
+}
+
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
diff --git a/lib/security/rte_security_driver.h b/lib/security/rte_security_driver.h
index 31444a05d3..1e6a6ef8e3 100644
--- a/lib/security/rte_security_driver.h
+++ b/lib/security/rte_security_driver.h
@@ -197,6 +197,14 @@ typedef int (*security_macsec_sa_stats_get_t)(void *device, uint16_t sa_id,
__rte_internal
int rte_security_dynfield_register(void);
+/**
+ * @internal
+ * Register mbuf dynamic field for security inline ingress Out-of-Place(OOP)
+ * processing.
+ */
+__rte_internal
+int rte_security_oop_dynfield_register(void);
+
/**
* Update the mbuf with provided metadata.
*
diff --git a/lib/security/version.map b/lib/security/version.map
index b2097a969d..86f976a302 100644
--- a/lib/security/version.map
+++ b/lib/security/version.map
@@ -23,10 +23,12 @@ EXPERIMENTAL {
rte_security_macsec_sc_stats_get;
rte_security_session_stats_get;
rte_security_session_update;
+ rte_security_oop_dynfield_offset;
};
INTERNAL {
global:
rte_security_dynfield_register;
+ rte_security_oop_dynfield_register;
};
--
2.25.1
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 0/5] bbdev: API extension for 23.11
@ 2023-09-21 7:35 0% ` Maxime Coquelin
2 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2023-09-21 7:35 UTC (permalink / raw)
To: Nicolas Chautru, dev; +Cc: trix, hemant.agrawal, david.marchand, hernan.vargas
On 6/15/23 18:48, Nicolas Chautru wrote:
> v2: moving the new mld functions at the end of struct rte_bbdev to avoid
> ABI offset changes based on feedback with Maxime.
> Adding a commit to waive the FFT ABI warning since that experimental function
> could break ABI (let me know if preferred to be merged with the FFT
> commit causing the FFT change).
>
>
> Including v1 for extending the bbdev api for 23.11.
> The new MLD-TS is expected to be non ABI compatible, the other ones
> should not break ABI.
> I will send a deprecation notice in parallel.
>
> This introduces a new operation (on top of FEC and FFT) to support
> equalization for MLD-TS. There also more modular API extension for
> existing FFT and FEC operation.
>
> Thanks
> Nic
>
>
> Nicolas Chautru (5):
> bbdev: add operation type for MLDTS procession
> bbdev: add new capabilities for FFT processing
> bbdev: add new capability for FEC 5G UL processing
> bbdev: improving error handling for queue configuration
> devtools: ignore changes into bbdev experimental API
>
> devtools/libabigail.abignore | 4 +-
> doc/guides/prog_guide/bbdev.rst | 83 ++++++++++++++++++
> lib/bbdev/rte_bbdev.c | 26 +++---
> lib/bbdev/rte_bbdev.h | 76 +++++++++++++++++
> lib/bbdev/rte_bbdev_op.h | 143 +++++++++++++++++++++++++++++++-
> lib/bbdev/version.map | 5 ++
> 6 files changed, 323 insertions(+), 14 deletions(-)
>
Applied to next-baseband/for-main.
Thanks,
Maxime
^ permalink raw reply [relevance 0%]
* RE: [RFC PATCH 2/3] security: add TLS record processing
2023-09-20 11:51 0% ` Anoob Joseph
@ 2023-09-21 8:38 0% ` Van Haaren, Harry
0 siblings, 0 replies; 200+ results
From: Van Haaren, Harry @ 2023-09-21 8:38 UTC (permalink / raw)
To: Anoob Joseph
Cc: Hemant Agrawal, dev, Matz, Olivier, Vidya Sagar Velumuri,
Thomas Monjalon, Akhil Goyal, Jerin Jacob Kollanukkaran,
Konstantin Ananyev
> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Wednesday, September 20, 2023 12:52 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> <vvelumuri@marvell.com>; Thomas Monjalon <thomas@monjalon.net>; Akhil
> Goyal <gakhil@marvell.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Subject: RE: [RFC PATCH 2/3] security: add TLS record processing
>
> Hi Harry,
>
> Thanks for the review. Please see inline.
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Sent: Wednesday, September 20, 2023 2:53 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Thomas Monjalon
> > <thomas@monjalon.net>; Akhil Goyal <gakhil@marvell.com>; Jerin Jacob
> > Kollanukkaran <jerinj@marvell.com>; Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru>
> > Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> > Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> > <vvelumuri@marvell.com>
> > Subject: [EXT] RE: [RFC PATCH 2/3] security: add TLS record processing
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > > -----Original Message-----
> > > From: Anoob Joseph <anoobj@marvell.com>
> > > Sent: Friday, August 11, 2023 8:17 AM
> > > To: Thomas Monjalon <thomas@monjalon.net>; Akhil Goyal
> > > <gakhil@marvell.com>; Jerin Jacob <jerinj@marvell.com>; Konstantin
> > > Ananyev <konstantin.v.ananyev@yandex.ru>
> > > Cc: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org; Matz,
> > > Olivier <olivier.matz@6wind.com>; Vidya Sagar Velumuri
> > > <vvelumuri@marvell.com>
> > > Subject: [RFC PATCH 2/3] security: add TLS record processing
> > >
> > > Add Transport Layer Security (TLS) and Datagram Transport Layer
> > > Security (DTLS). The protocols provide communications privacy for L4
> > > protocols such as TCP & UDP.
> > >
> > > TLS (and DTLS) protocol is composed of two layers, 1. TLS Record
> > > Protocol 2. TLS Handshake Protocol
> > >
> > > While TLS Handshake Protocol helps in establishing security parameters
> > > by which client and server can communicate, TLS Record Protocol
> > > provides the connection security. TLS Record Protocol leverages
> > > symmetric cryptographic operations such as data encryption and
> > > authentication for providing security to the communications.
> > >
> > > Cryptodevs that are capable of offloading TLS Record Protocol may
> > > perform other operations like IV generation, header insertion, atomic
> > > sequence number updates and anti-replay window check in addition to
> > > cryptographic transformations.
> > >
> > > The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
> >
> > From the code below, my understanding is that *ONLY* the record layer is
> > being added/supported? The difference is described well above, but the
> > intended support added is not clearly defined.
> >
> > Suggest reword the last line to clarify:
> > "Support for TLS record protocol is added for TLS 1.2, TLS 1.3 and DTLS 1.2."
>
> [Anoob] Indeed. Will reword as suggested.
Thanks.
> > > Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > > Signed-off-by: Vidya Sagar Velumuri <vvelumuri@marvell.com>
> > > ---
> > > doc/guides/prog_guide/rte_security.rst | 58 +++++++++++++
> > > lib/security/rte_security.c | 4 +
> > > lib/security/rte_security.h | 110 +++++++++++++++++++++++++
> > > 3 files changed, 172 insertions(+)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_security.rst
> > > b/doc/guides/prog_guide/rte_security.rst
> > > index 7418e35c1b..7716d7239f 100644
> > > --- a/doc/guides/prog_guide/rte_security.rst
> > > +++ b/doc/guides/prog_guide/rte_security.rst
> > > @@ -399,6 +399,64 @@ The API ``rte_security_macsec_sc_create`` returns
> > > a handle for SC, and this handle is set in
> > > ``rte_security_macsec_xform`` to create a MACsec session using
> > > ``rte_security_session_create``.
> > >
> > > +TLS-Record Protocol
> > > +~~~~~~~~~~~~~~~~~~~
> > > +
> > > +The Transport Layer Protocol provides communications security over
> > > +the
> > > Internet. The protocol
> > > +allows client/server applications to communicate in a way that is
> > > +designed to
> > > prevent eavesdropping,
> > > +tampering, or message forgery.
> > > +
> > > +TLS protocol is composed of two layers: the TLS Record Protocol and
> > > +the TLS
> > > Handshake Protocol. At
> > > +the lowest level, layered on top of some reliable transport protocol
> > > +(e.g., TCP),
> > > is the TLS Record
> > > +Protocol. The TLS Record Protocol provides connection security that
> > > +has two
> > > basic properties:
> > > +
> > > + - The connection is private. Symmetric cryptography is used for data
> > > + encryption (e.g., AES, DES, etc.). The keys for this symmetric
> > encryption
> > > + are generated uniquely for each connection and are based on a secret
> > > + negotiated by another protocol (such as the TLS Handshake Protocol).
> > The
> > > + Record Protocol can also be used without encryption.
> > > +
> > > + - The connection is reliable. Message transport includes a message
> > > + integrity check using a keyed MAC. Secure hash functions (e.g.,
> > > + SHA-1, etc.) are used for MAC computations. The Record Protocol
> > > + can operate without a MAC, but is generally only used in this mode
> > > + while another protocol is using the Record Protocol as a transport
> > > + for negotiating security parameters.
> > > +
> > > +.. code-block:: c
> >
> > The code block below isn't C? Is there a better code block type for a text
> > diagram?
>
> [Anoob] Valid point. I was just following the general scheme followed in this file.
> May be, I'll introduce a .svg image for newly added code.
This was a nit-pick that perhaps "code-block:: text-diagram" or so exists.
No need to make a .svg in my opinion, the text-diagrams are clear.
> > > + Record Write Record Read
> > > + ------------ -----------
> > > +
> > > + TLSPlaintext TLSCiphertext
> > > + | |
> > > + ~ ~
> > > + | |
> > > + V V
> > > + +---------|----------+ +----------|---------+
> > > + | Seq. no generation | | Seq. no generation |
> > > + +---------|----------+ +----------|---------+
> > > + | |
> > > + +---------|----------+ +----------|---------+
> > > + | Header insertion | | Decryption & |
> > > + +---------|----------+ | MAC verification |
> > > + | +----------|---------+
> > > + +---------|----------+ |
> > > + | MAC generation & | +----------|---------+
> > > + | Encryption | | TLS Header removal |
> > > + +---------|----------+ +----------|---------+
> > > + | |
> > > + ~ ~
> > > + | |
> > > + V V
> > > + TLSCiphertext TLSPlaintext
> > > +
> > > +Supported Versions
> > > +^^^^^^^^^^^^^^^^^^
> > > +
> > > +* TLS 1.2
> > > +* TLS 1.3
> > > +* DTLS 1.2
> > >
> > > Device Features and Capabilities
> > > ---------------------------------
> > > diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
> > > index c4d64bb8e9..bd7b026547 100644
> > > --- a/lib/security/rte_security.c
> > > +++ b/lib/security/rte_security.c
> > > @@ -282,6 +282,10 @@ rte_security_capability_get(struct
> > > rte_security_ctx *instance,
> > > if (capability->docsis.direction ==
> > > idx->docsis.direction)
> > > return capability;
> > > + } else if (idx->protocol ==
> > > RTE_SECURITY_PROTOCOL_TLS_RECORD) {
> > > + if (capability->tls_record.ver == idx-
> > > >tls_record.ver &&
> > > + capability->tls_record.type == idx-
> > > >tls_record.type)
> > > + return capability;
> > > }
> > > }
> > > }
> > > diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> > > index 3b2df526ba..b9d064ed84 100644
> > > --- a/lib/security/rte_security.h
> > > +++ b/lib/security/rte_security.h
> > > @@ -620,6 +620,99 @@ struct rte_security_docsis_xform {
> > > /**< DOCSIS direction */
> > > };
> > >
> > > +/** Salt len to be used with AEAD algos in TLS 1.2 */ #define
> > > +RTE_SECURITY_TLS_1_2_SALT_LEN 4
> > > +/** Salt len to be used with AEAD algos in TLS 1.3 */ #define
> > > +RTE_SECURITY_TLS_1_3_SALT_LEN 12
> > > +/** Salt len to be used with AEAD algos in DTLS 1.2 */ #define
> > > +RTE_SECURITY_DTLS_1_2_SALT_LEN 4
> > > +
> > > +/** TLS version */
> > > +enum rte_security_tls_version {
> > > + RTE_SECURITY_VERSION_TLS_1_2, /**< TLS 1.2 */
> > > + RTE_SECURITY_VERSION_TLS_1_3, /**< TLS 1.3 */
> > > + RTE_SECURITY_VERSION_DTLS_1_2, /**< DTLS 1.2 */
> > > +};
> > > +
> > > +/** TLS session type */
> > > +enum rte_security_tls_sess_type {
> > > + /** Record read session
> > > + * - Decrypt & digest verification.
> > > + */
> > > + RTE_SECURITY_TLS_SESS_TYPE_READ,
> > > + /** Record write session
> > > + * - Encrypt & digest generation.
> > > + */
> > > + RTE_SECURITY_TLS_SESS_TYPE_WRITE,
> > > +};
> > > +
> > > +/**
> > > + * Configure soft and hard lifetime of a TLS record session
> > > + *
> > > + * Lifetime of a TLS record session would specify the maximum number
> > > +of
> > > packets that can be
> > > + * processed. TLS record processing operations would start failing
> > > + once hard
> > > limit is reached.
> > > + *
> > > + * Soft limits can be specified to generate notification when the TLS
> > > + record
> > > session is approaching
> > > + * hard limits for lifetime. This would result in a warning returned
> > > + in
> > > ``rte_crypto_op.aux_flags``.
> >
> > Can we define "a warning" better? Perhaps an example of a soft-limit and
> > hard-limit, what the user can check aux_flags for, to identify? Or link to the
> > appropriate part of the crypto_op.aux_flags documentation to help the user.
> >
>
> [Anoob] The concept of lifetime is present in most protocols. Idea is to limit the
> max number of operations performed with a session. Soft expiry notification is
> to help application prepare for an expiry and setup a new session before the
> current one expires.
Understood, yes.
> The idea was borrowed from IPsec which has the
> 'RTE_CRYPTO_OP_AUX_FLAGS_IPSEC_SOFT_EXPIRY' flag defined. But I realize, it
> should be better defined. I can rename the flag to
> 'RTE_CRYPTO_OP_AUX_FLAGS_SEC_SOFT_EXPIRY' to avoid redefining same flag
> for each security offload. Do you agree to this suggestion?
>
> https://elixir.bootlin.com/dpdk/latest/source/lib/cryptodev/rte_crypto.h#L67
So we cannot "just rename" the flag, its an API break. It likely is possible to add an
additional #define with the same value as IPSEC_SOFT_EXPIRY, and call it SEC_SOFT_EXPIRY.
Is that the best/most descriptive name? SYM_ALG_SOFT_EXPIRY? I'm not sure here, input welcomed.
Perhaps we can improve the doc-string there, to explain what it means a bit more verbosely.
> Do note that once hard expiry is hit, the operation would fail. Expectation is,
> cryptodev would return 'RTE_CRYPTO_OP_STATUS_ERROR' in case of errors.
That is good.
> > > + */
> > > +struct rte_security_tls_record_lifetime {
> > > + /** Soft expiry limit in number of packets */
> > > + uint64_t packets_soft_limit;
> > > + /** Hard expiry limit in number of packets */
> > > + uint64_t packets_hard_limit;
> > > +};
> > > +
> > > +/**
> > > + * TLS record protocol session configuration.
> > > + *
> > > + * This structure contains data required to create a TLS record security
> > session.
> > > + */
> > > +struct rte_security_tls_record_xform {
> > > + /** TLS record version. */
> > > + enum rte_security_tls_version ver;
> > > + /** TLS record session type. */
> > > + enum rte_security_tls_sess_type type;
> > > + /** TLS record session lifetime. */
> > > + struct rte_security_tls_record_lifetime life;
> > > + union {
> > > + /** TLS 1.2 parameters. */
> > > + struct {
> > > + /** Starting sequence number. */
> > > + uint64_t seq_no;
> > > + /** Salt to be used for AEAD algos. */
> > > + uint8_t salt[RTE_SECURITY_TLS_1_2_SALT_LEN];
> > > + } tls_1_2;
> > > +
> > > + /** TLS 1.3 parameters. */
> > > + struct {
> > > + /** Starting sequence number. */
> > > + uint64_t seq_no;
> > > + /** Salt to be used for AEAD algos. */
> > > + uint8_t salt[RTE_SECURITY_TLS_1_3_SALT_LEN];
> > > + /**
> > > + * Minimum payload length (in case of write
> > sessions).
> > > For shorter inputs,
> > > + * the payload would be padded appropriately before
> > > performing crypto
> >
> > Replace "would be" with "must be"? And who must do this step, is it the
> > application?
>
> [Anoob] Padding is performed by the PMD/cryptodev device. I'll change "would
> be" to "will be". Would that address your concern?
I suppose my concern is "is it clear to PMD authors that they must implement X in their PMD",
and to ensure we (DPDK community) do our best to clarify API demands, and to ensure future
contributions are of high quality too.
For example, could we have a security library unit-test that checks the padding case, to
ensure correct & consistent behaviour across different crypto PMDs?
Same thoughts for SOFT and HARD error variants, (although they might take... hours?) to execute.
But it is nice to automate-and-test these "corner cases".
It's not about wording, its about clarity between PMD devs, security library devs, and application facing APIs,
to ensure that DPDK provides the most/best help it can to provide correctness. Does that clarify what I'd like to see?
For this patchset, could we document a list of "caveats" when implementing PMD functionality for TLS-record security offload, and indicate that:
1) Padding must be added by the PMD based on security library flags& algo in use, not application layer (I know this is demanded by the sym algos anyway, but let's make it explicit)
2) It is strongly recommended to build unit-tests for _SOFT and _HARD error cases (potentially by "fast forwarding" the internal counters via private APIs to avoid hours of enc/decryption)
I think that limits scope-impact to this patchset, but is clear for PMD implementations in future what expectations are.
Thoughts, is that a good way forward?
> >
> > > + * transformations.
> > > + */
> > > + uint32_t min_payload_len;
> > > + } tls_1_3;
> > > +
> > > + /** DTLS 1.2 parameters */
> > > + struct {
> > > + /** Epoch value to be used. */
> > > + uint16_t epoch;
> > > + /** 6B starting sequence number to be used. */
> > > + uint64_t seq_no;
> > > + /** Salt to be used for AEAD algos. */
> > > + uint8_t salt[RTE_SECURITY_DTLS_1_2_SALT_LEN];
> > > + /** Anti replay window size to enable sequence
> > replay
> > > attack handling.
> > > + * Anti replay check is disabled if the window size is 0.
> > > + */
> > > + uint32_t ar_win_sz;
> > > + } dtls_1_2;
> > > + };
> > > +};
> > > +
> > > /**
> > > * Security session action type.
> > > */
> > > @@ -654,6 +747,8 @@ enum rte_security_session_protocol {
> > > /**< PDCP Protocol */
> > > RTE_SECURITY_PROTOCOL_DOCSIS,
> > > /**< DOCSIS Protocol */
> > > + RTE_SECURITY_PROTOCOL_TLS_RECORD,
> > > + /**< TLS Record Protocol */
> > > };
> > >
> > > /**
> > > @@ -670,6 +765,7 @@ struct rte_security_session_conf {
> > > struct rte_security_macsec_xform macsec;
> > > struct rte_security_pdcp_xform pdcp;
> > > struct rte_security_docsis_xform docsis;
> > > + struct rte_security_tls_record_xform tls;
> >
> > Do we see TLS handshake xform being added in future? If so, is 'tls' a good
> > name, perhaps 'tls_record'?
> > That would allow 'tls_handshake' in future, with consistent naming scheme
> > without API/ABI break.
>
> [Anoob] In the future, I would like to see TLS handshake also offloaded in a
> similar manner. But that would need some fundamental changes in security
> library. Like, current security library is pretty much tied to symmetric
> operations but a handshake would involve both symmetric & asymmetric
> operations.
>
> Said that, I agree with your suggestion to rename the field. Will change it to
> 'tls_record' in next version.
Agreed, that handshake is significantly more complex, thanks for rename to "tls_record".
>
> >
> >
> > > };
> > > /**< Configuration parameters for security session */
> > > struct rte_crypto_sym_xform *crypto_xform; @@ -1190,6 +1286,16
> > @@
> > > struct rte_security_capability {
> > > /**< DOCSIS direction */
> > > } docsis;
> > > /**< DOCSIS capability */
> > > + struct {
> > > + enum rte_security_tls_version ver;
> > > + /**< TLS record version. */
> > > + enum rte_security_tls_sess_type type;
> > > + /**< TLS record session type. */
> > > + uint32_t ar_win_size;
> > > + /**< Maximum anti replay window size supported
> > for
> > > DTLS 1.2 record read
> > > + * operation. Value of 0 means anti replay check is
> > not
> > > supported.
> > > + */
> > > + } tls_record;
> >
> > Missing /**< TLS Record Capability */ docstring here.
>
> [Anoob] Agreed. Will add in next version.
Thanks!
<snip>
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-20 7:34 0% ` David Marchand
@ 2023-09-21 13:18 4% ` Tummala, Sivaprasad
2023-09-21 14:49 4% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: Tummala, Sivaprasad @ 2023-09-21 13:18 UTC (permalink / raw)
To: David Marchand, Stanisław Kardach
Cc: Ruifeng Wang, Min Zhou, David Christensen, Bruce Richardson,
Konstantin Ananyev, dev, Yigit, Ferruh, Thomas Monjalon
[AMD Official Use Only - General]
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Wednesday, September 20, 2023 1:05 PM
> To: Stanisław Kardach <kda@semihalf.com>; Tummala, Sivaprasad
> <Sivaprasad.Tummala@amd.com>
> Cc: Ruifeng Wang <ruifeng.wang@arm.com>; Min Zhou <zhoumin@loongson.cn>;
> David Christensen <drc@linux.vnet.ibm.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>; dev <dev@dpdk.org>; Yigit, Ferruh
> <Ferruh.Yigit@amd.com>; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach <kda@semihalf.com> wrote:
> >
> > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> <david.marchand@redhat.com> wrote:
> > <snip>
> > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS (what I call a
> last element canary). Why? If you're concerned with ABI, then we're talking about
> an application linking dynamically with DPDK or talking via some RPC channel with
> another DPDK application. So clashing with this definition does not come into
> question. One should rather use rte_cpu_get_flag_enabled().
> > > > Also if you want to introduce new features, one would add them yo the
> rte_cpuflags headers, unless you'd like to not add those and keep an
> undocumented list "above" the last defined element.
> > > > Could you explain a bit more Your use-case?
> > >
> > > Hey Stanislaw,
> > >
> > > Talking generically, one problem with such pattern (having a LAST,
> > > or MAX enum) is when an array sized with such a symbol is exposed.
> > > As I mentionned in the past, this can have unwanted effects:
> > > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > > -1-david.marchand@redhat.com/
>
> Argh... who broke copy/paste in my browser ?!
> Wrt to MAX and arrays, I wanted to point at:
> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR
> TsUw@mail.gmail.com/
>
> > I agree, though I'd argue "LAST" and "MAX" semantics are a bit different. "LAST"
> delimits the known enumeration territory while "MAX" is more of a `constepxr`
> value type.
> > >
> > > Another issue is when an existing enum meaning changes: from the
> > > application pov, the (old) MAX value is incorrect, but for the
> > > library pov, a new meaning has been associated.
> > > This may trigger bugs in the application when calling a function
> > > that returns such an enum which never return this MAX value in the past.
> > >
> > > For at least those two reasons, removing those canary elements is
> > > being done in DPDK.
> > >
> > > This specific removal has been announced:
> > > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > > -1-david.marchand@redhat.com/
> > Thanks for pointing this out but did you mean to link to the patch again here?
>
> Sorry, same here, bad copy/paste :-(.
>
> The intended link is: https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> The deprecation notice was badly formulated and this patch here is consistent with
> it.
>
>
> > >
> > > Now, practically, when I look at the cpuflags API, I don't see us
> > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this change
> > > is unneeded.
> > > But on the other hand, is it really an issue for an application to
> > > lose this (internal) information?
> > I doubt it, maybe it could be used as a sanity check for choosing proper functors
> in the application. Though the initial description of the reason behind this patch was
> to not break the ABI and I don't think it does that. What it does is enforces users to
> use explicit cpu flag values which is a good thing. Though if so, then it should be
> stated in the commit description.
>
> I agree.
> Siva, can you work on a new revision?
>
David, Stanislaw,
The original motivation of this patch was to avoid ABI breakage with the introduction of new CPU flag
"RTE_CPUFLAG_MONITORX" (http://mails.dpdk.org/archives/test-report/2023-April/382489.html).
Because of ABI breakage, the feature was postponed to this release.
https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/
Can you please add what exactly needs to be reworked in the new version.
>
> Thanks.
>
> --
> David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-21 13:18 4% ` Tummala, Sivaprasad
@ 2023-09-21 14:49 4% ` Stanisław Kardach
2023-09-27 11:55 5% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Stanisław Kardach @ 2023-09-21 14:49 UTC (permalink / raw)
To: Tummala, Sivaprasad
Cc: David Marchand, Ruifeng Wang, Min Zhou, David Christensen,
Bruce Richardson, Konstantin Ananyev, dev, Yigit, Ferruh,
Thomas Monjalon
[-- Attachment #1: Type: text/plain, Size: 5540 bytes --]
On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
wrote:
> [AMD Official Use Only - General]
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Wednesday, September 20, 2023 1:05 PM
> > To: Stanisław Kardach <kda@semihalf.com>; Tummala, Sivaprasad
> > <Sivaprasad.Tummala@amd.com>
> > Cc: Ruifeng Wang <ruifeng.wang@arm.com>; Min Zhou <zhoumin@loongson.cn>;
> > David Christensen <drc@linux.vnet.ibm.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru>; dev <dev@dpdk.org>; Yigit, Ferruh
> > <Ferruh.Yigit@amd.com>; Thomas Monjalon <thomas@monjalon.net>
> > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
> >
> > Caution: This message originated from an External Source. Use proper
> caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach <kda@semihalf.com>
> wrote:
> > >
> > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> > > <snip>
> > > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS (what I
> call a
> > last element canary). Why? If you're concerned with ABI, then we're
> talking about
> > an application linking dynamically with DPDK or talking via some RPC
> channel with
> > another DPDK application. So clashing with this definition does not come
> into
> > question. One should rather use rte_cpu_get_flag_enabled().
> > > > > Also if you want to introduce new features, one would add them yo
> the
> > rte_cpuflags headers, unless you'd like to not add those and keep an
> > undocumented list "above" the last defined element.
> > > > > Could you explain a bit more Your use-case?
> > > >
> > > > Hey Stanislaw,
> > > >
> > > > Talking generically, one problem with such pattern (having a LAST,
> > > > or MAX enum) is when an array sized with such a symbol is exposed.
> > > > As I mentionned in the past, this can have unwanted effects:
> > > > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > > > -1-david.marchand@redhat.com/
> >
> > Argh... who broke copy/paste in my browser ?!
> > Wrt to MAX and arrays, I wanted to point at:
> >
> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR
> > TsUw@mail.gmail.com/
> >
> > > I agree, though I'd argue "LAST" and "MAX" semantics are a bit
> different. "LAST"
> > delimits the known enumeration territory while "MAX" is more of a
> `constepxr`
> > value type.
> > > >
> > > > Another issue is when an existing enum meaning changes: from the
> > > > application pov, the (old) MAX value is incorrect, but for the
> > > > library pov, a new meaning has been associated.
> > > > This may trigger bugs in the application when calling a function
> > > > that returns such an enum which never return this MAX value in the
> past.
> > > >
> > > > For at least those two reasons, removing those canary elements is
> > > > being done in DPDK.
> > > >
> > > > This specific removal has been announced:
> > > > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > > > -1-david.marchand@redhat.com/
> > > Thanks for pointing this out but did you mean to link to the patch
> again here?
> >
> > Sorry, same here, bad copy/paste :-(.
> >
> > The intended link is: https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> > The deprecation notice was badly formulated and this patch here is
> consistent with
> > it.
> >
> >
> > > >
> > > > Now, practically, when I look at the cpuflags API, I don't see us
> > > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this change
> > > > is unneeded.
> > > > But on the other hand, is it really an issue for an application to
> > > > lose this (internal) information?
> > > I doubt it, maybe it could be used as a sanity check for choosing
> proper functors
> > in the application. Though the initial description of the reason behind
> this patch was
> > to not break the ABI and I don't think it does that. What it does is
> enforces users to
> > use explicit cpu flag values which is a good thing. Though if so, then
> it should be
> > stated in the commit description.
> >
> > I agree.
> > Siva, can you work on a new revision?
> >
> David, Stanislaw,
>
> The original motivation of this patch was to avoid ABI breakage with the
> introduction of new CPU flag
> "RTE_CPUFLAG_MONITORX" (
> http://mails.dpdk.org/archives/test-report/2023-April/382489.html).
>
> Because of ABI breakage, the feature was postponed to this release.
>
> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/
This test is flawed, reason being that the NUMFLAGS should not be treated
as a flag value and instead as a canary but this test is not taking into
account.
Your change did not break the ABI because you have properly added the new
flag at the end.
So I would ask to change the commit description to mention that NUMFLAGS is
removed to:
1. Prevent users from treating it as a usable value or an array size.
2. Prevent false-positive failures in the ABI test.
Also it would be good to link to the aforementioned ABI test failure to
give readers some context when inspecting the git tree.
>
>
> Can you please add what exactly needs to be reworked in the new version.
>
> >
> > Thanks.
> >
> > --
> > David Marchand
>
>
[-- Attachment #2: Type: text/html, Size: 8942 bytes --]
^ permalink raw reply [relevance 4%]
* Re: [PATCH] ethdev: validate reserved fields
@ 2023-09-21 15:12 0% ` Ferruh Yigit
2023-09-21 16:33 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-21 15:12 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev, thomas, Andrew Rybchenko
On 5/26/2023 9:15 AM, Bruce Richardson wrote:
> On Thu, May 25, 2023 at 01:39:42PM -0700, Stephen Hemminger wrote:
>> The various reserved fields added to ethdev could not be
>> safely used for future extensions because they were never
>> checked on input. Therefore ABI would be broken if these
>> fields were added in a future DPDK release.
>>
>> Fixes: 436b3a6b6e62 ("ethdev: reserve space in main structs for extension")
>> Cc: thomas@monjalon.net
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> ---
>> lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
Applied to dpdk-next-net/main, thanks.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] ethdev: validate reserved fields
2023-09-21 15:12 0% ` Ferruh Yigit
@ 2023-09-21 16:33 0% ` Ferruh Yigit
2023-09-22 15:23 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-21 16:33 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev, thomas, Andrew Rybchenko
On 9/21/2023 4:12 PM, Ferruh Yigit wrote:
> On 5/26/2023 9:15 AM, Bruce Richardson wrote:
>> On Thu, May 25, 2023 at 01:39:42PM -0700, Stephen Hemminger wrote:
>>> The various reserved fields added to ethdev could not be
>>> safely used for future extensions because they were never
>>> checked on input. Therefore ABI would be broken if these
>>> fields were added in a future DPDK release.
>>>
>>> Fixes: 436b3a6b6e62 ("ethdev: reserve space in main structs for extension")
>>> Cc: thomas@monjalon.net
>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>> ---
>>> lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 41 insertions(+)
>>>
>> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
>
> Applied to dpdk-next-net/main, thanks.
>
some unit tests are failing with this patch, both iol and github actions
reports it, need to investigate the root cause.
Based on findings, we may need to drop the patch from next-net, fyi.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] ethdev: validate reserved fields
2023-09-21 16:33 0% ` Ferruh Yigit
@ 2023-09-22 15:23 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-09-22 15:23 UTC (permalink / raw)
To: Bruce Richardson, Stephen Hemminger; +Cc: dev, thomas, Andrew Rybchenko
On 9/21/2023 5:33 PM, Ferruh Yigit wrote:
> On 9/21/2023 4:12 PM, Ferruh Yigit wrote:
>> On 5/26/2023 9:15 AM, Bruce Richardson wrote:
>>> On Thu, May 25, 2023 at 01:39:42PM -0700, Stephen Hemminger wrote:
>>>> The various reserved fields added to ethdev could not be
>>>> safely used for future extensions because they were never
>>>> checked on input. Therefore ABI would be broken if these
>>>> fields were added in a future DPDK release.
>>>>
>>>> Fixes: 436b3a6b6e62 ("ethdev: reserve space in main structs for extension")
>>>> Cc: thomas@monjalon.net
>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>> ---
>>>> lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 41 insertions(+)
>>>>
>>> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>>>
>>
>> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
>>
>> Applied to dpdk-next-net/main, thanks.
>>
>
> some unit tests are failing with this patch, both iol and github actions
> reports it, need to investigate the root cause.
>
> Based on findings, we may need to drop the patch from next-net, fyi.
>
Unit test failures caused by segfault, because in
'rte_eth_rx_queue_setup()' & 'rte_eth_tx_queue_setup()' accepts
'rx_conf' & 'tx_conf' to be NULL, but checks doesn't take this into account.
Adding "rx_conf != NULL && (..)" check for Rx, and similar for Tx.
I will update in next-net, and force push.
^ permalink raw reply [relevance 0%]
* [PATCH v13 1/4] ethdev: add API for mbufs recycle mode
@ 2023-09-25 3:19 3% ` Feifei Wang
0 siblings, 0 replies; 200+ results
From: Feifei Wang @ 2023-09-25 3:19 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko
Cc: dev, nd, Feifei Wang, Honnappa Nagarahalli, Ruifeng Wang,
Morten Brørup, Konstantin Ananyev
Add 'rte_eth_recycle_rx_queue_info_get' and 'rte_eth_recycle_mbufs'
APIs to recycle used mbufs from a transmit queue of an Ethernet device,
and move these mbufs into a mbuf ring for a receive queue of an Ethernet
device. This can bypass mempool 'put/get' operations hence saving CPU
cycles.
For each recycling mbufs, the rte_eth_recycle_mbufs() function performs
the following operations:
- Copy used *rte_mbuf* buffer pointers from Tx mbuf ring into Rx mbuf
ring.
- Replenish the Rx descriptors with the recycling *rte_mbuf* mbufs freed
from the Tx mbuf ring.
Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Suggested-by: Ruifeng Wang <ruifeng.wang@arm.com>
Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
doc/guides/rel_notes/release_23_11.rst | 15 +++
lib/ethdev/ethdev_driver.h | 10 ++
lib/ethdev/ethdev_private.c | 2 +
lib/ethdev/rte_ethdev.c | 22 +++
lib/ethdev/rte_ethdev.h | 180 +++++++++++++++++++++++++
lib/ethdev/rte_ethdev_core.h | 23 +++-
lib/ethdev/version.map | 3 +
7 files changed, 249 insertions(+), 6 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 9746809a66..3c2bed73aa 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -78,6 +78,13 @@ New Features
* build: Optional libraries can now be selected with the new ``enable_libs``
build option similarly to the existing ``enable_drivers`` build option.
+* **Add mbufs recycling support.**
+
+ Added ``rte_eth_recycle_rx_queue_info_get`` and ``rte_eth_recycle_mbufs``
+ APIs which allow the user to copy used mbufs from the Tx mbuf ring
+ into the Rx mbuf ring. This feature supports the case that the Rx Ethernet
+ device is different from the Tx Ethernet device with respective driver
+ callback functions in ``rte_eth_recycle_mbufs``.
Removed Items
-------------
@@ -135,6 +142,14 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: Added ``recycle_tx_mbufs_reuse`` and ``recycle_rx_descriptors_refill``
+ fields to ``rte_eth_dev`` structure.
+
+* ethdev: Structure ``rte_eth_fp_ops`` was affected to add
+ ``recycle_tx_mbufs_reuse`` and ``recycle_rx_descriptors_refill``
+ fields, to move ``rxq`` and ``txq`` fields, to change the size of
+ ``reserved1`` and ``reserved2`` fields.
+
Known Issues
------------
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 3fa8b309c1..deb23ada18 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -60,6 +60,10 @@ struct rte_eth_dev {
eth_rx_descriptor_status_t rx_descriptor_status;
/** Check the status of a Tx descriptor */
eth_tx_descriptor_status_t tx_descriptor_status;
+ /** Pointer to PMD transmit mbufs reuse function */
+ eth_recycle_tx_mbufs_reuse_t recycle_tx_mbufs_reuse;
+ /** Pointer to PMD receive descriptors refill function */
+ eth_recycle_rx_descriptors_refill_t recycle_rx_descriptors_refill;
/**
* Device data that is shared between primary and secondary processes
@@ -509,6 +513,10 @@ typedef void (*eth_rxq_info_get_t)(struct rte_eth_dev *dev,
typedef void (*eth_txq_info_get_t)(struct rte_eth_dev *dev,
uint16_t tx_queue_id, struct rte_eth_txq_info *qinfo);
+typedef void (*eth_recycle_rxq_info_get_t)(struct rte_eth_dev *dev,
+ uint16_t rx_queue_id,
+ struct rte_eth_recycle_rxq_info *recycle_rxq_info);
+
typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
uint16_t queue_id, struct rte_eth_burst_mode *mode);
@@ -1252,6 +1260,8 @@ struct eth_dev_ops {
eth_rxq_info_get_t rxq_info_get;
/** Retrieve Tx queue information */
eth_txq_info_get_t txq_info_get;
+ /** Retrieve mbufs recycle Rx queue information */
+ eth_recycle_rxq_info_get_t recycle_rxq_info_get;
eth_burst_mode_get_t rx_burst_mode_get; /**< Get Rx burst mode */
eth_burst_mode_get_t tx_burst_mode_get; /**< Get Tx burst mode */
eth_fw_version_get_t fw_version_get; /**< Get firmware version */
diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
index 14ec8c6ccf..f8ab64f195 100644
--- a/lib/ethdev/ethdev_private.c
+++ b/lib/ethdev/ethdev_private.c
@@ -277,6 +277,8 @@ eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
fpo->rx_queue_count = dev->rx_queue_count;
fpo->rx_descriptor_status = dev->rx_descriptor_status;
fpo->tx_descriptor_status = dev->tx_descriptor_status;
+ fpo->recycle_tx_mbufs_reuse = dev->recycle_tx_mbufs_reuse;
+ fpo->recycle_rx_descriptors_refill = dev->recycle_rx_descriptors_refill;
fpo->rxq.data = dev->data->rx_queues;
fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 46eaed6467..92d7fc41a1 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -5876,6 +5876,28 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
return 0;
}
+int
+rte_eth_recycle_rx_queue_info_get(uint16_t port_id, uint16_t queue_id,
+ struct rte_eth_recycle_rxq_info *recycle_rxq_info)
+{
+ struct rte_eth_dev *dev;
+ int ret;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ ret = eth_dev_validate_rx_queue(dev, queue_id);
+ if (unlikely(ret != 0))
+ return ret;
+
+ if (*dev->dev_ops->recycle_rxq_info_get == NULL)
+ return -ENOTSUP;
+
+ dev->dev_ops->recycle_rxq_info_get(dev, queue_id, recycle_rxq_info);
+
+ return 0;
+}
+
int
rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
struct rte_eth_burst_mode *mode)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 04a2564f22..9ea639852d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1820,6 +1820,30 @@ struct rte_eth_txq_info {
uint8_t queue_state; /**< one of RTE_ETH_QUEUE_STATE_*. */
} __rte_cache_min_aligned;
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice.
+ *
+ * Ethernet device Rx queue information structure for recycling mbufs.
+ * Used to retrieve Rx queue information when Tx queue reusing mbufs and moving
+ * them into Rx mbuf ring.
+ */
+struct rte_eth_recycle_rxq_info {
+ struct rte_mbuf **mbuf_ring; /**< mbuf ring of Rx queue. */
+ struct rte_mempool *mp; /**< mempool of Rx queue. */
+ uint16_t *refill_head; /**< head of Rx queue refilling mbufs. */
+ uint16_t *receive_tail; /**< tail of Rx queue receiving pkts. */
+ uint16_t mbuf_ring_size; /**< configured number of mbuf ring size. */
+ /**
+ * Requirement on mbuf refilling batch size of Rx mbuf ring.
+ * For some PMD drivers, the number of Rx mbuf ring refilling mbufs
+ * should be aligned with mbuf ring size, in order to simplify
+ * ring wrapping around.
+ * Value 0 means that PMD drivers have no requirement for this.
+ */
+ uint16_t refill_requirement;
+} __rte_cache_min_aligned;
+
/* Generic Burst mode flag definition, values can be ORed. */
/**
@@ -4853,6 +4877,31 @@ int rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id,
int rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
struct rte_eth_txq_info *qinfo);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Retrieve information about given ports's Rx queue for recycling mbufs.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The Rx queue on the Ethernet devicefor which information
+ * will be retrieved.
+ * @param recycle_rxq_info
+ * A pointer to a structure of type *rte_eth_recycle_rxq_info* to be filled.
+ *
+ * @return
+ * - 0: Success
+ * - -ENODEV: If *port_id* is invalid.
+ * - -ENOTSUP: routine is not supported by the device PMD.
+ * - -EINVAL: The queue_id is out of range.
+ */
+__rte_experimental
+int rte_eth_recycle_rx_queue_info_get(uint16_t port_id,
+ uint16_t queue_id,
+ struct rte_eth_recycle_rxq_info *recycle_rxq_info);
+
/**
* Retrieve information about the Rx packet burst mode.
*
@@ -6527,6 +6576,137 @@ rte_eth_tx_buffer(uint16_t port_id, uint16_t queue_id,
return rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
}
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ * Recycle used mbufs from a transmit queue of an Ethernet device, and move
+ * these mbufs into a mbuf ring for a receive queue of an Ethernet device.
+ * This can bypass mempool path to save CPU cycles.
+ *
+ * The rte_eth_recycle_mbufs() function loops, with rte_eth_rx_burst() and
+ * rte_eth_tx_burst() functions, freeing Tx used mbufs and replenishing Rx
+ * descriptors. The number of recycling mbufs depends on the request of Rx mbuf
+ * ring, with the constraint of enough used mbufs from Tx mbuf ring.
+ *
+ * For each recycling mbufs, the rte_eth_recycle_mbufs() function performs the
+ * following operations:
+ *
+ * - Copy used *rte_mbuf* buffer pointers from Tx mbuf ring into Rx mbuf ring.
+ *
+ * - Replenish the Rx descriptors with the recycling *rte_mbuf* mbufs freed
+ * from the Tx mbuf ring.
+ *
+ * This function spilts Rx and Tx path with different callback functions. The
+ * callback function recycle_tx_mbufs_reuse is for Tx driver. The callback
+ * function recycle_rx_descriptors_refill is for Rx driver. rte_eth_recycle_mbufs()
+ * can support the case that Rx Ethernet device is different from Tx Ethernet device.
+ *
+ * It is the responsibility of users to select the Rx/Tx queue pair to recycle
+ * mbufs. Before call this function, users must call rte_eth_recycle_rxq_info_get
+ * function to retrieve selected Rx queue information.
+ * @see rte_eth_recycle_rxq_info_get, struct rte_eth_recycle_rxq_info
+ *
+ * Currently, the rte_eth_recycle_mbufs() function can support to feed 1 Rx queue from
+ * 2 Tx queues in the same thread. Do not pair the Rx queue and Tx queue in different
+ * threads, in order to avoid memory error rewriting.
+ *
+ * @param rx_port_id
+ * Port identifying the receive side.
+ * @param rx_queue_id
+ * The index of the receive queue identifying the receive side.
+ * The value must be in the range [0, nb_rx_queue - 1] previously supplied
+ * to rte_eth_dev_configure().
+ * @param tx_port_id
+ * Port identifying the transmit side.
+ * @param tx_queue_id
+ * The index of the transmit queue identifying the transmit side.
+ * The value must be in the range [0, nb_tx_queue - 1] previously supplied
+ * to rte_eth_dev_configure().
+ * @param recycle_rxq_info
+ * A pointer to a structure of type *rte_eth_recycle_rxq_info* which contains
+ * the information of the Rx queue mbuf ring.
+ * @return
+ * The number of recycling mbufs.
+ */
+__rte_experimental
+static inline uint16_t
+rte_eth_recycle_mbufs(uint16_t rx_port_id, uint16_t rx_queue_id,
+ uint16_t tx_port_id, uint16_t tx_queue_id,
+ struct rte_eth_recycle_rxq_info *recycle_rxq_info)
+{
+ struct rte_eth_fp_ops *p1, *p2;
+ void *qd1, *qd2;
+ uint16_t nb_mbufs;
+
+#ifdef RTE_ETHDEV_DEBUG_TX
+ if (tx_port_id >= RTE_MAX_ETHPORTS ||
+ tx_queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid tx_port_id=%u or tx_queue_id=%u\n",
+ tx_port_id, tx_queue_id);
+ return 0;
+ }
+#endif
+
+ /* fetch pointer to Tx queue data */
+ p1 = &rte_eth_fp_ops[tx_port_id];
+ qd1 = p1->txq.data[tx_queue_id];
+
+#ifdef RTE_ETHDEV_DEBUG_TX
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(tx_port_id, 0);
+
+ if (qd1 == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid Tx queue_id=%u for port_id=%u\n",
+ tx_queue_id, tx_port_id);
+ return 0;
+ }
+#endif
+ if (p1->recycle_tx_mbufs_reuse == NULL)
+ return 0;
+
+#ifdef RTE_ETHDEV_DEBUG_RX
+ if (rx_port_id >= RTE_MAX_ETHPORTS ||
+ rx_queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR, "Invalid rx_port_id=%u or rx_queue_id=%u\n",
+ rx_port_id, rx_queue_id);
+ return 0;
+ }
+#endif
+
+ /* fetch pointer to Rx queue data */
+ p2 = &rte_eth_fp_ops[rx_port_id];
+ qd2 = p2->rxq.data[rx_queue_id];
+
+#ifdef RTE_ETHDEV_DEBUG_RX
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(rx_port_id, 0);
+
+ if (qd2 == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid Rx queue_id=%u for port_id=%u\n",
+ rx_queue_id, rx_port_id);
+ return 0;
+ }
+#endif
+ if (p2->recycle_rx_descriptors_refill == NULL)
+ return 0;
+
+ /* Copy used *rte_mbuf* buffer pointers from Tx mbuf ring
+ * into Rx mbuf ring.
+ */
+ nb_mbufs = p1->recycle_tx_mbufs_reuse(qd1, recycle_rxq_info);
+
+ /* If no recycling mbufs, return 0. */
+ if (nb_mbufs == 0)
+ return 0;
+
+ /* Replenish the Rx descriptors with the recycling
+ * into Rx mbuf ring.
+ */
+ p2->recycle_rx_descriptors_refill(qd2, nb_mbufs);
+
+ return nb_mbufs;
+}
+
/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index 8d260584b4..32f5f7376a 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -53,6 +53,13 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
/** @internal Check the status of a Tx descriptor */
typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
+/** @internal Copy used mbufs from Tx mbuf ring into Rx mbuf ring */
+typedef uint16_t (*eth_recycle_tx_mbufs_reuse_t)(void *txq,
+ struct rte_eth_recycle_rxq_info *recycle_rxq_info);
+
+/** @internal Refill Rx descriptors with the recycling mbufs */
+typedef void (*eth_recycle_rx_descriptors_refill_t)(void *rxq, uint16_t nb);
+
/**
* @internal
* Structure used to hold opaque pointers to internal ethdev Rx/Tx
@@ -81,15 +88,17 @@ struct rte_eth_fp_ops {
* Rx fast-path functions and related data.
* 64-bit systems: occupies first 64B line
*/
+ /** Rx queues data. */
+ struct rte_ethdev_qdata rxq;
/** PMD receive function. */
eth_rx_burst_t rx_pkt_burst;
/** Get the number of used Rx descriptors. */
eth_rx_queue_count_t rx_queue_count;
/** Check the status of a Rx descriptor. */
eth_rx_descriptor_status_t rx_descriptor_status;
- /** Rx queues data. */
- struct rte_ethdev_qdata rxq;
- uintptr_t reserved1[3];
+ /** Refill Rx descriptors with the recycling mbufs. */
+ eth_recycle_rx_descriptors_refill_t recycle_rx_descriptors_refill;
+ uintptr_t reserved1[2];
/**@}*/
/**@{*/
@@ -97,15 +106,17 @@ struct rte_eth_fp_ops {
* Tx fast-path functions and related data.
* 64-bit systems: occupies second 64B line
*/
+ /** Tx queues data. */
+ struct rte_ethdev_qdata txq;
/** PMD transmit function. */
eth_tx_burst_t tx_pkt_burst;
/** PMD transmit prepare function. */
eth_tx_prep_t tx_pkt_prepare;
/** Check the status of a Tx descriptor. */
eth_tx_descriptor_status_t tx_descriptor_status;
- /** Tx queues data. */
- struct rte_ethdev_qdata txq;
- uintptr_t reserved2[3];
+ /** Copy used mbufs from Tx mbuf ring into Rx. */
+ eth_recycle_tx_mbufs_reuse_t recycle_tx_mbufs_reuse;
+ uintptr_t reserved2[2];
/**@}*/
} __rte_cache_aligned;
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index b965d6aa52..eec159dfdd 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -312,6 +312,9 @@ EXPERIMENTAL {
rte_flow_async_action_list_handle_query_update;
rte_flow_async_actions_update;
rte_flow_restore_info_dynflag;
+
+ # added in 23.11
+ rte_eth_recycle_rx_queue_info_get;
};
INTERNAL {
--
2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v3] security: hide security context
@ 2023-09-26 7:19 2% ` Akhil Goyal
2023-09-26 8:08 1% ` [PATCH v4] " Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-09-26 7:19 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, fanzhang.oss, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.v.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
rte_security_ctx is used by all security APIs to identify
which device security_op it need to call and hence it should
be opaque to the application.
Hence, it is now moved to internal header file and all
APIs will now take an opaque pointer for it.
The fast path inline APIs like set metadata need to get flags
from security_ctx. The flags are now retrieved using inline APIs
which use macros to get the offset of flags in security_ctx.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Ciara Power <ciara.power@intel.com>
---
Changes in v3: Updated release notes and removed deprecation notice.
Changes in v2: Rebased.
app/test-crypto-perf/cperf_ops.c | 9 +--
app/test-crypto-perf/cperf_test_latency.c | 3 +-
.../cperf_test_pmd_cyclecount.c | 8 +-
app/test-crypto-perf/cperf_test_throughput.c | 9 +--
app/test-crypto-perf/cperf_test_verify.c | 4 +-
app/test-security-perf/test_security_perf.c | 2 +-
app/test/test_cryptodev.c | 22 ++----
app/test/test_cryptodev_security_ipsec.c | 2 +-
app/test/test_cryptodev_security_ipsec.h | 2 +-
app/test/test_security_inline_macsec.c | 10 +--
app/test/test_security_inline_proto.c | 14 ++--
doc/guides/rel_notes/deprecation.rst | 3 -
doc/guides/rel_notes/release_23_11.rst | 3 +
examples/ipsec-secgw/ipsec-secgw.c | 2 +-
examples/ipsec-secgw/ipsec.c | 15 ++--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/ipsec_worker.c | 2 +-
examples/ipsec-secgw/ipsec_worker.h | 4 +-
lib/security/rte_security.c | 61 +++++++++------
lib/security/rte_security.h | 77 +++++++++----------
lib/security/rte_security_driver.h | 24 ++++++
21 files changed, 143 insertions(+), 135 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 93b9bfb240..84945d1313 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -749,8 +749,7 @@ create_ipsec_session(struct rte_mempool *sess_mp,
else
sess_conf.ipsec.direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
@@ -853,8 +852,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
.crypto_xform = &cipher_xform
};
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
@@ -901,8 +899,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
} },
.crypto_xform = &cipher_xform
};
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
diff --git a/app/test-crypto-perf/cperf_test_latency.c b/app/test-crypto-perf/cperf_test_latency.c
index f1676a9aa9..484bc9eb4e 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -53,8 +53,7 @@ cperf_latency_test_free(struct cperf_latency_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
rte_security_session_destroy(sec_ctx, ctx->sess);
}
#endif
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index 0307e82996..4a60f6d558 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -67,11 +67,9 @@ cperf_pmd_cyclecount_test_free(struct cperf_pmd_cyclecount_ctx *ctx)
#ifdef RTE_LIB_SECURITY
if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS) {
- struct rte_security_ctx *sec_ctx =
- (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
- rte_security_session_destroy(sec_ctx,
- (void *)ctx->sess);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
+ rte_security_session_destroy(sec_ctx, (void *)ctx->sess);
} else
#endif
rte_cryptodev_sym_session_free(ctx->dev_id, ctx->sess);
diff --git a/app/test-crypto-perf/cperf_test_throughput.c b/app/test-crypto-perf/cperf_test_throughput.c
index e892a70699..f8f8bd717f 100644
--- a/app/test-crypto-perf/cperf_test_throughput.c
+++ b/app/test-crypto-perf/cperf_test_throughput.c
@@ -44,12 +44,9 @@ cperf_throughput_test_free(struct cperf_throughput_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
- rte_security_session_destroy(
- sec_ctx,
- (void *)ctx->sess);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
+ rte_security_session_destroy(sec_ctx, (void *)ctx->sess);
}
#endif
else
diff --git a/app/test-crypto-perf/cperf_test_verify.c b/app/test-crypto-perf/cperf_test_verify.c
index 8042c94e04..a6c0ffe813 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -48,8 +48,8 @@ cperf_verify_test_free(struct cperf_verify_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
rte_security_session_destroy(sec_ctx, ctx->sess);
}
#endif
diff --git a/app/test-security-perf/test_security_perf.c b/app/test-security-perf/test_security_perf.c
index 9bb50689e3..4dfaca4800 100644
--- a/app/test-security-perf/test_security_perf.c
+++ b/app/test-security-perf/test_security_perf.c
@@ -344,7 +344,7 @@ test_security_session_perf(void *arg)
struct rte_security_session_conf sess_conf;
int i, ret, nb_sessions, nb_sess_total;
struct rte_security_session **sess;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
double setup_rate, destroy_rate;
uint64_t setup_ms, destroy_ms;
struct lcore_conf *conf = arg;
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 3a51a5d00f..fcac108511 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -8931,9 +8931,7 @@ security_proto_supported(enum rte_security_session_action_type action,
const struct rte_security_capability *capability;
uint16_t i = 0;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
capabilities = rte_security_capabilities_get(ctx);
@@ -8973,9 +8971,7 @@ static int test_pdcp_proto(int i, int oop, enum rte_crypto_cipher_operation opc,
struct crypto_unittest_params *ut_params = &unittest_params;
uint8_t *plaintext;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
struct rte_cryptodev_info dev_info;
uint64_t feat_flags;
@@ -9180,9 +9176,7 @@ test_pdcp_proto_SGL(int i, int oop,
unsigned int trn_data = 0;
struct rte_cryptodev_info dev_info;
uint64_t feat_flags;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
struct rte_mbuf *temp_mbuf;
rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
@@ -9905,7 +9899,7 @@ test_ipsec_proto_process(const struct ipsec_test_data td[],
struct ipsec_test_data *res_d_tmp = NULL;
uint8_t input_text[IPSEC_TEXT_MAX_LEN];
int salt_len, i, ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx;
+ void *ctx;
uint32_t src, dst;
uint32_t verify;
@@ -11088,9 +11082,7 @@ test_docsis_proto_uplink(const void *data)
uint32_t crc_data_len;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
/* Verify the capabilities */
struct rte_security_capability_idx sec_cap_idx;
@@ -11272,9 +11264,7 @@ test_docsis_proto_downlink(const void *data)
int32_t cipher_len, crc_len;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
/* Verify the capabilities */
struct rte_security_capability_idx sec_cap_idx;
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index be9e246bfe..205714b270 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -1249,7 +1249,7 @@ test_ipsec_status_check(const struct ipsec_test_data *td,
}
int
-test_ipsec_stats_verify(struct rte_security_ctx *ctx,
+test_ipsec_stats_verify(void *ctx,
void *sess,
const struct ipsec_test_flags *flags,
enum rte_security_ipsec_sa_direction dir)
diff --git a/app/test/test_cryptodev_security_ipsec.h b/app/test/test_cryptodev_security_ipsec.h
index e7903e9334..8587fc4577 100644
--- a/app/test/test_cryptodev_security_ipsec.h
+++ b/app/test/test_cryptodev_security_ipsec.h
@@ -302,7 +302,7 @@ int test_ipsec_status_check(const struct ipsec_test_data *td,
enum rte_security_ipsec_sa_direction dir,
int pkt_num);
-int test_ipsec_stats_verify(struct rte_security_ctx *ctx,
+int test_ipsec_stats_verify(void *ctx,
void *sess,
const struct ipsec_test_flags *flags,
enum rte_security_ipsec_sa_direction dir);
diff --git a/app/test/test_security_inline_macsec.c b/app/test/test_security_inline_macsec.c
index 40fdfda942..59b1b8a6a6 100644
--- a/app/test/test_security_inline_macsec.c
+++ b/app/test/test_security_inline_macsec.c
@@ -136,7 +136,7 @@ init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len)
static int
init_mempools(unsigned int nb_mbuf)
{
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint16_t nb_sess = 512;
uint32_t sess_sz;
char s[64];
@@ -482,7 +482,7 @@ test_macsec_post_process(struct rte_mbuf *m, const struct mcs_test_vector *td,
}
static void
-mcs_stats_dump(struct rte_security_ctx *ctx, enum mcs_op op,
+mcs_stats_dump(void *ctx, enum mcs_op op,
void *rx_sess, void *tx_sess,
uint8_t rx_sc_id, uint8_t tx_sc_id,
uint16_t rx_sa_id[], uint16_t tx_sa_id[])
@@ -667,7 +667,7 @@ mcs_stats_dump(struct rte_security_ctx *ctx, enum mcs_op op,
}
static int
-mcs_stats_check(struct rte_security_ctx *ctx, enum mcs_op op,
+mcs_stats_check(void *ctx, enum mcs_op op,
const struct mcs_test_opts *opts,
const struct mcs_test_vector *td,
void *rx_sess, void *tx_sess,
@@ -900,7 +900,7 @@ test_macsec(const struct mcs_test_vector *td[], enum mcs_op op, const struct mcs
struct rte_security_macsec_sa sa_conf = {0};
struct rte_security_macsec_sc sc_conf = {0};
struct mcs_err_vector err_vector = {0};
- struct rte_security_ctx *ctx;
+ void *ctx;
int nb_rx = 0, nb_sent;
int i, j = 0, ret, id, an = 0;
uint8_t tci_off;
@@ -908,7 +908,7 @@ test_macsec(const struct mcs_test_vector *td[], enum mcs_op op, const struct mcs
memset(rx_pkts_burst, 0, sizeof(rx_pkts_burst[0]) * opts->nb_td);
- ctx = (struct rte_security_ctx *)rte_eth_dev_get_sec_ctx(port_id);
+ ctx = rte_eth_dev_get_sec_ctx(port_id);
if (ctx == NULL) {
printf("Ethernet device doesn't support security features.\n");
return TEST_SKIPPED;
diff --git a/app/test/test_security_inline_proto.c b/app/test/test_security_inline_proto.c
index 33eb1dd201..78a2064b65 100644
--- a/app/test/test_security_inline_proto.c
+++ b/app/test/test_security_inline_proto.c
@@ -136,7 +136,7 @@ static struct rte_flow *default_flow[RTE_MAX_ETHPORTS];
/* Create Inline IPsec session */
static int
create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
- void **sess, struct rte_security_ctx **ctx,
+ void **sess, void **ctx,
uint32_t *ol_flags, const struct ipsec_test_flags *flags,
struct rte_security_session_conf *sess_conf)
{
@@ -149,7 +149,7 @@ create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
struct rte_security_capability_idx sec_cap_idx;
const struct rte_security_capability *sec_cap;
enum rte_security_ipsec_sa_direction dir;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint32_t verify;
sess_conf->action_type = RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL;
@@ -221,7 +221,7 @@ create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
sess_conf->userdata = (void *) sa;
- sec_ctx = (struct rte_security_ctx *)rte_eth_dev_get_sec_ctx(portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(portid);
if (sec_ctx == NULL) {
printf("Ethernet device doesn't support security features.\n");
return TEST_SKIPPED;
@@ -503,7 +503,7 @@ init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len, bool
static int
init_mempools(unsigned int nb_mbuf)
{
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint16_t nb_sess = 512;
uint32_t sess_sz;
char s[64];
@@ -846,7 +846,7 @@ test_ipsec_with_reassembly(struct reassembly_vector *vector,
struct rte_crypto_sym_xform auth_in = {0};
struct rte_crypto_sym_xform aead_in = {0};
struct ipsec_test_data sa_data;
- struct rte_security_ctx *ctx;
+ void *ctx;
unsigned int i, nb_rx = 0, j;
uint32_t ol_flags;
bool outer_ipv4;
@@ -1113,7 +1113,7 @@ test_ipsec_inline_proto_process(struct ipsec_test_data *td,
struct rte_crypto_sym_xform auth = {0};
struct rte_crypto_sym_xform aead = {0};
struct sa_expiry_vector vector = {0};
- struct rte_security_ctx *ctx;
+ void *ctx;
int nb_rx = 0, nb_sent;
uint32_t ol_flags;
int i, j = 0, ret;
@@ -1398,7 +1398,7 @@ test_ipsec_inline_proto_process_with_esn(struct ipsec_test_data td[],
struct rte_mbuf *tx_pkt = NULL;
int nb_rx, nb_sent;
void *ses;
- struct rte_security_ctx *ctx;
+ void *ctx;
uint32_t ol_flags;
bool outer_ipv4;
int i, ret;
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4ec4953f6e..c776efebd9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -139,9 +139,6 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
-* security: Hide structures ``rte_security_ops`` and ``rte_security_ctx``
- as these are internal to DPDK library and drivers.
-
* eventdev: The single-event (non-burst) enqueue and dequeue operations,
used by static inline burst enqueue and dequeue functions in ``rte_eventdev.h``,
will be removed in DPDK 23.11.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index d0bfb7f5d2..250735efa9 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -144,6 +144,9 @@ API Changes
except ``rte_thread_setname()`` and ``rte_ctrl_thread_create()`` which are
replaced with ``rte_thread_set_name()`` and ``rte_thread_create_control()``.
+* security: Structures ``rte_security_ops`` and ``rte_security_ctx`` were moved to
+ internal library headers not visible to application.
+
ABI Changes
-----------
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 3ab7995fd5..bf98d2618b 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -568,7 +568,7 @@ process_pkts_outbound_nosp(struct ipsec_ctx *ipsec_ctx,
static inline void
process_pkts(struct lcore_conf *qconf, struct rte_mbuf **pkts,
- uint8_t nb_pkts, uint16_t portid, struct rte_security_ctx *ctx)
+ uint8_t nb_pkts, uint16_t portid, void *ctx)
{
struct ipsec_traffic traffic;
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index a5706bed24..f5cec4a928 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -205,7 +205,7 @@ verify_ipsec_capabilities(struct rte_security_ipsec_xform *ipsec_xform,
static inline int
-verify_security_capabilities(struct rte_security_ctx *ctx,
+verify_security_capabilities(void *ctx,
struct rte_security_session_conf *sess_conf,
uint32_t *ol_flags)
{
@@ -327,9 +327,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx_lcore[],
};
if (ips->type == RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) {
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- cdev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(cdev_id);
/* Set IPsec parameters in conf */
set_ipsec_conf(sa, &(sess_conf.ipsec));
@@ -411,7 +409,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
struct rte_ipsec_session *ips)
{
int32_t ret = 0;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
struct rte_security_session_conf sess_conf = {
.action_type = ips->type,
.protocol = RTE_SECURITY_PROTOCOL_IPSEC,
@@ -490,9 +488,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
struct rte_flow_error err;
int ret = 0;
- sec_ctx = (struct rte_security_ctx *)
- rte_eth_dev_get_sec_ctx(
- sa->portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(sa->portid);
if (sec_ctx == NULL) {
RTE_LOG(ERR, IPSEC,
" rte_eth_dev_get_sec_ctx failed\n");
@@ -657,8 +653,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
return -1;
}
} else if (ips->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
- sec_ctx = (struct rte_security_ctx *)
- rte_eth_dev_get_sec_ctx(sa->portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(sa->portid);
if (sec_ctx == NULL) {
RTE_LOG(ERR, IPSEC,
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 6bef2a7285..5059418456 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -279,7 +279,7 @@ struct cnt_blk {
struct lcore_rx_queue {
uint16_t port_id;
uint8_t queue_id;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
} __rte_cache_aligned;
struct buffer {
diff --git a/examples/ipsec-secgw/ipsec_worker.c b/examples/ipsec-secgw/ipsec_worker.c
index 58c80c73f0..8d122e8519 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -20,7 +20,7 @@
struct port_drv_mode_data {
void *sess;
- struct rte_security_ctx *ctx;
+ void *ctx;
};
typedef void (*ipsec_worker_fn_t)(void);
diff --git a/examples/ipsec-secgw/ipsec_worker.h b/examples/ipsec-secgw/ipsec_worker.h
index cf59b9b5ab..ac980b8bcf 100644
--- a/examples/ipsec-secgw/ipsec_worker.h
+++ b/examples/ipsec-secgw/ipsec_worker.h
@@ -119,7 +119,7 @@ adjust_ipv6_pktlen(struct rte_mbuf *m, const struct rte_ipv6_hdr *iph,
}
static __rte_always_inline void
-prepare_one_packet(struct rte_security_ctx *ctx, struct rte_mbuf *pkt,
+prepare_one_packet(void *ctx, struct rte_mbuf *pkt,
struct ipsec_traffic *t)
{
uint32_t ptype = pkt->packet_type;
@@ -230,7 +230,7 @@ prepare_one_packet(struct rte_security_ctx *ctx, struct rte_mbuf *pkt,
}
static __rte_always_inline void
-prepare_traffic(struct rte_security_ctx *ctx, struct rte_mbuf **pkts,
+prepare_traffic(void *ctx, struct rte_mbuf **pkts,
struct ipsec_traffic *t, uint16_t nb_pkts)
{
int32_t i;
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index 42af4a2c35..ab44bbe0f0 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -60,11 +60,12 @@ rte_security_oop_dynfield_register(void)
}
void *
-rte_security_session_create(struct rte_security_ctx *instance,
+rte_security_session_create(void *ctx,
struct rte_security_session_conf *conf,
struct rte_mempool *mp)
{
struct rte_security_session *sess = NULL;
+ struct rte_security_ctx *instance = ctx;
uint32_t sess_priv_size;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
@@ -93,10 +94,10 @@ rte_security_session_create(struct rte_security_ctx *instance,
}
int
-rte_security_session_update(struct rte_security_ctx *instance,
- void *sess,
- struct rte_security_session_conf *conf)
+rte_security_session_update(void *ctx, void *sess, struct rte_security_session_conf *conf)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_update, -EINVAL,
-ENOTSUP);
RTE_PTR_OR_ERR_RET(sess, -EINVAL);
@@ -106,8 +107,10 @@ rte_security_session_update(struct rte_security_ctx *instance,
}
unsigned int
-rte_security_session_get_size(struct rte_security_ctx *instance)
+rte_security_session_get_size(void *ctx)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_get_size, 0, 0);
return (sizeof(struct rte_security_session) +
@@ -115,10 +118,10 @@ rte_security_session_get_size(struct rte_security_ctx *instance)
}
int
-rte_security_session_stats_get(struct rte_security_ctx *instance,
- void *sess,
- struct rte_security_stats *stats)
+rte_security_session_stats_get(void *ctx, void *sess, struct rte_security_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_stats_get, -EINVAL,
-ENOTSUP);
/* Parameter sess can be NULL in case of getting global statistics. */
@@ -128,8 +131,9 @@ rte_security_session_stats_get(struct rte_security_ctx *instance,
}
int
-rte_security_session_destroy(struct rte_security_ctx *instance, void *sess)
+rte_security_session_destroy(void *ctx, void *sess)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_destroy, -EINVAL,
@@ -149,9 +153,9 @@ rte_security_session_destroy(struct rte_security_ctx *instance, void *sess)
}
int
-rte_security_macsec_sc_create(struct rte_security_ctx *instance,
- struct rte_security_macsec_sc *conf)
+rte_security_macsec_sc_create(void *ctx, struct rte_security_macsec_sc *conf)
{
+ struct rte_security_ctx *instance = ctx;
int sc_id;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_create, -EINVAL, -ENOTSUP);
@@ -165,9 +169,9 @@ rte_security_macsec_sc_create(struct rte_security_ctx *instance,
}
int
-rte_security_macsec_sa_create(struct rte_security_ctx *instance,
- struct rte_security_macsec_sa *conf)
+rte_security_macsec_sa_create(void *ctx, struct rte_security_macsec_sa *conf)
{
+ struct rte_security_ctx *instance = ctx;
int sa_id;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_create, -EINVAL, -ENOTSUP);
@@ -181,9 +185,10 @@ rte_security_macsec_sa_create(struct rte_security_ctx *instance,
}
int
-rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_destroy(void *ctx, uint16_t sc_id,
enum rte_security_macsec_direction dir)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_destroy, -EINVAL, -ENOTSUP);
@@ -199,9 +204,10 @@ rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id
}
int
-rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_destroy(void *ctx, uint16_t sa_id,
enum rte_security_macsec_direction dir)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_destroy, -EINVAL, -ENOTSUP);
@@ -217,10 +223,12 @@ rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id
}
int
-rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_stats_get(void *ctx, uint16_t sc_id,
enum rte_security_macsec_direction dir,
struct rte_security_macsec_sc_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_stats_get, -EINVAL, -ENOTSUP);
RTE_PTR_OR_ERR_RET(stats, -EINVAL);
@@ -228,10 +236,12 @@ rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance, uint16_t sc_
}
int
-rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_stats_get(void *ctx, uint16_t sa_id,
enum rte_security_macsec_direction dir,
struct rte_security_macsec_sa_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_stats_get, -EINVAL, -ENOTSUP);
RTE_PTR_OR_ERR_RET(stats, -EINVAL);
@@ -239,10 +249,9 @@ rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance, uint16_t sa_
}
int
-__rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
- void *sess,
- struct rte_mbuf *m, void *params)
+__rte_security_set_pkt_metadata(void *ctx, void *sess, struct rte_mbuf *m, void *params)
{
+ struct rte_security_ctx *instance = ctx;
#ifdef RTE_DEBUG
RTE_PTR_OR_ERR_RET(sess, -EINVAL);
RTE_PTR_OR_ERR_RET(instance, -EINVAL);
@@ -255,19 +264,21 @@ __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
}
const struct rte_security_capability *
-rte_security_capabilities_get(struct rte_security_ctx *instance)
+rte_security_capabilities_get(void *ctx)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, capabilities_get, NULL, NULL);
return instance->ops->capabilities_get(instance->device);
}
const struct rte_security_capability *
-rte_security_capability_get(struct rte_security_ctx *instance,
- struct rte_security_capability_idx *idx)
+rte_security_capability_get(void *ctx, struct rte_security_capability_idx *idx)
{
const struct rte_security_capability *capabilities;
const struct rte_security_capability *capability;
+ struct rte_security_ctx *instance = ctx;
uint16_t i = 0;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, capabilities_get, NULL, NULL);
@@ -401,12 +412,12 @@ static int
security_capabilities_from_dev_id(int dev_id, const void **caps)
{
const struct rte_security_capability *capabilities;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
if (rte_cryptodev_is_valid_dev(dev_id) == 0)
return -EINVAL;
- sec_ctx = (struct rte_security_ctx *)rte_cryptodev_get_sec_ctx(dev_id);
+ sec_ctx = rte_cryptodev_get_sec_ctx(dev_id);
RTE_PTR_OR_ERR_RET(sec_ctx, -EINVAL);
capabilities = rte_security_capabilities_get(sec_ctx);
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index da58fe1f14..c9cc7a45a6 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -56,30 +56,6 @@ enum rte_security_ipsec_tunnel_type {
#define RTE_SECURITY_IPSEC_TUNNEL_VERIFY_DST_ADDR 0x1
#define RTE_SECURITY_IPSEC_TUNNEL_VERIFY_SRC_DST_ADDR 0x2
-/**
- * Security context for crypto/eth devices
- *
- * Security instance for each driver to register security operations.
- * The application can get the security context from the crypto/eth device id
- * using the APIs rte_cryptodev_get_sec_ctx()/rte_eth_dev_get_sec_ctx()
- * This structure is used to identify the device(crypto/eth) for which the
- * security operations need to be performed.
- */
-struct rte_security_ctx {
- void *device;
- /**< Crypto/ethernet device attached */
- const struct rte_security_ops *ops;
- /**< Pointer to security ops for the device */
- uint16_t sess_cnt;
- /**< Number of sessions attached to this context */
- uint16_t macsec_sc_cnt;
- /**< Number of MACsec SC attached to this context */
- uint16_t macsec_sa_cnt;
- /**< Number of MACsec SA attached to this context */
- uint32_t flags;
- /**< Flags for security context */
-};
-
#define RTE_SEC_CTX_F_FAST_SET_MDATA 0x00000001
/**< Driver uses fast metadata update without using driver specific callback.
* For fast mdata, mbuf dynamic field would be registered by driver
@@ -695,7 +671,7 @@ struct rte_security_session_conf {
* - On failure, NULL
*/
void *
-rte_security_session_create(struct rte_security_ctx *instance,
+rte_security_session_create(void *instance,
struct rte_security_session_conf *conf,
struct rte_mempool *mp);
@@ -711,7 +687,7 @@ rte_security_session_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_session_update(struct rte_security_ctx *instance,
+rte_security_session_update(void *instance,
void *sess,
struct rte_security_session_conf *conf);
@@ -725,7 +701,7 @@ rte_security_session_update(struct rte_security_ctx *instance,
* - 0 if device is invalid or does not support the operation.
*/
unsigned int
-rte_security_session_get_size(struct rte_security_ctx *instance);
+rte_security_session_get_size(void *instance);
/**
* Free security session header and the session private data and
@@ -742,7 +718,7 @@ rte_security_session_get_size(struct rte_security_ctx *instance);
* - other negative values in case of freeing private data errors.
*/
int
-rte_security_session_destroy(struct rte_security_ctx *instance, void *sess);
+rte_security_session_destroy(void *instance, void *sess);
/**
* @warning
@@ -761,7 +737,7 @@ rte_security_session_destroy(struct rte_security_ctx *instance, void *sess);
*/
__rte_experimental
int
-rte_security_macsec_sc_create(struct rte_security_ctx *instance,
+rte_security_macsec_sc_create(void *instance,
struct rte_security_macsec_sc *conf);
/**
@@ -780,7 +756,7 @@ rte_security_macsec_sc_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_destroy(void *instance, uint16_t sc_id,
enum rte_security_macsec_direction dir);
/**
@@ -800,7 +776,7 @@ rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id
*/
__rte_experimental
int
-rte_security_macsec_sa_create(struct rte_security_ctx *instance,
+rte_security_macsec_sa_create(void *instance,
struct rte_security_macsec_sa *conf);
/**
@@ -819,7 +795,7 @@ rte_security_macsec_sa_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_destroy(void *instance, uint16_t sa_id,
enum rte_security_macsec_direction dir);
/** Device-specific metadata field type */
@@ -889,6 +865,27 @@ static inline bool rte_security_dynfield_is_registered(void)
return rte_security_dynfield_offset >= 0;
}
+#define RTE_SECURITY_CTX_FLAGS_OFF 4
+/**
+ * Get security flags from security instance.
+ */
+static inline uint32_t
+rte_security_ctx_flags_get(void *ctx)
+{
+ return *((uint32_t *)ctx + RTE_SECURITY_CTX_FLAGS_OFF);
+}
+
+/**
+ * Set security flags in security instance.
+ */
+static inline void
+rte_security_ctx_flags_set(void *ctx, uint32_t flags)
+{
+ uint32_t *data;
+ data = (((uint32_t *)ctx) + RTE_SECURITY_CTX_FLAGS_OFF);
+ *data = flags;
+}
+
#define RTE_SECURITY_SESS_OPAQUE_DATA_OFF 0
#define RTE_SECURITY_SESS_FAST_MDATA_OFF 1
/**
@@ -933,7 +930,7 @@ rte_security_session_fast_mdata_set(void *sess, uint64_t fdata)
/** Function to call PMD specific function pointer set_pkt_metadata() */
__rte_experimental
-int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
+int __rte_security_set_pkt_metadata(void *instance,
void *sess,
struct rte_mbuf *m, void *params);
@@ -951,12 +948,12 @@ int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
* - On failure, a negative value.
*/
static inline int
-rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
+rte_security_set_pkt_metadata(void *instance,
void *sess,
struct rte_mbuf *mb, void *params)
{
/* Fast Path */
- if (instance->flags & RTE_SEC_CTX_F_FAST_SET_MDATA) {
+ if (rte_security_ctx_flags_get(instance) & RTE_SEC_CTX_F_FAST_SET_MDATA) {
*rte_security_dynfield(mb) = (rte_security_dynfield_t)
rte_security_session_fast_mdata_get(sess);
return 0;
@@ -1105,7 +1102,7 @@ struct rte_security_stats {
*/
__rte_experimental
int
-rte_security_session_stats_get(struct rte_security_ctx *instance,
+rte_security_session_stats_get(void *instance,
void *sess,
struct rte_security_stats *stats);
@@ -1125,7 +1122,7 @@ rte_security_session_stats_get(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance,
+rte_security_macsec_sa_stats_get(void *instance,
uint16_t sa_id, enum rte_security_macsec_direction dir,
struct rte_security_macsec_sa_stats *stats);
@@ -1145,7 +1142,7 @@ rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance,
+rte_security_macsec_sc_stats_get(void *instance,
uint16_t sc_id, enum rte_security_macsec_direction dir,
struct rte_security_macsec_sc_stats *stats);
@@ -1296,7 +1293,7 @@ struct rte_security_capability_idx {
* - Return NULL if no capabilities available.
*/
const struct rte_security_capability *
-rte_security_capabilities_get(struct rte_security_ctx *instance);
+rte_security_capabilities_get(void *instance);
/**
* Query if a specific capability is available on security instance
@@ -1310,7 +1307,7 @@ rte_security_capabilities_get(struct rte_security_ctx *instance);
* - Return NULL if the capability not matched on security instance.
*/
const struct rte_security_capability *
-rte_security_capability_get(struct rte_security_ctx *instance,
+rte_security_capability_get(void *instance,
struct rte_security_capability_idx *idx);
#ifdef __cplusplus
diff --git a/lib/security/rte_security_driver.h b/lib/security/rte_security_driver.h
index 1e6a6ef8e3..e5e1c4cfe8 100644
--- a/lib/security/rte_security_driver.h
+++ b/lib/security/rte_security_driver.h
@@ -37,6 +37,30 @@ struct rte_security_session {
/**< Private session material, variable size (depends on driver) */
};
+/**
+ * Security context for crypto/eth devices
+ *
+ * Security instance for each driver to register security operations.
+ * The application can get the security context from the crypto/eth device id
+ * using the APIs rte_cryptodev_get_sec_ctx()/rte_eth_dev_get_sec_ctx()
+ * This structure is used to identify the device(crypto/eth) for which the
+ * security operations need to be performed.
+ */
+struct rte_security_ctx {
+ void *device;
+ /**< Crypto/ethernet device attached */
+ const struct rte_security_ops *ops;
+ /**< Pointer to security ops for the device */
+ uint32_t flags;
+ /**< Flags for security context */
+ uint16_t sess_cnt;
+ /**< Number of sessions attached to this context */
+ uint16_t macsec_sc_cnt;
+ /**< Number of MACsec SC attached to this context */
+ uint16_t macsec_sa_cnt;
+ /**< Number of MACsec SA attached to this context */
+};
+
/**
* Helper macro to get driver private data
*/
--
2.25.1
^ permalink raw reply [relevance 2%]
* [PATCH v4] security: hide security context
2023-09-26 7:19 2% ` [PATCH v3] " Akhil Goyal
@ 2023-09-26 8:08 1% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2023-09-26 8:08 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, fanzhang.oss, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.v.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
rte_security_ctx is used by all security APIs to identify
which device security_op it need to call and hence it should
be opaque to the application.
Hence, it is now moved to internal header file and all
APIs will now take an opaque pointer for it.
The fast path inline APIs like set metadata need to get flags
from security_ctx. The flags are now retrieved using inline APIs
which use macros to get the offset of flags in security_ctx.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Ciara Power <ciara.power@intel.com>
---
Changes in v4: Updated rte_security doc.
Changes in v3: Updated release notes and removed deprecation notice.
Changes in v2: Rebased.
app/test-crypto-perf/cperf_ops.c | 9 +--
app/test-crypto-perf/cperf_test_latency.c | 3 +-
.../cperf_test_pmd_cyclecount.c | 8 +-
app/test-crypto-perf/cperf_test_throughput.c | 9 +--
app/test-crypto-perf/cperf_test_verify.c | 4 +-
app/test-security-perf/test_security_perf.c | 2 +-
app/test/test_cryptodev.c | 22 ++----
app/test/test_cryptodev_security_ipsec.c | 2 +-
app/test/test_cryptodev_security_ipsec.h | 2 +-
app/test/test_security_inline_macsec.c | 10 +--
app/test/test_security_inline_proto.c | 14 ++--
doc/guides/prog_guide/rte_security.rst | 2 +-
doc/guides/rel_notes/deprecation.rst | 3 -
doc/guides/rel_notes/release_23_11.rst | 3 +
examples/ipsec-secgw/ipsec-secgw.c | 2 +-
examples/ipsec-secgw/ipsec.c | 15 ++--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/ipsec_worker.c | 2 +-
examples/ipsec-secgw/ipsec_worker.h | 4 +-
lib/security/rte_security.c | 61 +++++++++------
lib/security/rte_security.h | 77 +++++++++----------
lib/security/rte_security_driver.h | 24 ++++++
22 files changed, 144 insertions(+), 136 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 93b9bfb240..84945d1313 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -749,8 +749,7 @@ create_ipsec_session(struct rte_mempool *sess_mp,
else
sess_conf.ipsec.direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
@@ -853,8 +852,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
.crypto_xform = &cipher_xform
};
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
@@ -901,8 +899,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
} },
.crypto_xform = &cipher_xform
};
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(dev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(dev_id);
/* Create security session */
return (void *)rte_security_session_create(ctx, &sess_conf, sess_mp);
diff --git a/app/test-crypto-perf/cperf_test_latency.c b/app/test-crypto-perf/cperf_test_latency.c
index f1676a9aa9..484bc9eb4e 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -53,8 +53,7 @@ cperf_latency_test_free(struct cperf_latency_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
rte_security_session_destroy(sec_ctx, ctx->sess);
}
#endif
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index 0307e82996..4a60f6d558 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -67,11 +67,9 @@ cperf_pmd_cyclecount_test_free(struct cperf_pmd_cyclecount_ctx *ctx)
#ifdef RTE_LIB_SECURITY
if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS) {
- struct rte_security_ctx *sec_ctx =
- (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
- rte_security_session_destroy(sec_ctx,
- (void *)ctx->sess);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
+ rte_security_session_destroy(sec_ctx, (void *)ctx->sess);
} else
#endif
rte_cryptodev_sym_session_free(ctx->dev_id, ctx->sess);
diff --git a/app/test-crypto-perf/cperf_test_throughput.c b/app/test-crypto-perf/cperf_test_throughput.c
index e892a70699..f8f8bd717f 100644
--- a/app/test-crypto-perf/cperf_test_throughput.c
+++ b/app/test-crypto-perf/cperf_test_throughput.c
@@ -44,12 +44,9 @@ cperf_throughput_test_free(struct cperf_throughput_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
- rte_security_session_destroy(
- sec_ctx,
- (void *)ctx->sess);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
+ rte_security_session_destroy(sec_ctx, (void *)ctx->sess);
}
#endif
else
diff --git a/app/test-crypto-perf/cperf_test_verify.c b/app/test-crypto-perf/cperf_test_verify.c
index 8042c94e04..a6c0ffe813 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -48,8 +48,8 @@ cperf_verify_test_free(struct cperf_verify_ctx *ctx)
else if (ctx->options->op_type == CPERF_PDCP ||
ctx->options->op_type == CPERF_DOCSIS ||
ctx->options->op_type == CPERF_IPSEC) {
- struct rte_security_ctx *sec_ctx =
- rte_cryptodev_get_sec_ctx(ctx->dev_id);
+ void *sec_ctx = rte_cryptodev_get_sec_ctx(ctx->dev_id);
+
rte_security_session_destroy(sec_ctx, ctx->sess);
}
#endif
diff --git a/app/test-security-perf/test_security_perf.c b/app/test-security-perf/test_security_perf.c
index 9bb50689e3..4dfaca4800 100644
--- a/app/test-security-perf/test_security_perf.c
+++ b/app/test-security-perf/test_security_perf.c
@@ -344,7 +344,7 @@ test_security_session_perf(void *arg)
struct rte_security_session_conf sess_conf;
int i, ret, nb_sessions, nb_sess_total;
struct rte_security_session **sess;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
double setup_rate, destroy_rate;
uint64_t setup_ms, destroy_ms;
struct lcore_conf *conf = arg;
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 3a51a5d00f..fcac108511 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -8931,9 +8931,7 @@ security_proto_supported(enum rte_security_session_action_type action,
const struct rte_security_capability *capability;
uint16_t i = 0;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
capabilities = rte_security_capabilities_get(ctx);
@@ -8973,9 +8971,7 @@ static int test_pdcp_proto(int i, int oop, enum rte_crypto_cipher_operation opc,
struct crypto_unittest_params *ut_params = &unittest_params;
uint8_t *plaintext;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
struct rte_cryptodev_info dev_info;
uint64_t feat_flags;
@@ -9180,9 +9176,7 @@ test_pdcp_proto_SGL(int i, int oop,
unsigned int trn_data = 0;
struct rte_cryptodev_info dev_info;
uint64_t feat_flags;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
struct rte_mbuf *temp_mbuf;
rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
@@ -9905,7 +9899,7 @@ test_ipsec_proto_process(const struct ipsec_test_data td[],
struct ipsec_test_data *res_d_tmp = NULL;
uint8_t input_text[IPSEC_TEXT_MAX_LEN];
int salt_len, i, ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx;
+ void *ctx;
uint32_t src, dst;
uint32_t verify;
@@ -11088,9 +11082,7 @@ test_docsis_proto_uplink(const void *data)
uint32_t crc_data_len;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
/* Verify the capabilities */
struct rte_security_capability_idx sec_cap_idx;
@@ -11272,9 +11264,7 @@ test_docsis_proto_downlink(const void *data)
int32_t cipher_len, crc_len;
int ret = TEST_SUCCESS;
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- ts_params->valid_devs[0]);
+ void *ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
/* Verify the capabilities */
struct rte_security_capability_idx sec_cap_idx;
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index be9e246bfe..205714b270 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -1249,7 +1249,7 @@ test_ipsec_status_check(const struct ipsec_test_data *td,
}
int
-test_ipsec_stats_verify(struct rte_security_ctx *ctx,
+test_ipsec_stats_verify(void *ctx,
void *sess,
const struct ipsec_test_flags *flags,
enum rte_security_ipsec_sa_direction dir)
diff --git a/app/test/test_cryptodev_security_ipsec.h b/app/test/test_cryptodev_security_ipsec.h
index e7903e9334..8587fc4577 100644
--- a/app/test/test_cryptodev_security_ipsec.h
+++ b/app/test/test_cryptodev_security_ipsec.h
@@ -302,7 +302,7 @@ int test_ipsec_status_check(const struct ipsec_test_data *td,
enum rte_security_ipsec_sa_direction dir,
int pkt_num);
-int test_ipsec_stats_verify(struct rte_security_ctx *ctx,
+int test_ipsec_stats_verify(void *ctx,
void *sess,
const struct ipsec_test_flags *flags,
enum rte_security_ipsec_sa_direction dir);
diff --git a/app/test/test_security_inline_macsec.c b/app/test/test_security_inline_macsec.c
index 40fdfda942..59b1b8a6a6 100644
--- a/app/test/test_security_inline_macsec.c
+++ b/app/test/test_security_inline_macsec.c
@@ -136,7 +136,7 @@ init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len)
static int
init_mempools(unsigned int nb_mbuf)
{
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint16_t nb_sess = 512;
uint32_t sess_sz;
char s[64];
@@ -482,7 +482,7 @@ test_macsec_post_process(struct rte_mbuf *m, const struct mcs_test_vector *td,
}
static void
-mcs_stats_dump(struct rte_security_ctx *ctx, enum mcs_op op,
+mcs_stats_dump(void *ctx, enum mcs_op op,
void *rx_sess, void *tx_sess,
uint8_t rx_sc_id, uint8_t tx_sc_id,
uint16_t rx_sa_id[], uint16_t tx_sa_id[])
@@ -667,7 +667,7 @@ mcs_stats_dump(struct rte_security_ctx *ctx, enum mcs_op op,
}
static int
-mcs_stats_check(struct rte_security_ctx *ctx, enum mcs_op op,
+mcs_stats_check(void *ctx, enum mcs_op op,
const struct mcs_test_opts *opts,
const struct mcs_test_vector *td,
void *rx_sess, void *tx_sess,
@@ -900,7 +900,7 @@ test_macsec(const struct mcs_test_vector *td[], enum mcs_op op, const struct mcs
struct rte_security_macsec_sa sa_conf = {0};
struct rte_security_macsec_sc sc_conf = {0};
struct mcs_err_vector err_vector = {0};
- struct rte_security_ctx *ctx;
+ void *ctx;
int nb_rx = 0, nb_sent;
int i, j = 0, ret, id, an = 0;
uint8_t tci_off;
@@ -908,7 +908,7 @@ test_macsec(const struct mcs_test_vector *td[], enum mcs_op op, const struct mcs
memset(rx_pkts_burst, 0, sizeof(rx_pkts_burst[0]) * opts->nb_td);
- ctx = (struct rte_security_ctx *)rte_eth_dev_get_sec_ctx(port_id);
+ ctx = rte_eth_dev_get_sec_ctx(port_id);
if (ctx == NULL) {
printf("Ethernet device doesn't support security features.\n");
return TEST_SKIPPED;
diff --git a/app/test/test_security_inline_proto.c b/app/test/test_security_inline_proto.c
index 33eb1dd201..78a2064b65 100644
--- a/app/test/test_security_inline_proto.c
+++ b/app/test/test_security_inline_proto.c
@@ -136,7 +136,7 @@ static struct rte_flow *default_flow[RTE_MAX_ETHPORTS];
/* Create Inline IPsec session */
static int
create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
- void **sess, struct rte_security_ctx **ctx,
+ void **sess, void **ctx,
uint32_t *ol_flags, const struct ipsec_test_flags *flags,
struct rte_security_session_conf *sess_conf)
{
@@ -149,7 +149,7 @@ create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
struct rte_security_capability_idx sec_cap_idx;
const struct rte_security_capability *sec_cap;
enum rte_security_ipsec_sa_direction dir;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint32_t verify;
sess_conf->action_type = RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL;
@@ -221,7 +221,7 @@ create_inline_ipsec_session(struct ipsec_test_data *sa, uint16_t portid,
sess_conf->userdata = (void *) sa;
- sec_ctx = (struct rte_security_ctx *)rte_eth_dev_get_sec_ctx(portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(portid);
if (sec_ctx == NULL) {
printf("Ethernet device doesn't support security features.\n");
return TEST_SKIPPED;
@@ -503,7 +503,7 @@ init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len, bool
static int
init_mempools(unsigned int nb_mbuf)
{
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
uint16_t nb_sess = 512;
uint32_t sess_sz;
char s[64];
@@ -846,7 +846,7 @@ test_ipsec_with_reassembly(struct reassembly_vector *vector,
struct rte_crypto_sym_xform auth_in = {0};
struct rte_crypto_sym_xform aead_in = {0};
struct ipsec_test_data sa_data;
- struct rte_security_ctx *ctx;
+ void *ctx;
unsigned int i, nb_rx = 0, j;
uint32_t ol_flags;
bool outer_ipv4;
@@ -1113,7 +1113,7 @@ test_ipsec_inline_proto_process(struct ipsec_test_data *td,
struct rte_crypto_sym_xform auth = {0};
struct rte_crypto_sym_xform aead = {0};
struct sa_expiry_vector vector = {0};
- struct rte_security_ctx *ctx;
+ void *ctx;
int nb_rx = 0, nb_sent;
uint32_t ol_flags;
int i, j = 0, ret;
@@ -1398,7 +1398,7 @@ test_ipsec_inline_proto_process_with_esn(struct ipsec_test_data td[],
struct rte_mbuf *tx_pkt = NULL;
int nb_rx, nb_sent;
void *ses;
- struct rte_security_ctx *ctx;
+ void *ctx;
uint32_t ol_flags;
bool outer_ipv4;
int i, ret;
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index b4db4a7bfd..ad8c6374bd 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -637,7 +637,7 @@ And the session mempool object size should be enough to accommodate
Once the session mempools have been created, ``rte_security_session_create()``
is used to allocate and initialize a session for the required crypto/ethernet device.
-Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
+Session APIs need an opaque handle to identify the crypto/ethernet
security ops. This parameter can be retrieved using the APIs
``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
(for ethernet port).
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 4ec4953f6e..c776efebd9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -139,9 +139,6 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
-* security: Hide structures ``rte_security_ops`` and ``rte_security_ctx``
- as these are internal to DPDK library and drivers.
-
* eventdev: The single-event (non-burst) enqueue and dequeue operations,
used by static inline burst enqueue and dequeue functions in ``rte_eventdev.h``,
will be removed in DPDK 23.11.
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index d0bfb7f5d2..250735efa9 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -144,6 +144,9 @@ API Changes
except ``rte_thread_setname()`` and ``rte_ctrl_thread_create()`` which are
replaced with ``rte_thread_set_name()`` and ``rte_thread_create_control()``.
+* security: Structures ``rte_security_ops`` and ``rte_security_ctx`` were moved to
+ internal library headers not visible to application.
+
ABI Changes
-----------
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 3ab7995fd5..bf98d2618b 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -568,7 +568,7 @@ process_pkts_outbound_nosp(struct ipsec_ctx *ipsec_ctx,
static inline void
process_pkts(struct lcore_conf *qconf, struct rte_mbuf **pkts,
- uint8_t nb_pkts, uint16_t portid, struct rte_security_ctx *ctx)
+ uint8_t nb_pkts, uint16_t portid, void *ctx)
{
struct ipsec_traffic traffic;
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index a5706bed24..f5cec4a928 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -205,7 +205,7 @@ verify_ipsec_capabilities(struct rte_security_ipsec_xform *ipsec_xform,
static inline int
-verify_security_capabilities(struct rte_security_ctx *ctx,
+verify_security_capabilities(void *ctx,
struct rte_security_session_conf *sess_conf,
uint32_t *ol_flags)
{
@@ -327,9 +327,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx_lcore[],
};
if (ips->type == RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL) {
- struct rte_security_ctx *ctx = (struct rte_security_ctx *)
- rte_cryptodev_get_sec_ctx(
- cdev_id);
+ void *ctx = rte_cryptodev_get_sec_ctx(cdev_id);
/* Set IPsec parameters in conf */
set_ipsec_conf(sa, &(sess_conf.ipsec));
@@ -411,7 +409,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
struct rte_ipsec_session *ips)
{
int32_t ret = 0;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
struct rte_security_session_conf sess_conf = {
.action_type = ips->type,
.protocol = RTE_SECURITY_PROTOCOL_IPSEC,
@@ -490,9 +488,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
struct rte_flow_error err;
int ret = 0;
- sec_ctx = (struct rte_security_ctx *)
- rte_eth_dev_get_sec_ctx(
- sa->portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(sa->portid);
if (sec_ctx == NULL) {
RTE_LOG(ERR, IPSEC,
" rte_eth_dev_get_sec_ctx failed\n");
@@ -657,8 +653,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
return -1;
}
} else if (ips->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
- sec_ctx = (struct rte_security_ctx *)
- rte_eth_dev_get_sec_ctx(sa->portid);
+ sec_ctx = rte_eth_dev_get_sec_ctx(sa->portid);
if (sec_ctx == NULL) {
RTE_LOG(ERR, IPSEC,
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 6bef2a7285..5059418456 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -279,7 +279,7 @@ struct cnt_blk {
struct lcore_rx_queue {
uint16_t port_id;
uint8_t queue_id;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
} __rte_cache_aligned;
struct buffer {
diff --git a/examples/ipsec-secgw/ipsec_worker.c b/examples/ipsec-secgw/ipsec_worker.c
index 58c80c73f0..8d122e8519 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -20,7 +20,7 @@
struct port_drv_mode_data {
void *sess;
- struct rte_security_ctx *ctx;
+ void *ctx;
};
typedef void (*ipsec_worker_fn_t)(void);
diff --git a/examples/ipsec-secgw/ipsec_worker.h b/examples/ipsec-secgw/ipsec_worker.h
index cf59b9b5ab..ac980b8bcf 100644
--- a/examples/ipsec-secgw/ipsec_worker.h
+++ b/examples/ipsec-secgw/ipsec_worker.h
@@ -119,7 +119,7 @@ adjust_ipv6_pktlen(struct rte_mbuf *m, const struct rte_ipv6_hdr *iph,
}
static __rte_always_inline void
-prepare_one_packet(struct rte_security_ctx *ctx, struct rte_mbuf *pkt,
+prepare_one_packet(void *ctx, struct rte_mbuf *pkt,
struct ipsec_traffic *t)
{
uint32_t ptype = pkt->packet_type;
@@ -230,7 +230,7 @@ prepare_one_packet(struct rte_security_ctx *ctx, struct rte_mbuf *pkt,
}
static __rte_always_inline void
-prepare_traffic(struct rte_security_ctx *ctx, struct rte_mbuf **pkts,
+prepare_traffic(void *ctx, struct rte_mbuf **pkts,
struct ipsec_traffic *t, uint16_t nb_pkts)
{
int32_t i;
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index 42af4a2c35..ab44bbe0f0 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -60,11 +60,12 @@ rte_security_oop_dynfield_register(void)
}
void *
-rte_security_session_create(struct rte_security_ctx *instance,
+rte_security_session_create(void *ctx,
struct rte_security_session_conf *conf,
struct rte_mempool *mp)
{
struct rte_security_session *sess = NULL;
+ struct rte_security_ctx *instance = ctx;
uint32_t sess_priv_size;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
@@ -93,10 +94,10 @@ rte_security_session_create(struct rte_security_ctx *instance,
}
int
-rte_security_session_update(struct rte_security_ctx *instance,
- void *sess,
- struct rte_security_session_conf *conf)
+rte_security_session_update(void *ctx, void *sess, struct rte_security_session_conf *conf)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_update, -EINVAL,
-ENOTSUP);
RTE_PTR_OR_ERR_RET(sess, -EINVAL);
@@ -106,8 +107,10 @@ rte_security_session_update(struct rte_security_ctx *instance,
}
unsigned int
-rte_security_session_get_size(struct rte_security_ctx *instance)
+rte_security_session_get_size(void *ctx)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_get_size, 0, 0);
return (sizeof(struct rte_security_session) +
@@ -115,10 +118,10 @@ rte_security_session_get_size(struct rte_security_ctx *instance)
}
int
-rte_security_session_stats_get(struct rte_security_ctx *instance,
- void *sess,
- struct rte_security_stats *stats)
+rte_security_session_stats_get(void *ctx, void *sess, struct rte_security_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_stats_get, -EINVAL,
-ENOTSUP);
/* Parameter sess can be NULL in case of getting global statistics. */
@@ -128,8 +131,9 @@ rte_security_session_stats_get(struct rte_security_ctx *instance,
}
int
-rte_security_session_destroy(struct rte_security_ctx *instance, void *sess)
+rte_security_session_destroy(void *ctx, void *sess)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_destroy, -EINVAL,
@@ -149,9 +153,9 @@ rte_security_session_destroy(struct rte_security_ctx *instance, void *sess)
}
int
-rte_security_macsec_sc_create(struct rte_security_ctx *instance,
- struct rte_security_macsec_sc *conf)
+rte_security_macsec_sc_create(void *ctx, struct rte_security_macsec_sc *conf)
{
+ struct rte_security_ctx *instance = ctx;
int sc_id;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_create, -EINVAL, -ENOTSUP);
@@ -165,9 +169,9 @@ rte_security_macsec_sc_create(struct rte_security_ctx *instance,
}
int
-rte_security_macsec_sa_create(struct rte_security_ctx *instance,
- struct rte_security_macsec_sa *conf)
+rte_security_macsec_sa_create(void *ctx, struct rte_security_macsec_sa *conf)
{
+ struct rte_security_ctx *instance = ctx;
int sa_id;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_create, -EINVAL, -ENOTSUP);
@@ -181,9 +185,10 @@ rte_security_macsec_sa_create(struct rte_security_ctx *instance,
}
int
-rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_destroy(void *ctx, uint16_t sc_id,
enum rte_security_macsec_direction dir)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_destroy, -EINVAL, -ENOTSUP);
@@ -199,9 +204,10 @@ rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id
}
int
-rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_destroy(void *ctx, uint16_t sa_id,
enum rte_security_macsec_direction dir)
{
+ struct rte_security_ctx *instance = ctx;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_destroy, -EINVAL, -ENOTSUP);
@@ -217,10 +223,12 @@ rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id
}
int
-rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_stats_get(void *ctx, uint16_t sc_id,
enum rte_security_macsec_direction dir,
struct rte_security_macsec_sc_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sc_stats_get, -EINVAL, -ENOTSUP);
RTE_PTR_OR_ERR_RET(stats, -EINVAL);
@@ -228,10 +236,12 @@ rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance, uint16_t sc_
}
int
-rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_stats_get(void *ctx, uint16_t sa_id,
enum rte_security_macsec_direction dir,
struct rte_security_macsec_sa_stats *stats)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, macsec_sa_stats_get, -EINVAL, -ENOTSUP);
RTE_PTR_OR_ERR_RET(stats, -EINVAL);
@@ -239,10 +249,9 @@ rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance, uint16_t sa_
}
int
-__rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
- void *sess,
- struct rte_mbuf *m, void *params)
+__rte_security_set_pkt_metadata(void *ctx, void *sess, struct rte_mbuf *m, void *params)
{
+ struct rte_security_ctx *instance = ctx;
#ifdef RTE_DEBUG
RTE_PTR_OR_ERR_RET(sess, -EINVAL);
RTE_PTR_OR_ERR_RET(instance, -EINVAL);
@@ -255,19 +264,21 @@ __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
}
const struct rte_security_capability *
-rte_security_capabilities_get(struct rte_security_ctx *instance)
+rte_security_capabilities_get(void *ctx)
{
+ struct rte_security_ctx *instance = ctx;
+
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, capabilities_get, NULL, NULL);
return instance->ops->capabilities_get(instance->device);
}
const struct rte_security_capability *
-rte_security_capability_get(struct rte_security_ctx *instance,
- struct rte_security_capability_idx *idx)
+rte_security_capability_get(void *ctx, struct rte_security_capability_idx *idx)
{
const struct rte_security_capability *capabilities;
const struct rte_security_capability *capability;
+ struct rte_security_ctx *instance = ctx;
uint16_t i = 0;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, capabilities_get, NULL, NULL);
@@ -401,12 +412,12 @@ static int
security_capabilities_from_dev_id(int dev_id, const void **caps)
{
const struct rte_security_capability *capabilities;
- struct rte_security_ctx *sec_ctx;
+ void *sec_ctx;
if (rte_cryptodev_is_valid_dev(dev_id) == 0)
return -EINVAL;
- sec_ctx = (struct rte_security_ctx *)rte_cryptodev_get_sec_ctx(dev_id);
+ sec_ctx = rte_cryptodev_get_sec_ctx(dev_id);
RTE_PTR_OR_ERR_RET(sec_ctx, -EINVAL);
capabilities = rte_security_capabilities_get(sec_ctx);
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index da58fe1f14..c9cc7a45a6 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -56,30 +56,6 @@ enum rte_security_ipsec_tunnel_type {
#define RTE_SECURITY_IPSEC_TUNNEL_VERIFY_DST_ADDR 0x1
#define RTE_SECURITY_IPSEC_TUNNEL_VERIFY_SRC_DST_ADDR 0x2
-/**
- * Security context for crypto/eth devices
- *
- * Security instance for each driver to register security operations.
- * The application can get the security context from the crypto/eth device id
- * using the APIs rte_cryptodev_get_sec_ctx()/rte_eth_dev_get_sec_ctx()
- * This structure is used to identify the device(crypto/eth) for which the
- * security operations need to be performed.
- */
-struct rte_security_ctx {
- void *device;
- /**< Crypto/ethernet device attached */
- const struct rte_security_ops *ops;
- /**< Pointer to security ops for the device */
- uint16_t sess_cnt;
- /**< Number of sessions attached to this context */
- uint16_t macsec_sc_cnt;
- /**< Number of MACsec SC attached to this context */
- uint16_t macsec_sa_cnt;
- /**< Number of MACsec SA attached to this context */
- uint32_t flags;
- /**< Flags for security context */
-};
-
#define RTE_SEC_CTX_F_FAST_SET_MDATA 0x00000001
/**< Driver uses fast metadata update without using driver specific callback.
* For fast mdata, mbuf dynamic field would be registered by driver
@@ -695,7 +671,7 @@ struct rte_security_session_conf {
* - On failure, NULL
*/
void *
-rte_security_session_create(struct rte_security_ctx *instance,
+rte_security_session_create(void *instance,
struct rte_security_session_conf *conf,
struct rte_mempool *mp);
@@ -711,7 +687,7 @@ rte_security_session_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_session_update(struct rte_security_ctx *instance,
+rte_security_session_update(void *instance,
void *sess,
struct rte_security_session_conf *conf);
@@ -725,7 +701,7 @@ rte_security_session_update(struct rte_security_ctx *instance,
* - 0 if device is invalid or does not support the operation.
*/
unsigned int
-rte_security_session_get_size(struct rte_security_ctx *instance);
+rte_security_session_get_size(void *instance);
/**
* Free security session header and the session private data and
@@ -742,7 +718,7 @@ rte_security_session_get_size(struct rte_security_ctx *instance);
* - other negative values in case of freeing private data errors.
*/
int
-rte_security_session_destroy(struct rte_security_ctx *instance, void *sess);
+rte_security_session_destroy(void *instance, void *sess);
/**
* @warning
@@ -761,7 +737,7 @@ rte_security_session_destroy(struct rte_security_ctx *instance, void *sess);
*/
__rte_experimental
int
-rte_security_macsec_sc_create(struct rte_security_ctx *instance,
+rte_security_macsec_sc_create(void *instance,
struct rte_security_macsec_sc *conf);
/**
@@ -780,7 +756,7 @@ rte_security_macsec_sc_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id,
+rte_security_macsec_sc_destroy(void *instance, uint16_t sc_id,
enum rte_security_macsec_direction dir);
/**
@@ -800,7 +776,7 @@ rte_security_macsec_sc_destroy(struct rte_security_ctx *instance, uint16_t sc_id
*/
__rte_experimental
int
-rte_security_macsec_sa_create(struct rte_security_ctx *instance,
+rte_security_macsec_sa_create(void *instance,
struct rte_security_macsec_sa *conf);
/**
@@ -819,7 +795,7 @@ rte_security_macsec_sa_create(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sa_destroy(struct rte_security_ctx *instance, uint16_t sa_id,
+rte_security_macsec_sa_destroy(void *instance, uint16_t sa_id,
enum rte_security_macsec_direction dir);
/** Device-specific metadata field type */
@@ -889,6 +865,27 @@ static inline bool rte_security_dynfield_is_registered(void)
return rte_security_dynfield_offset >= 0;
}
+#define RTE_SECURITY_CTX_FLAGS_OFF 4
+/**
+ * Get security flags from security instance.
+ */
+static inline uint32_t
+rte_security_ctx_flags_get(void *ctx)
+{
+ return *((uint32_t *)ctx + RTE_SECURITY_CTX_FLAGS_OFF);
+}
+
+/**
+ * Set security flags in security instance.
+ */
+static inline void
+rte_security_ctx_flags_set(void *ctx, uint32_t flags)
+{
+ uint32_t *data;
+ data = (((uint32_t *)ctx) + RTE_SECURITY_CTX_FLAGS_OFF);
+ *data = flags;
+}
+
#define RTE_SECURITY_SESS_OPAQUE_DATA_OFF 0
#define RTE_SECURITY_SESS_FAST_MDATA_OFF 1
/**
@@ -933,7 +930,7 @@ rte_security_session_fast_mdata_set(void *sess, uint64_t fdata)
/** Function to call PMD specific function pointer set_pkt_metadata() */
__rte_experimental
-int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
+int __rte_security_set_pkt_metadata(void *instance,
void *sess,
struct rte_mbuf *m, void *params);
@@ -951,12 +948,12 @@ int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
* - On failure, a negative value.
*/
static inline int
-rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
+rte_security_set_pkt_metadata(void *instance,
void *sess,
struct rte_mbuf *mb, void *params)
{
/* Fast Path */
- if (instance->flags & RTE_SEC_CTX_F_FAST_SET_MDATA) {
+ if (rte_security_ctx_flags_get(instance) & RTE_SEC_CTX_F_FAST_SET_MDATA) {
*rte_security_dynfield(mb) = (rte_security_dynfield_t)
rte_security_session_fast_mdata_get(sess);
return 0;
@@ -1105,7 +1102,7 @@ struct rte_security_stats {
*/
__rte_experimental
int
-rte_security_session_stats_get(struct rte_security_ctx *instance,
+rte_security_session_stats_get(void *instance,
void *sess,
struct rte_security_stats *stats);
@@ -1125,7 +1122,7 @@ rte_security_session_stats_get(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance,
+rte_security_macsec_sa_stats_get(void *instance,
uint16_t sa_id, enum rte_security_macsec_direction dir,
struct rte_security_macsec_sa_stats *stats);
@@ -1145,7 +1142,7 @@ rte_security_macsec_sa_stats_get(struct rte_security_ctx *instance,
*/
__rte_experimental
int
-rte_security_macsec_sc_stats_get(struct rte_security_ctx *instance,
+rte_security_macsec_sc_stats_get(void *instance,
uint16_t sc_id, enum rte_security_macsec_direction dir,
struct rte_security_macsec_sc_stats *stats);
@@ -1296,7 +1293,7 @@ struct rte_security_capability_idx {
* - Return NULL if no capabilities available.
*/
const struct rte_security_capability *
-rte_security_capabilities_get(struct rte_security_ctx *instance);
+rte_security_capabilities_get(void *instance);
/**
* Query if a specific capability is available on security instance
@@ -1310,7 +1307,7 @@ rte_security_capabilities_get(struct rte_security_ctx *instance);
* - Return NULL if the capability not matched on security instance.
*/
const struct rte_security_capability *
-rte_security_capability_get(struct rte_security_ctx *instance,
+rte_security_capability_get(void *instance,
struct rte_security_capability_idx *idx);
#ifdef __cplusplus
diff --git a/lib/security/rte_security_driver.h b/lib/security/rte_security_driver.h
index 1e6a6ef8e3..e5e1c4cfe8 100644
--- a/lib/security/rte_security_driver.h
+++ b/lib/security/rte_security_driver.h
@@ -37,6 +37,30 @@ struct rte_security_session {
/**< Private session material, variable size (depends on driver) */
};
+/**
+ * Security context for crypto/eth devices
+ *
+ * Security instance for each driver to register security operations.
+ * The application can get the security context from the crypto/eth device id
+ * using the APIs rte_cryptodev_get_sec_ctx()/rte_eth_dev_get_sec_ctx()
+ * This structure is used to identify the device(crypto/eth) for which the
+ * security operations need to be performed.
+ */
+struct rte_security_ctx {
+ void *device;
+ /**< Crypto/ethernet device attached */
+ const struct rte_security_ops *ops;
+ /**< Pointer to security ops for the device */
+ uint32_t flags;
+ /**< Flags for security context */
+ uint16_t sess_cnt;
+ /**< Number of sessions attached to this context */
+ uint16_t macsec_sc_cnt;
+ /**< Number of MACsec SC attached to this context */
+ uint16_t macsec_sa_cnt;
+ /**< Number of MACsec SA attached to this context */
+};
+
/**
* Helper macro to get driver private data
*/
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [PATCH v4 2/7] ethdev: support setting and querying RSS algorithm
2023-09-20 16:39 3% ` Ferruh Yigit
@ 2023-09-26 13:23 0% ` Jie Hai
0 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-09-26 13:23 UTC (permalink / raw)
To: Ferruh Yigit, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam; +Cc: lihuisong
On 2023/9/21 0:39, Ferruh Yigit wrote:
> On 9/8/2023 9:00 AM, Jie Hai wrote:
>> Currently, rte_eth_rss_conf supports configuring and querying
>> RSS hash functions, rss key and it's length, but not RSS hash
>> algorithm.
>>
>> The structure ``rte_eth_rss_conf`` is extended by adding a new
>> field "func". This represents the RSS algorithms to apply. The
>> following API will be affected:
>> - rte_eth_dev_configure
>> - rte_eth_dev_rss_hash_update
>> - rte_eth_dev_rss_hash_conf_get
>>
>
> The problem with adding new configuration fields is, none of the drivers
> are using it.
>
> I can see you are updating hns3 driver in next patch, but what about
> others, application will set this field and almost all drivers will
> ignore it for now.
> And in near future, some will be supporting it and some won't, still
> frustrating for the application perspective.
>
> In the past I was gathering list of these items and follow
> implementation of them with drivers, but as the number of drivers
> increased this became very hard to manage.
>
> Another way to manage this is go and update all drivers, and if the
> configuration requests anything other than
> 'RTE_ETH_HASH_FUNCTION_DEFAULT', return error. So that application can
> know this is not supported by this driver.
> Do you have better solution for this?
>
I know this may not be reasonable, how about adding new ops to
the query and configuration of the RSS algorithm?
>
>> If the value of "func" used for configuration is a gibberish
>> value, report the error and return. Do the same for
>> rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
>>
>> To check whether the drivers report the "func" field, it is set
>> to default value before querying.
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> ---
>> doc/guides/rel_notes/release_23_11.rst | 2 ++
>> lib/ethdev/rte_ethdev.c | 17 +++++++++++++++++
>> lib/ethdev/rte_ethdev.h | 21 +++++++++++++++++++++
>> lib/ethdev/rte_flow.c | 1 -
>> lib/ethdev/rte_flow.h | 22 ++--------------------
>> 5 files changed, 42 insertions(+), 21 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
>> index 333e1d95a283..deb019fbe4c1 100644
>> --- a/doc/guides/rel_notes/release_23_11.rst
>> +++ b/doc/guides/rel_notes/release_23_11.rst
>> @@ -129,6 +129,8 @@ ABI Changes
>> Also, make sure to start the actual text at the margin.
>> =======================================================
>>
>> +* ethdev: Added "func" field to ``rte_eth_rss_conf`` structure for RSS hash
>> + algorithm.
>>
>> Known Issues
>> ------------
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 0840d2b5942a..4cbcdb344cac 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -1445,6 +1445,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>> goto rollback;
>> }
>>
>> + if (dev_conf->rx_adv_conf.rss_conf.func >= RTE_ETH_HASH_FUNCTION_MAX) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Ethdev port_id=%u invalid rss hash function (%u)\n",
>> + port_id, dev_conf->rx_adv_conf.rss_conf.func);
>> + ret = -EINVAL;
>> + goto rollback;
>> + }
>> +
>> /* Check if Rx RSS distribution is disabled but RSS hash is enabled. */
>> if (((dev_conf->rxmode.mq_mode & RTE_ETH_MQ_RX_RSS_FLAG) == 0) &&
>> (dev_conf->rxmode.offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)) {
>> @@ -4630,6 +4638,13 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
>> return -ENOTSUP;
>> }
>>
>> + if (rss_conf->func >= RTE_ETH_HASH_FUNCTION_MAX) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Ethdev port_id=%u invalid rss hash function (%u)\n",
>> + port_id, rss_conf->func);
>> + return -EINVAL;
>> + }
>> +
>> if (*dev->dev_ops->rss_hash_update == NULL)
>> return -ENOTSUP;
>> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
>> @@ -4657,6 +4672,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
>> return -EINVAL;
>> }
>>
>> + rss_conf->func = RTE_ETH_HASH_FUNCTION_DEFAULT;
>> +
>>
>
> I think setting this in ethdev level is not required if you update all
> drivers to not accept anything other than DEFAULT.
>
>
I initialized this field to prevent some drivers from not reporting RSS
algorithms.
If an improper parameter is transferred before an API is invoked, the
query result will be incorrect.
>> if (*dev->dev_ops->rss_hash_conf_get == NULL)
>> return -ENOTSUP;
>> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
>> index 40cfbb7efddd..33cec3570f85 100644
>> --- a/lib/ethdev/rte_ethdev.h
>> +++ b/lib/ethdev/rte_ethdev.h
>> @@ -445,6 +445,26 @@ struct rte_vlan_filter_conf {
>> uint64_t ids[64];
>> };
>>
>> +/**
>> + * Hash function types.
>> + */
>> +enum rte_eth_hash_function {
>> + /**
>> + * DEFAULT means that conformance to a specific hash algorithm is
>> + * uncared to the caller. The driver can pick the one it deems optimal.
>> + */
>> + RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
>> + RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
>> + RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
>> + /**
>> + * Symmetric Toeplitz: src, dst will be replaced by
>> + * xor(src, dst). For the case with src/dst only,
>> + * src or dst address will xor with zero pair.
>> + */
>> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
>> + RTE_ETH_HASH_FUNCTION_MAX,
>
> As we are moving this to ethdev.h, when we want to add a new algorithm,
> it will cause ABI break because of the 'RTE_ETH_HASH_FUNCTION_MAX', and
> it will need to wait. Is there a way to eliminate this MAX enum?
>
How about assigning RTE_ETH_HASH_FUNCTION_MAX a larger value, e.g. 255 ?
>> +};
>> +
>> /**
>> * A structure used to configure the Receive Side Scaling (RSS) feature
>> * of an Ethernet port.
>> @@ -464,6 +484,7 @@ struct rte_eth_rss_conf {
>> * Supplying an *rss_hf* equal to zero disables the RSS feature.
>> */
>> uint64_t rss_hf;
>> + enum rte_eth_hash_function func; /**< Hash algorithm. */
>
> Can we use 'algorithm' as the field name?
>
> I know it won't exactly match type name (rte_eth_hash_function) but I
> think this will be more accurate also less confusing for "rss_hf (rss
> hash function)" and "func (function)"?
>
Considering the comprehensibility, I agree with the proposal.
>> };
>>
>> /*
>> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
>> index 271d854f7807..d3f2d466d841 100644
>> --- a/lib/ethdev/rte_flow.c
>> +++ b/lib/ethdev/rte_flow.c
>> @@ -12,7 +12,6 @@
>> #include <rte_branch_prediction.h>
>> #include <rte_string_fns.h>
>> #include <rte_mbuf_dyn.h>
>> -#include "rte_ethdev.h"
>> #include "rte_flow_driver.h"
>> #include "rte_flow.h"
>>
>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>> index 3bd0dc64fbe2..a7578b1d2eff 100644
>> --- a/lib/ethdev/rte_flow.h
>> +++ b/lib/ethdev/rte_flow.h
>> @@ -40,6 +40,8 @@
>> #include <rte_macsec.h>
>> #include <rte_ib.h>
>>
>> +#include "rte_ethdev.h"
>> +
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> @@ -3183,26 +3185,6 @@ struct rte_flow_query_count {
>> uint64_t bytes; /**< Number of bytes through this rule [out]. */
>> };
>>
>> -/**
>> - * Hash function types.
>> - */
>> -enum rte_eth_hash_function {
>> - /**
>> - * DEFAULT means that conformance to a specific hash algorithm is
>> - * uncared to the caller. The driver can pick the one it deems optimal.
>> - */
>> - RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
>> - RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
>> - RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
>> - /**
>> - * Symmetric Toeplitz: src, dst will be replaced by
>> - * xor(src, dst). For the case with src/dst only,
>> - * src or dst address will xor with zero pair.
>> - */
>> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
>> - RTE_ETH_HASH_FUNCTION_MAX,
>> -};
>> -
>> /**
>> * RTE_FLOW_ACTION_TYPE_RSS
>> *
>
> .
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/3] lib: introduce dispatcher library
@ 2023-09-27 8:13 3% ` Bruce Richardson
2023-09-28 7:44 0% ` Mattias Rönnblom
2023-10-03 17:31 0% ` Jerin Jacob
0 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2023-09-27 8:13 UTC (permalink / raw)
To: Jerin Jacob
Cc: Mattias Rönnblom, Mattias Rönnblom, dev, Jerin Jacob,
techboard, harry.van.haaren, Peter Nilsson, Heng Wang,
Naga Harish K S V, Pavan Nikhilesh, Gujjar Abhinandan S,
Erik Gabriel Carrillo, Shijith Thotton, Hemant Agrawal,
Sachin Saxena, Liang Ma, Peter Mccarthy, Zhirun Yan
On Tue, Sep 26, 2023 at 11:58:37PM +0530, Jerin Jacob wrote:
> On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> >
> > On 2023-09-22 09:38, Mattias Rönnblom wrote:
> >
> > <snip>
> >
> > > +int
> > > +rte_dispatcher_create(uint8_t id, uint8_t event_dev_id)
> > > +{
> >
> >
> > There are two changes I'm considering:
> >
> > 1) Removing the "id" to identify the dispatcher, replacing it with an
> > forward-declared rte_dispatcher struct pointer.
> >
> > struct rte_dispatcher;
> >
> > struct rte_dispatcher *
> > rte_dispatcher_create(uint8_t event_dev_id);
> >
> >
> > The original reason for using an integer id to identify a dispatcher is
> > to make it look like everything else in Eventdev. I find this pattern a
> > little awkward to use - in particular the fact the id is
> > application-allocated (and thus require coordination between different
> > part of the application in case multiple instances are used).
> >
> > 2) Adding a flags field to the create function "for future use". But
> > since the API is experimental, there may not be that much need to
> > attempt to be future-proof?
> >
> > Any thoughts are appreciated.
>
> IMO, better to have rte_dispatcher_create(struct
> rte_dispatch_create_params *params)
> for better future proofing with specific
> rte_dispatch_crearte_params_init() API(No need to add reserved fields
> in rte_dispatch_create_params now, may need only for before removing
> experimental status)
>
> Just 2c.
>
I don't like using structs in those cases, I'd much rather have a flags
parameter, as flags can be checked for explicit zeros for future proofing,
while a struct cannot be checked for extra space on the end for future
fields added.
Furthermore, if we need to add new parameters to the create function, I
actually believe it is better to add them as explicit parameters rather
than new fields to the struct. Struct fields can be missed by a user just
recompiling, while new function parameters will be flagged by the compiler
to make the user aware of the change. [There would be no change for ABI
compatibility as function versioning would be usable in both cases]
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-21 14:49 4% ` Stanisław Kardach
@ 2023-09-27 11:55 5% ` Ferruh Yigit
2023-09-27 13:48 4% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-27 11:55 UTC (permalink / raw)
To: Stanisław Kardach, Tummala, Sivaprasad
Cc: David Marchand, Ruifeng Wang, Min Zhou, David Christensen,
Bruce Richardson, Konstantin Ananyev, dev, Thomas Monjalon
On 9/21/2023 3:49 PM, Stanisław Kardach wrote:
> On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad
> <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>> wrote:
>
> [AMD Official Use Only - General]
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com
> <mailto:david.marchand@redhat.com>>
> > Sent: Wednesday, September 20, 2023 1:05 PM
> > To: Stanisław Kardach <kda@semihalf.com
> <mailto:kda@semihalf.com>>; Tummala, Sivaprasad
> > <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>
> > Cc: Ruifeng Wang <ruifeng.wang@arm.com
> <mailto:ruifeng.wang@arm.com>>; Min Zhou <zhoumin@loongson.cn
> <mailto:zhoumin@loongson.cn>>;
> > David Christensen <drc@linux.vnet.ibm.com
> <mailto:drc@linux.vnet.ibm.com>>; Bruce Richardson
> > <bruce.richardson@intel.com <mailto:bruce.richardson@intel.com>>;
> Konstantin Ananyev
> > <konstantin.v.ananyev@yandex.ru
> <mailto:konstantin.v.ananyev@yandex.ru>>; dev <dev@dpdk.org
> <mailto:dev@dpdk.org>>; Yigit, Ferruh
> > <Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>>; Thomas
> Monjalon <thomas@monjalon.net <mailto:thomas@monjalon.net>>
> > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
> >
> > Caution: This message originated from an External Source. Use
> proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach
> <kda@semihalf.com <mailto:kda@semihalf.com>> wrote:
> > >
> > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> > <david.marchand@redhat.com <mailto:david.marchand@redhat.com>> wrote:
> > > <snip>
> > > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS
> (what I call a
> > last element canary). Why? If you're concerned with ABI, then
> we're talking about
> > an application linking dynamically with DPDK or talking via some
> RPC channel with
> > another DPDK application. So clashing with this definition does
> not come into
> > question. One should rather use rte_cpu_get_flag_enabled().
> > > > > Also if you want to introduce new features, one would add
> them yo the
> > rte_cpuflags headers, unless you'd like to not add those and keep an
> > undocumented list "above" the last defined element.
> > > > > Could you explain a bit more Your use-case?
> > > >
> > > > Hey Stanislaw,
> > > >
> > > > Talking generically, one problem with such pattern (having a LAST,
> > > > or MAX enum) is when an array sized with such a symbol is exposed.
> > > > As I mentionned in the past, this can have unwanted effects:
> > > >
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> > > > -1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>
> >
> > Argh... who broke copy/paste in my browser ?!
> > Wrt to MAX and arrays, I wanted to point at:
> >
> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR>
> > TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>
> >
> > > I agree, though I'd argue "LAST" and "MAX" semantics are a bit
> different. "LAST"
> > delimits the known enumeration territory while "MAX" is more of a
> `constepxr`
> > value type.
> > > >
> > > > Another issue is when an existing enum meaning changes: from the
> > > > application pov, the (old) MAX value is incorrect, but for the
> > > > library pov, a new meaning has been associated.
> > > > This may trigger bugs in the application when calling a function
> > > > that returns such an enum which never return this MAX value in
> the past.
> > > >
> > > > For at least those two reasons, removing those canary elements is
> > > > being done in DPDK.
> > > >
> > > > This specific removal has been announced:
> > > >
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> > > > -1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>
> > > Thanks for pointing this out but did you mean to link to the
> patch again here?
> >
> > Sorry, same here, bad copy/paste :-(.
> >
> > The intended link is:
> https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>
> > The deprecation notice was badly formulated and this patch here is
> consistent with
> > it.
> >
> >
> > > >
> > > > Now, practically, when I look at the cpuflags API, I don't see us
> > > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this
> change
> > > > is unneeded.
> > > > But on the other hand, is it really an issue for an application to
> > > > lose this (internal) information?
> > > I doubt it, maybe it could be used as a sanity check for
> choosing proper functors
> > in the application. Though the initial description of the reason
> behind this patch was
> > to not break the ABI and I don't think it does that. What it does
> is enforces users to
> > use explicit cpu flag values which is a good thing. Though if so,
> then it should be
> > stated in the commit description.
> >
> > I agree.
> > Siva, can you work on a new revision?
> >
> David, Stanislaw,
>
> The original motivation of this patch was to avoid ABI breakage with
> the introduction of new CPU flag
> "RTE_CPUFLAG_MONITORX"
> (http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html>).
>
> Because of ABI breakage, the feature was postponed to this release.
> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/>
>
> This test is flawed, reason being that the NUMFLAGS should not be
> treated as a flag value and instead as a canary but this test is not
> taking into account.
>
Hi Stanislaw,
Why test is flawed?
The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum
item, and there are APIs using the enum, so the enum exchanged between
shared library and the application.
Similar thing discussed before and when enum exchanged between
application and shared library, there is an ABI breakage risk when enum
extended and general tendency is to eliminate the MAX value to reduce
the risk.
When enum value sent from library to application, it is more clear that
this can cause an ABI breakage, because application can receive a value
that it is not aware in the build time, which can cause unexpected behavior.
Simply think about a case application allocated array in
'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array index based
on returned enum item value, if the enum extended in the new version of
the shared library, this can cause invalid memory access in application.
When enum value sent from application to library, I am not quite sure
how problematic it is to be honest. Like being in the
'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question.
Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to
'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't
happen in new version of the shared library, not sure if this can cause
any problem for the application.
But as I mentioned, general guidance is to eliminate this kind of MAX
enum value usage.
And for this specific issue, although usage of the enum in
'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not
clear if it cause ABI breakage,
enum being embedded into the 'struct rte_bbdev_driver_info' struct
doesn't leave a question, since this struct is returned from library to
the application and change in the enum causes an ABI breakage.
Briefly, I think even appending to the end of 'enum rte_cpu_flag_t'
cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to extend
this enum in the future.
And an outstanding deprecation notice already exists for this:
https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63
> Your change did not break the ABI because you have properly added the
> new flag at the end.
> So I would ask to change the commit description to mention that NUMFLAGS
> is removed to:
> 1. Prevent users from treating it as a usable value or an array size.
> 2. Prevent false-positive failures in the ABI test.
>
> Also it would be good to link to the aforementioned ABI test failure to
> give readers some context when inspecting the git tree.
>
>
>
> Can you please add what exactly needs to be reworked in the new version.
>
> >
> > Thanks.
> >
> > --
> > David Marchand
>
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
@ 2023-09-27 13:13 0% ` Ferruh Yigit
2023-09-28 9:31 0% ` Tummala, Sivaprasad
2023-10-06 8:27 3% ` David Marchand
2 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-27 13:13 UTC (permalink / raw)
To: Sivaprasad Tummala, ruifeng.wang, zhoumin, drc, kda,
bruce.richardson, konstantin.v.ananyev
Cc: dev
On 8/11/2023 7:07 AM, Sivaprasad Tummala wrote:
> This patch removes RTE_CPUFLAG_NUMFLAGS to allow new CPU
> features without breaking ABI each time.
>
> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
> ---
> lib/eal/arm/include/rte_cpuflags_32.h | 1 -
> lib/eal/arm/include/rte_cpuflags_64.h | 1 -
> lib/eal/arm/rte_cpuflags.c | 7 +++++--
> lib/eal/loongarch/include/rte_cpuflags.h | 1 -
> lib/eal/loongarch/rte_cpuflags.c | 7 +++++--
> lib/eal/ppc/include/rte_cpuflags.h | 1 -
> lib/eal/ppc/rte_cpuflags.c | 7 +++++--
> lib/eal/riscv/include/rte_cpuflags.h | 1 -
> lib/eal/riscv/rte_cpuflags.c | 7 +++++--
> lib/eal/x86/include/rte_cpuflags.h | 1 -
> lib/eal/x86/rte_cpuflags.c | 7 +++++--
> 11 files changed, 25 insertions(+), 16 deletions(-)
>
Hi Sivaprasad,
Is the relevant deprecation notice removed somewhere, if not can you
please remove it in this set?
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 11:55 5% ` Ferruh Yigit
@ 2023-09-27 13:48 4% ` Stanisław Kardach
2023-09-27 14:09 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Stanisław Kardach @ 2023-09-27 13:48 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Tummala, Sivaprasad, David Marchand, Ruifeng Wang, Min Zhou,
David Christensen, Bruce Richardson, Konstantin Ananyev, dev,
Thomas Monjalon
On Wed, Sep 27, 2023 at 1:55 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 9/21/2023 3:49 PM, Stanisław Kardach wrote:
> > On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad
> > <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -----Original Message-----
> > > From: David Marchand <david.marchand@redhat.com
> > <mailto:david.marchand@redhat.com>>
> > > Sent: Wednesday, September 20, 2023 1:05 PM
> > > To: Stanisław Kardach <kda@semihalf.com
> > <mailto:kda@semihalf.com>>; Tummala, Sivaprasad
> > > <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>
> > > Cc: Ruifeng Wang <ruifeng.wang@arm.com
> > <mailto:ruifeng.wang@arm.com>>; Min Zhou <zhoumin@loongson.cn
> > <mailto:zhoumin@loongson.cn>>;
> > > David Christensen <drc@linux.vnet.ibm.com
> > <mailto:drc@linux.vnet.ibm.com>>; Bruce Richardson
> > > <bruce.richardson@intel.com <mailto:bruce.richardson@intel.com>>;
> > Konstantin Ananyev
> > > <konstantin.v.ananyev@yandex.ru
> > <mailto:konstantin.v.ananyev@yandex.ru>>; dev <dev@dpdk.org
> > <mailto:dev@dpdk.org>>; Yigit, Ferruh
> > > <Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>>; Thomas
> > Monjalon <thomas@monjalon.net <mailto:thomas@monjalon.net>>
> > > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
> > >
> > > Caution: This message originated from an External Source. Use
> > proper caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach
> > <kda@semihalf.com <mailto:kda@semihalf.com>> wrote:
> > > >
> > > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> > > <david.marchand@redhat.com <mailto:david.marchand@redhat.com>> wrote:
> > > > <snip>
> > > > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS
> > (what I call a
> > > last element canary). Why? If you're concerned with ABI, then
> > we're talking about
> > > an application linking dynamically with DPDK or talking via some
> > RPC channel with
> > > another DPDK application. So clashing with this definition does
> > not come into
> > > question. One should rather use rte_cpu_get_flag_enabled().
> > > > > > Also if you want to introduce new features, one would add
> > them yo the
> > > rte_cpuflags headers, unless you'd like to not add those and keep an
> > > undocumented list "above" the last defined element.
> > > > > > Could you explain a bit more Your use-case?
> > > > >
> > > > > Hey Stanislaw,
> > > > >
> > > > > Talking generically, one problem with such pattern (having a LAST,
> > > > > or MAX enum) is when an array sized with such a symbol is exposed.
> > > > > As I mentionned in the past, this can have unwanted effects:
> > > > >
> > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> > > > > -1-david.marchand@redhat.com/
> > <http://1-david.marchand@redhat.com/>
> > >
> > > Argh... who broke copy/paste in my browser ?!
> > > Wrt to MAX and arrays, I wanted to point at:
> > >
> > http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR>
> > > TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>
> > >
> > > > I agree, though I'd argue "LAST" and "MAX" semantics are a bit
> > different. "LAST"
> > > delimits the known enumeration territory while "MAX" is more of a
> > `constepxr`
> > > value type.
> > > > >
> > > > > Another issue is when an existing enum meaning changes: from the
> > > > > application pov, the (old) MAX value is incorrect, but for the
> > > > > library pov, a new meaning has been associated.
> > > > > This may trigger bugs in the application when calling a function
> > > > > that returns such an enum which never return this MAX value in
> > the past.
> > > > >
> > > > > For at least those two reasons, removing those canary elements is
> > > > > being done in DPDK.
> > > > >
> > > > > This specific removal has been announced:
> > > > >
> > https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> > <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> > > > > -1-david.marchand@redhat.com/
> > <http://1-david.marchand@redhat.com/>
> > > > Thanks for pointing this out but did you mean to link to the
> > patch again here?
> > >
> > > Sorry, same here, bad copy/paste :-(.
> > >
> > > The intended link is:
> > https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> > <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>
> > > The deprecation notice was badly formulated and this patch here is
> > consistent with
> > > it.
> > >
> > >
> > > > >
> > > > > Now, practically, when I look at the cpuflags API, I don't see us
> > > > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this
> > change
> > > > > is unneeded.
> > > > > But on the other hand, is it really an issue for an application to
> > > > > lose this (internal) information?
> > > > I doubt it, maybe it could be used as a sanity check for
> > choosing proper functors
> > > in the application. Though the initial description of the reason
> > behind this patch was
> > > to not break the ABI and I don't think it does that. What it does
> > is enforces users to
> > > use explicit cpu flag values which is a good thing. Though if so,
> > then it should be
> > > stated in the commit description.
> > >
> > > I agree.
> > > Siva, can you work on a new revision?
> > >
> > David, Stanislaw,
> >
> > The original motivation of this patch was to avoid ABI breakage with
> > the introduction of new CPU flag
> > "RTE_CPUFLAG_MONITORX"
> > (http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> > <http://mails.dpdk.org/archives/test-report/2023-April/382489.html>).
> >
> > Because of ABI breakage, the feature was postponed to this release.
> > https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/>
> >
> > This test is flawed, reason being that the NUMFLAGS should not be
> > treated as a flag value and instead as a canary but this test is not
> > taking into account.
> >
>
> Hi Stanislaw,
>
> Why test is flawed?
>
> The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum
> item, and there are APIs using the enum, so the enum exchanged between
> shared library and the application.
In a similar way lots of Linux uapi headers contain bits that should
not be used directly, even though they are defined there. The reason
for that is the C language syntax, not necessarily the intent of a
developer.
Since NUMFLAGS was a canary to make the flag handling code easier, it
should not be treated as a "real" value and hence my suggestion of a
flawed test. That said, NUMFLAGS does not bring enough value to not
remove it. :)
>
> Similar thing discussed before and when enum exchanged between
> application and shared library, there is an ABI breakage risk when enum
> extended and general tendency is to eliminate the MAX value to reduce
> the risk.
Agreed though as I have mentioned before, "MAX" has a different
semantics than "NUM". Then again since we have rte_cpu_feature_table,
we can RTE_DIM to check the user input.
>
>
> When enum value sent from library to application, it is more clear that
> this can cause an ABI breakage, because application can receive a value
> that it is not aware in the build time, which can cause unexpected behavior.
> Simply think about a case application allocated array in
> 'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array index based
> on returned enum item value, if the enum extended in the new version of
> the shared library, this can cause invalid memory access in application.
Using the NUM enum element (which serves as a last item canary) to
size an array is not a good idea unless it's returned from a runtime
call. Otherwise one hits issues that you've described.
>
> When enum value sent from application to library, I am not quite sure
> how problematic it is to be honest. Like being in the
> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question.
> Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to
> 'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't
> happen in new version of the shared library, not sure if this can cause
> any problem for the application.
> But as I mentioned, general guidance is to eliminate this kind of MAX
> enum value usage.
>
>
> And for this specific issue, although usage of the enum in
> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not
> clear if it cause ABI breakage,
> enum being embedded into the 'struct rte_bbdev_driver_info' struct
> doesn't leave a question, since this struct is returned from library to
> the application and change in the enum causes an ABI breakage.
Enum size does not change irrespective of changing its values. So
size-wise it's not an ABI breakage. Re-ordering values is an ABI
breakage.
>
>
> Briefly, I think even appending to the end of 'enum rte_cpu_flag_t'
> cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to extend
> this enum in the future.
> And an outstanding deprecation notice already exists for this:
> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63
>
>
> > Your change did not break the ABI because you have properly added the
> > new flag at the end.
> > So I would ask to change the commit description to mention that NUMFLAGS
> > is removed to:
> > 1. Prevent users from treating it as a usable value or an array size.
> > 2. Prevent false-positive failures in the ABI test.
> >
> > Also it would be good to link to the aforementioned ABI test failure to
> > give readers some context when inspecting the git tree.
> >
> >
> >
> > Can you please add what exactly needs to be reworked in the new version.
> >
> > >
> > > Thanks.
> > >
> > > --
> > > David Marchand
> >
>
--
Best Regards,
Stanisław Kardach
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 13:48 4% ` Stanisław Kardach
@ 2023-09-27 14:09 0% ` Ferruh Yigit
2023-09-27 15:03 0% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-09-27 14:09 UTC (permalink / raw)
To: Stanisław Kardach
Cc: Tummala, Sivaprasad, David Marchand, Ruifeng Wang, Min Zhou,
David Christensen, Bruce Richardson, Konstantin Ananyev, dev,
Thomas Monjalon
On 9/27/2023 2:48 PM, Stanisław Kardach wrote:
> On Wed, Sep 27, 2023 at 1:55 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>
>> On 9/21/2023 3:49 PM, Stanisław Kardach wrote:
>>> On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad
>>> <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>> wrote:
>>>
>>> [AMD Official Use Only - General]
>>>
>>> > -----Original Message-----
>>> > From: David Marchand <david.marchand@redhat.com
>>> <mailto:david.marchand@redhat.com>>
>>> > Sent: Wednesday, September 20, 2023 1:05 PM
>>> > To: Stanisław Kardach <kda@semihalf.com
>>> <mailto:kda@semihalf.com>>; Tummala, Sivaprasad
>>> > <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>
>>> > Cc: Ruifeng Wang <ruifeng.wang@arm.com
>>> <mailto:ruifeng.wang@arm.com>>; Min Zhou <zhoumin@loongson.cn
>>> <mailto:zhoumin@loongson.cn>>;
>>> > David Christensen <drc@linux.vnet.ibm.com
>>> <mailto:drc@linux.vnet.ibm.com>>; Bruce Richardson
>>> > <bruce.richardson@intel.com <mailto:bruce.richardson@intel.com>>;
>>> Konstantin Ananyev
>>> > <konstantin.v.ananyev@yandex.ru
>>> <mailto:konstantin.v.ananyev@yandex.ru>>; dev <dev@dpdk.org
>>> <mailto:dev@dpdk.org>>; Yigit, Ferruh
>>> > <Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>>; Thomas
>>> Monjalon <thomas@monjalon.net <mailto:thomas@monjalon.net>>
>>> > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
>>> >
>>> > Caution: This message originated from an External Source. Use
>>> proper caution
>>> > when opening attachments, clicking links, or responding.
>>> >
>>> >
>>> > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach
>>> <kda@semihalf.com <mailto:kda@semihalf.com>> wrote:
>>> > >
>>> > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
>>> > <david.marchand@redhat.com <mailto:david.marchand@redhat.com>> wrote:
>>> > > <snip>
>>> > > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS
>>> (what I call a
>>> > last element canary). Why? If you're concerned with ABI, then
>>> we're talking about
>>> > an application linking dynamically with DPDK or talking via some
>>> RPC channel with
>>> > another DPDK application. So clashing with this definition does
>>> not come into
>>> > question. One should rather use rte_cpu_get_flag_enabled().
>>> > > > > Also if you want to introduce new features, one would add
>>> them yo the
>>> > rte_cpuflags headers, unless you'd like to not add those and keep an
>>> > undocumented list "above" the last defined element.
>>> > > > > Could you explain a bit more Your use-case?
>>> > > >
>>> > > > Hey Stanislaw,
>>> > > >
>>> > > > Talking generically, one problem with such pattern (having a LAST,
>>> > > > or MAX enum) is when an array sized with such a symbol is exposed.
>>> > > > As I mentionned in the past, this can have unwanted effects:
>>> > > >
>>> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
>>> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
>>> > > > -1-david.marchand@redhat.com/
>>> <http://1-david.marchand@redhat.com/>
>>> >
>>> > Argh... who broke copy/paste in my browser ?!
>>> > Wrt to MAX and arrays, I wanted to point at:
>>> >
>>> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR>
>>> > TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>
>>> >
>>> > > I agree, though I'd argue "LAST" and "MAX" semantics are a bit
>>> different. "LAST"
>>> > delimits the known enumeration territory while "MAX" is more of a
>>> `constepxr`
>>> > value type.
>>> > > >
>>> > > > Another issue is when an existing enum meaning changes: from the
>>> > > > application pov, the (old) MAX value is incorrect, but for the
>>> > > > library pov, a new meaning has been associated.
>>> > > > This may trigger bugs in the application when calling a function
>>> > > > that returns such an enum which never return this MAX value in
>>> the past.
>>> > > >
>>> > > > For at least those two reasons, removing those canary elements is
>>> > > > being done in DPDK.
>>> > > >
>>> > > > This specific removal has been announced:
>>> > > >
>>> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
>>> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
>>> > > > -1-david.marchand@redhat.com/
>>> <http://1-david.marchand@redhat.com/>
>>> > > Thanks for pointing this out but did you mean to link to the
>>> patch again here?
>>> >
>>> > Sorry, same here, bad copy/paste :-(.
>>> >
>>> > The intended link is:
>>> https://git.dpdk.org/dpdk/commit/?id=5da7c13521
>>> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>
>>> > The deprecation notice was badly formulated and this patch here is
>>> consistent with
>>> > it.
>>> >
>>> >
>>> > > >
>>> > > > Now, practically, when I look at the cpuflags API, I don't see us
>>> > > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this
>>> change
>>> > > > is unneeded.
>>> > > > But on the other hand, is it really an issue for an application to
>>> > > > lose this (internal) information?
>>> > > I doubt it, maybe it could be used as a sanity check for
>>> choosing proper functors
>>> > in the application. Though the initial description of the reason
>>> behind this patch was
>>> > to not break the ABI and I don't think it does that. What it does
>>> is enforces users to
>>> > use explicit cpu flag values which is a good thing. Though if so,
>>> then it should be
>>> > stated in the commit description.
>>> >
>>> > I agree.
>>> > Siva, can you work on a new revision?
>>> >
>>> David, Stanislaw,
>>>
>>> The original motivation of this patch was to avoid ABI breakage with
>>> the introduction of new CPU flag
>>> "RTE_CPUFLAG_MONITORX"
>>> (http://mails.dpdk.org/archives/test-report/2023-April/382489.html
>>> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html>).
>>>
>>> Because of ABI breakage, the feature was postponed to this release.
>>> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/>
>>>
>>> This test is flawed, reason being that the NUMFLAGS should not be
>>> treated as a flag value and instead as a canary but this test is not
>>> taking into account.
>>>
>>
>> Hi Stanislaw,
>>
>> Why test is flawed?
>>
>> The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum
>> item, and there are APIs using the enum, so the enum exchanged between
>> shared library and the application.
> In a similar way lots of Linux uapi headers contain bits that should
> not be used directly, even though they are defined there. The reason
> for that is the C language syntax, not necessarily the intent of a
> developer.
> Since NUMFLAGS was a canary to make the flag handling code easier, it
> should not be treated as a "real" value and hence my suggestion of a
> flawed test. That said, NUMFLAGS does not bring enough value to not
> remove it. :)
>
Both it doesn't enough value to hang on, and we don't have control on
how it is used by the application once it is exposed by the library.
>>
>> Similar thing discussed before and when enum exchanged between
>> application and shared library, there is an ABI breakage risk when enum
>> extended and general tendency is to eliminate the MAX value to reduce
>> the risk.
> Agreed though as I have mentioned before, "MAX" has a different
> semantics than "NUM". Then again since we have rte_cpu_feature_table,
> we can RTE_DIM to check the user input.
>
Their usage and intention on having them is same I think, can you please
elaborate what is the difference between MAX and NUM enum items that is
added as last item in an enum?
>>
>>
>> When enum value sent from library to application, it is more clear that
>> this can cause an ABI breakage, because application can receive a value
>> that it is not aware in the build time, which can cause unexpected behavior.
>> Simply think about a case application allocated array in
>> 'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array index based
>> on returned enum item value, if the enum extended in the new version of
>> the shared library, this can cause invalid memory access in application.
> Using the NUM enum element (which serves as a last item canary) to
> size an array is not a good idea unless it's returned from a runtime
> call. Otherwise one hits issues that you've described.
>
I agree :), but that is a way to describe how it can be a problem.
Also last time I argued similar to what you said, that application
should check against MAX value before using it but I have been told
not to assume what application does. My take from it is, expect worst
from application as a library side developer.
>>
>> When enum value sent from application to library, I am not quite sure
>> how problematic it is to be honest. Like being in the
>> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question.
>> Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to
>> 'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't
>> happen in new version of the shared library, not sure if this can cause
>> any problem for the application.
>> But as I mentioned, general guidance is to eliminate this kind of MAX
>> enum value usage.
>>
>>
>> And for this specific issue, although usage of the enum in
>> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not
>> clear if it cause ABI breakage,
>> enum being embedded into the 'struct rte_bbdev_driver_info' struct
>> doesn't leave a question, since this struct is returned from library to
>> the application and change in the enum causes an ABI breakage.
> Enum size does not change irrespective of changing its values. So
> size-wise it's not an ABI breakage. Re-ordering values is an ABI
> breakage.>
Agree it is not size-wise issue. But still an issue.
>>
>>
>> Briefly, I think even appending to the end of 'enum rte_cpu_flag_t'
>> cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to extend
>> this enum in the future.
>> And an outstanding deprecation notice already exists for this:
>> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63
>>
>>
>>> Your change did not break the ABI because you have properly added the
>>> new flag at the end.
>>> So I would ask to change the commit description to mention that NUMFLAGS
>>> is removed to:
>>> 1. Prevent users from treating it as a usable value or an array size.
>>> 2. Prevent false-positive failures in the ABI test.
>>>
>>> Also it would be good to link to the aforementioned ABI test failure to
>>> give readers some context when inspecting the git tree.
>>>
>>>
>>>
>>> Can you please add what exactly needs to be reworked in the new version.
>>>
>>> >
>>> > Thanks.
>>> >
>>> > --
>>> > David Marchand
>>>
>>
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 14:09 0% ` Ferruh Yigit
@ 2023-09-27 15:03 0% ` Stanisław Kardach
2023-09-27 16:13 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Stanisław Kardach @ 2023-09-27 15:03 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Tummala, Sivaprasad, David Marchand, Ruifeng Wang, Min Zhou,
David Christensen, Bruce Richardson, Konstantin Ananyev, dev,
Thomas Monjalon
[-- Attachment #1: Type: text/plain, Size: 12535 bytes --]
On Wed, Sep 27, 2023, 16:09 Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> On 9/27/2023 2:48 PM, Stanisław Kardach wrote:
> > On Wed, Sep 27, 2023 at 1:55 PM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >>
> >> On 9/21/2023 3:49 PM, Stanisław Kardach wrote:
> >>> On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad
> >>> <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>
> wrote:
> >>>
> >>> [AMD Official Use Only - General]
> >>>
> >>> > -----Original Message-----
> >>> > From: David Marchand <david.marchand@redhat.com
> >>> <mailto:david.marchand@redhat.com>>
> >>> > Sent: Wednesday, September 20, 2023 1:05 PM
> >>> > To: Stanisław Kardach <kda@semihalf.com
> >>> <mailto:kda@semihalf.com>>; Tummala, Sivaprasad
> >>> > <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>
> >>> > Cc: Ruifeng Wang <ruifeng.wang@arm.com
> >>> <mailto:ruifeng.wang@arm.com>>; Min Zhou <zhoumin@loongson.cn
> >>> <mailto:zhoumin@loongson.cn>>;
> >>> > David Christensen <drc@linux.vnet.ibm.com
> >>> <mailto:drc@linux.vnet.ibm.com>>; Bruce Richardson
> >>> > <bruce.richardson@intel.com <mailto:bruce.richardson@intel.com
> >>;
> >>> Konstantin Ananyev
> >>> > <konstantin.v.ananyev@yandex.ru
> >>> <mailto:konstantin.v.ananyev@yandex.ru>>; dev <dev@dpdk.org
> >>> <mailto:dev@dpdk.org>>; Yigit, Ferruh
> >>> > <Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>>; Thomas
> >>> Monjalon <thomas@monjalon.net <mailto:thomas@monjalon.net>>
> >>> > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
> >>> >
> >>> > Caution: This message originated from an External Source. Use
> >>> proper caution
> >>> > when opening attachments, clicking links, or responding.
> >>> >
> >>> >
> >>> > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach
> >>> <kda@semihalf.com <mailto:kda@semihalf.com>> wrote:
> >>> > >
> >>> > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> >>> > <david.marchand@redhat.com <mailto:david.marchand@redhat.com>>
> wrote:
> >>> > > <snip>
> >>> > > > > Also I see you're still removing the RTE_CPUFLAG_NUMFLAGS
> >>> (what I call a
> >>> > last element canary). Why? If you're concerned with ABI, then
> >>> we're talking about
> >>> > an application linking dynamically with DPDK or talking via some
> >>> RPC channel with
> >>> > another DPDK application. So clashing with this definition does
> >>> not come into
> >>> > question. One should rather use rte_cpu_get_flag_enabled().
> >>> > > > > Also if you want to introduce new features, one would add
> >>> them yo the
> >>> > rte_cpuflags headers, unless you'd like to not add those and
> keep an
> >>> > undocumented list "above" the last defined element.
> >>> > > > > Could you explain a bit more Your use-case?
> >>> > > >
> >>> > > > Hey Stanislaw,
> >>> > > >
> >>> > > > Talking generically, one problem with such pattern (having a
> LAST,
> >>> > > > or MAX enum) is when an array sized with such a symbol is
> exposed.
> >>> > > > As I mentionned in the past, this can have unwanted effects:
> >>> > > >
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> >>> <
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> >>> > > > -1-david.marchand@redhat.com/
> >>> <http://1-david.marchand@redhat.com/>
> >>> >
> >>> > Argh... who broke copy/paste in my browser ?!
> >>> > Wrt to MAX and arrays, I wanted to point at:
> >>> >
> >>>
> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR
> <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR
> >
> >>> > TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>
> >>> >
> >>> > > I agree, though I'd argue "LAST" and "MAX" semantics are a bit
> >>> different. "LAST"
> >>> > delimits the known enumeration territory while "MAX" is more of a
> >>> `constepxr`
> >>> > value type.
> >>> > > >
> >>> > > > Another issue is when an existing enum meaning changes: from
> the
> >>> > > > application pov, the (old) MAX value is incorrect, but for
> the
> >>> > > > library pov, a new meaning has been associated.
> >>> > > > This may trigger bugs in the application when calling a
> function
> >>> > > > that returns such an enum which never return this MAX value
> in
> >>> the past.
> >>> > > >
> >>> > > > For at least those two reasons, removing those canary
> elements is
> >>> > > > being done in DPDK.
> >>> > > >
> >>> > > > This specific removal has been announced:
> >>> > > >
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493
> >>> <
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> >>> > > > -1-david.marchand@redhat.com/
> >>> <http://1-david.marchand@redhat.com/>
> >>> > > Thanks for pointing this out but did you mean to link to the
> >>> patch again here?
> >>> >
> >>> > Sorry, same here, bad copy/paste :-(.
> >>> >
> >>> > The intended link is:
> >>> https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> >>> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>
> >>> > The deprecation notice was badly formulated and this patch here
> is
> >>> consistent with
> >>> > it.
> >>> >
> >>> >
> >>> > > >
> >>> > > > Now, practically, when I look at the cpuflags API, I don't
> see us
> >>> > > > exposed to those two issues wrt rte_cpu_flag_t, so maybe this
> >>> change
> >>> > > > is unneeded.
> >>> > > > But on the other hand, is it really an issue for an
> application to
> >>> > > > lose this (internal) information?
> >>> > > I doubt it, maybe it could be used as a sanity check for
> >>> choosing proper functors
> >>> > in the application. Though the initial description of the reason
> >>> behind this patch was
> >>> > to not break the ABI and I don't think it does that. What it does
> >>> is enforces users to
> >>> > use explicit cpu flag values which is a good thing. Though if so,
> >>> then it should be
> >>> > stated in the commit description.
> >>> >
> >>> > I agree.
> >>> > Siva, can you work on a new revision?
> >>> >
> >>> David, Stanislaw,
> >>>
> >>> The original motivation of this patch was to avoid ABI breakage
> with
> >>> the introduction of new CPU flag
> >>> "RTE_CPUFLAG_MONITORX"
> >>> (http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> >>> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> >).
> >>>
> >>> Because of ABI breakage, the feature was postponed to this release.
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/
> <
> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/
> >
> >>>
> >>> This test is flawed, reason being that the NUMFLAGS should not be
> >>> treated as a flag value and instead as a canary but this test is not
> >>> taking into account.
> >>>
> >>
> >> Hi Stanislaw,
> >>
> >> Why test is flawed?
> >>
> >> The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum
> >> item, and there are APIs using the enum, so the enum exchanged between
> >> shared library and the application.
> > In a similar way lots of Linux uapi headers contain bits that should
> > not be used directly, even though they are defined there. The reason
> > for that is the C language syntax, not necessarily the intent of a
> > developer.
> > Since NUMFLAGS was a canary to make the flag handling code easier, it
> > should not be treated as a "real" value and hence my suggestion of a
> > flawed test. That said, NUMFLAGS does not bring enough value to not
> > remove it. :)
> >
>
> Both it doesn't enough value to hang on, and we don't have control on
> how it is used by the application once it is exposed by the library.
>
>
> >>
> >> Similar thing discussed before and when enum exchanged between
> >> application and shared library, there is an ABI breakage risk when enum
> >> extended and general tendency is to eliminate the MAX value to reduce
> >> the risk.
> > Agreed though as I have mentioned before, "MAX" has a different
> > semantics than "NUM". Then again since we have rte_cpu_feature_table,
> > we can RTE_DIM to check the user input.
> >
>
> Their usage and intention on having them is same I think, can you please
> elaborate what is the difference between MAX and NUM enum items that is
> added as last item in an enum?
>
MAX specifies a semantic numerical value, such as MTU. NUM counts elements
in an enumeration where elements describe some items and their value is
just an implementation detail.
>
>
> >>
> >>
> >> When enum value sent from library to application, it is more clear that
> >> this can cause an ABI breakage, because application can receive a value
> >> that it is not aware in the build time, which can cause unexpected
> behavior.
> >> Simply think about a case application allocated array in
> >> 'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array index based
> >> on returned enum item value, if the enum extended in the new version of
> >> the shared library, this can cause invalid memory access in application.
> > Using the NUM enum element (which serves as a last item canary) to
> > size an array is not a good idea unless it's returned from a runtime
> > call. Otherwise one hits issues that you've described.
> >
>
> I agree :), but that is a way to describe how it can be a problem.
> Also last time I argued similar to what you said, that application
> should check against MAX value before using it but I have been told
> not to assume what application does. My take from it is, expect worst
> from application as a library side developer.
>
>
> >>
> >> When enum value sent from application to library, I am not quite sure
> >> how problematic it is to be honest. Like being in the
> >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question.
> >> Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to
> >> 'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't
> >> happen in new version of the shared library, not sure if this can cause
> >> any problem for the application.
> >> But as I mentioned, general guidance is to eliminate this kind of MAX
> >> enum value usage.
> >>
> >>
> >> And for this specific issue, although usage of the enum in
> >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not
> >> clear if it cause ABI breakage,
> >> enum being embedded into the 'struct rte_bbdev_driver_info' struct
> >> doesn't leave a question, since this struct is returned from library to
> >> the application and change in the enum causes an ABI breakage.
> > Enum size does not change irrespective of changing its values. So
> > size-wise it's not an ABI breakage. Re-ordering values is an ABI
> > breakage.>
>
> Agree it is not size-wise issue. But still an issue.
>
>
> >>
> >>
> >> Briefly, I think even appending to the end of 'enum rte_cpu_flag_t'
> >> cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to extend
> >> this enum in the future.
> >> And an outstanding deprecation notice already exists for this:
> >>
> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63
> >>
> >>
> >>> Your change did not break the ABI because you have properly added the
> >>> new flag at the end.
> >>> So I would ask to change the commit description to mention that
> NUMFLAGS
> >>> is removed to:
> >>> 1. Prevent users from treating it as a usable value or an array size.
> >>> 2. Prevent false-positive failures in the ABI test.
> >>>
> >>> Also it would be good to link to the aforementioned ABI test failure to
> >>> give readers some context when inspecting the git tree.
> >>>
> >>>
> >>>
> >>> Can you please add what exactly needs to be reworked in the new
> version.
> >>>
> >>> >
> >>> > Thanks.
> >>> >
> >>> > --
> >>> > David Marchand
> >>>
> >>
> >
> >
>
>
[-- Attachment #2: Type: text/html, Size: 21051 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 15:03 0% ` Stanisław Kardach
@ 2023-09-27 16:13 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-09-27 16:13 UTC (permalink / raw)
To: Stanisław Kardach
Cc: Tummala, Sivaprasad, David Marchand, Ruifeng Wang, Min Zhou,
David Christensen, Bruce Richardson, Konstantin Ananyev, dev,
Thomas Monjalon
On 9/27/2023 4:03 PM, Stanisław Kardach wrote:
>
>
> On Wed, Sep 27, 2023, 16:09 Ferruh Yigit <ferruh.yigit@amd.com
> <mailto:ferruh.yigit@amd.com>> wrote:
>
> On 9/27/2023 2:48 PM, Stanisław Kardach wrote:
> > On Wed, Sep 27, 2023 at 1:55 PM Ferruh Yigit <ferruh.yigit@amd.com
> <mailto:ferruh.yigit@amd.com>> wrote:
> >>
> >> On 9/21/2023 3:49 PM, Stanisław Kardach wrote:
> >>> On Thu, Sep 21, 2023, 15:18 Tummala, Sivaprasad
> >>> <Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>
> <mailto:Sivaprasad.Tummala@amd.com
> <mailto:Sivaprasad.Tummala@amd.com>>> wrote:
> >>>
> >>> [AMD Official Use Only - General]
> >>>
> >>> > -----Original Message-----
> >>> > From: David Marchand <david.marchand@redhat.com
> <mailto:david.marchand@redhat.com>
> >>> <mailto:david.marchand@redhat.com
> <mailto:david.marchand@redhat.com>>>
> >>> > Sent: Wednesday, September 20, 2023 1:05 PM
> >>> > To: Stanisław Kardach <kda@semihalf.com
> <mailto:kda@semihalf.com>
> >>> <mailto:kda@semihalf.com <mailto:kda@semihalf.com>>>;
> Tummala, Sivaprasad
> >>> > <Sivaprasad.Tummala@amd.com
> <mailto:Sivaprasad.Tummala@amd.com>
> <mailto:Sivaprasad.Tummala@amd.com <mailto:Sivaprasad.Tummala@amd.com>>>
> >>> > Cc: Ruifeng Wang <ruifeng.wang@arm.com
> <mailto:ruifeng.wang@arm.com>
> >>> <mailto:ruifeng.wang@arm.com
> <mailto:ruifeng.wang@arm.com>>>; Min Zhou <zhoumin@loongson.cn
> <mailto:zhoumin@loongson.cn>
> >>> <mailto:zhoumin@loongson.cn <mailto:zhoumin@loongson.cn>>>;
> >>> > David Christensen <drc@linux.vnet.ibm.com
> <mailto:drc@linux.vnet.ibm.com>
> >>> <mailto:drc@linux.vnet.ibm.com
> <mailto:drc@linux.vnet.ibm.com>>>; Bruce Richardson
> >>> > <bruce.richardson@intel.com
> <mailto:bruce.richardson@intel.com>
> <mailto:bruce.richardson@intel.com
> <mailto:bruce.richardson@intel.com>>>;
> >>> Konstantin Ananyev
> >>> > <konstantin.v.ananyev@yandex.ru
> <mailto:konstantin.v.ananyev@yandex.ru>
> >>> <mailto:konstantin.v.ananyev@yandex.ru
> <mailto:konstantin.v.ananyev@yandex.ru>>>; dev <dev@dpdk.org
> <mailto:dev@dpdk.org>
> >>> <mailto:dev@dpdk.org <mailto:dev@dpdk.org>>>; Yigit, Ferruh
> >>> > <Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>
> <mailto:Ferruh.Yigit@amd.com <mailto:Ferruh.Yigit@amd.com>>>; Thomas
> >>> Monjalon <thomas@monjalon.net <mailto:thomas@monjalon.net>
> <mailto:thomas@monjalon.net <mailto:thomas@monjalon.net>>>
> >>> > Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
> >>> >
> >>> > Caution: This message originated from an External Source. Use
> >>> proper caution
> >>> > when opening attachments, clicking links, or responding.
> >>> >
> >>> >
> >>> > On Wed, Sep 20, 2023 at 8:01 AM Stanisław Kardach
> >>> <kda@semihalf.com <mailto:kda@semihalf.com>
> <mailto:kda@semihalf.com <mailto:kda@semihalf.com>>> wrote:
> >>> > >
> >>> > > On Tue, Sep 19, 2023 at 4:47 PM David Marchand
> >>> > <david.marchand@redhat.com
> <mailto:david.marchand@redhat.com> <mailto:david.marchand@redhat.com
> <mailto:david.marchand@redhat.com>>> wrote:
> >>> > > <snip>
> >>> > > > > Also I see you're still removing the
> RTE_CPUFLAG_NUMFLAGS
> >>> (what I call a
> >>> > last element canary). Why? If you're concerned with ABI, then
> >>> we're talking about
> >>> > an application linking dynamically with DPDK or talking
> via some
> >>> RPC channel with
> >>> > another DPDK application. So clashing with this definition
> does
> >>> not come into
> >>> > question. One should rather use rte_cpu_get_flag_enabled().
> >>> > > > > Also if you want to introduce new features, one
> would add
> >>> them yo the
> >>> > rte_cpuflags headers, unless you'd like to not add those
> and keep an
> >>> > undocumented list "above" the last defined element.
> >>> > > > > Could you explain a bit more Your use-case?
> >>> > > >
> >>> > > > Hey Stanislaw,
> >>> > > >
> >>> > > > Talking generically, one problem with such pattern
> (having a LAST,
> >>> > > > or MAX enum) is when an array sized with such a symbol
> is exposed.
> >>> > > > As I mentionned in the past, this can have unwanted
> effects:
> >>> > > >
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> >>>
> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>>
> >>> > > > -1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>
> >>> <http://1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>>
> >>> >
> >>> > Argh... who broke copy/paste in my browser ?!
> >>> > Wrt to MAX and arrays, I wanted to point at:
> >>> >
> >>>
> http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR> <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR <http://inbox.dpdk.org/dev/CAJFAV8xs5CVdE2xwRtaxk5vE_PiQMV5LY5tKStk3R1gOuR>>
> >>> > TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>
> <http://TsUw@mail.gmail.com/ <http://TsUw@mail.gmail.com/>>
> >>> >
> >>> > > I agree, though I'd argue "LAST" and "MAX" semantics are
> a bit
> >>> different. "LAST"
> >>> > delimits the known enumeration territory while "MAX" is
> more of a
> >>> `constepxr`
> >>> > value type.
> >>> > > >
> >>> > > > Another issue is when an existing enum meaning
> changes: from the
> >>> > > > application pov, the (old) MAX value is incorrect, but
> for the
> >>> > > > library pov, a new meaning has been associated.
> >>> > > > This may trigger bugs in the application when calling
> a function
> >>> > > > that returns such an enum which never return this MAX
> value in
> >>> the past.
> >>> > > >
> >>> > > > For at least those two reasons, removing those canary
> elements is
> >>> > > > being done in DPDK.
> >>> > > >
> >>> > > > This specific removal has been announced:
> >>> > > >
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>
> >>>
> <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493 <https://patchwork.dpdk.org/project/dpdk/patch/20230919140430.3251493>>
> >>> > > > -1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>
> >>> <http://1-david.marchand@redhat.com/
> <http://1-david.marchand@redhat.com/>>
> >>> > > Thanks for pointing this out but did you mean to link to the
> >>> patch again here?
> >>> >
> >>> > Sorry, same here, bad copy/paste :-(.
> >>> >
> >>> > The intended link is:
> >>> https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>
> >>> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521
> <https://git.dpdk.org/dpdk/commit/?id=5da7c13521>>
> >>> > The deprecation notice was badly formulated and this patch
> here is
> >>> consistent with
> >>> > it.
> >>> >
> >>> >
> >>> > > >
> >>> > > > Now, practically, when I look at the cpuflags API, I
> don't see us
> >>> > > > exposed to those two issues wrt rte_cpu_flag_t, so
> maybe this
> >>> change
> >>> > > > is unneeded.
> >>> > > > But on the other hand, is it really an issue for an
> application to
> >>> > > > lose this (internal) information?
> >>> > > I doubt it, maybe it could be used as a sanity check for
> >>> choosing proper functors
> >>> > in the application. Though the initial description of the
> reason
> >>> behind this patch was
> >>> > to not break the ABI and I don't think it does that. What
> it does
> >>> is enforces users to
> >>> > use explicit cpu flag values which is a good thing. Though
> if so,
> >>> then it should be
> >>> > stated in the commit description.
> >>> >
> >>> > I agree.
> >>> > Siva, can you work on a new revision?
> >>> >
> >>> David, Stanislaw,
> >>>
> >>> The original motivation of this patch was to avoid ABI
> breakage with
> >>> the introduction of new CPU flag
> >>> "RTE_CPUFLAG_MONITORX"
> >>>
> (http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html>
> >>>
> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html
> <http://mails.dpdk.org/archives/test-report/2023-April/382489.html>>).
> >>>
> >>> Because of ABI breakage, the feature was postponed to this
> release.
> >>>
> https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/> <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/ <https://patchwork.dpdk.org/project/dpdk/patch/20230413115334.43172-3-sivaprasad.tummala@amd.com/>>
> >>>
> >>> This test is flawed, reason being that the NUMFLAGS should not be
> >>> treated as a flag value and instead as a canary but this test is not
> >>> taking into account.
> >>>
> >>
> >> Hi Stanislaw,
> >>
> >> Why test is flawed?
> >>
> >> The enum in in the public header, so the 'RTE_CPUFLAG_NUMFLAGS' enum
> >> item, and there are APIs using the enum, so the enum exchanged
> between
> >> shared library and the application.
> > In a similar way lots of Linux uapi headers contain bits that should
> > not be used directly, even though they are defined there. The reason
> > for that is the C language syntax, not necessarily the intent of a
> > developer.
> > Since NUMFLAGS was a canary to make the flag handling code easier, it
> > should not be treated as a "real" value and hence my suggestion of a
> > flawed test. That said, NUMFLAGS does not bring enough value to not
> > remove it. :)
> >
>
> Both it doesn't enough value to hang on, and we don't have control on
> how it is used by the application once it is exposed by the library.
>
>
> >>
> >> Similar thing discussed before and when enum exchanged between
> >> application and shared library, there is an ABI breakage risk
> when enum
> >> extended and general tendency is to eliminate the MAX value to reduce
> >> the risk.
> > Agreed though as I have mentioned before, "MAX" has a different
> > semantics than "NUM". Then again since we have rte_cpu_feature_table,
> > we can RTE_DIM to check the user input.
> >
>
> Their usage and intention on having them is same I think, can you please
> elaborate what is the difference between MAX and NUM enum items that is
> added as last item in an enum?
>
> MAX specifies a semantic numerical value, such as MTU. NUM counts
> elements in an enumeration where elements describe some items and their
> value is just an implementation detail.
>
>
Ahh, I see your point now.
Most of the times, in enums, last item with name MAX is indeed used as
count of elements more than maximum semantic value, and sometimes LAST
is used for the same. So we are using them interchangeably with NUM.
I agree, for a MAX value as you are referring semantics is different,
but the one mentioned in this context is not an instance for that case.
>
> >>
> >>
> >> When enum value sent from library to application, it is more
> clear that
> >> this can cause an ABI breakage, because application can receive a
> value
> >> that it is not aware in the build time, which can cause
> unexpected behavior.
> >> Simply think about a case application allocated array in
> >> 'RTE_CPUFLAG_NUMFLAGS' size and directly accessing the array
> index based
> >> on returned enum item value, if the enum extended in the new
> version of
> >> the shared library, this can cause invalid memory access in
> application.
> > Using the NUM enum element (which serves as a last item canary) to
> > size an array is not a good idea unless it's returned from a runtime
> > call. Otherwise one hits issues that you've described.
> >
>
> I agree :), but that is a way to describe how it can be a problem.
> Also last time I argued similar to what you said, that application
> should check against MAX value before using it but I have been told
> not to assume what application does. My take from it is, expect worst
> from application as a library side developer.
>
>
> >>
> >> When enum value sent from application to library, I am not quite sure
> >> how problematic it is to be honest. Like being in the
> >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' in question.
> >> Only when application sends 'RTE_CPUFLAG_NUMFLAGS' to
> >> 'rte_cpu_get_flag_name()', it expects a NULL returned, but this won't
> >> happen in new version of the shared library, not sure if this can
> cause
> >> any problem for the application.
> >> But as I mentioned, general guidance is to eliminate this kind of MAX
> >> enum value usage.
> >>
> >>
> >> And for this specific issue, although usage of the enum in
> >> 'rte_cpu_get_flag_enabled()' & 'rte_cpu_get_flag_name()' APIs is not
> >> clear if it cause ABI breakage,
> >> enum being embedded into the 'struct rte_bbdev_driver_info' struct
> >> doesn't leave a question, since this struct is returned from
> library to
> >> the application and change in the enum causes an ABI breakage.
> > Enum size does not change irrespective of changing its values. So
> > size-wise it's not an ABI breakage. Re-ordering values is an ABI
> > breakage.>
>
> Agree it is not size-wise issue. But still an issue.
>
>
> >>
> >>
> >> Briefly, I think even appending to the end of 'enum rte_cpu_flag_t'
> >> cause ABI breakage and removing 'RTE_CPUFLAG_NUMFLAGS' helps to
> extend
> >> this enum in the future.
> >> And an outstanding deprecation notice already exists for this:
> >>
> https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63 <https://git.dpdk.org/dpdk/tree/doc/guides/rel_notes/deprecation.rst?h=v23.07#n63>
> >>
> >>
> >>> Your change did not break the ABI because you have properly
> added the
> >>> new flag at the end.
> >>> So I would ask to change the commit description to mention that
> NUMFLAGS
> >>> is removed to:
> >>> 1. Prevent users from treating it as a usable value or an array
> size.
> >>> 2. Prevent false-positive failures in the ABI test.
> >>>
> >>> Also it would be good to link to the aforementioned ABI test
> failure to
> >>> give readers some context when inspecting the git tree.
> >>>
> >>>
> >>>
> >>> Can you please add what exactly needs to be reworked in the
> new version.
> >>>
> >>> >
> >>> > Thanks.
> >>> >
> >>> > --
> >>> > David Marchand
> >>>
> >>
> >
> >
>
^ permalink raw reply [relevance 0%]
* [PATCH v3 4/4] mldev: update release notes for 23.11
@ 2023-09-27 18:11 4% ` Srikanth Yalavarthi
0 siblings, 0 replies; 200+ results
From: Srikanth Yalavarthi @ 2023-09-27 18:11 UTC (permalink / raw)
Cc: dev, syalavarthi, sshankarnara, aprabhu, ptakkar
Updated 23.11 release notes for mldev spec.
Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
---
doc/guides/rel_notes/release_23_11.rst | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 9746809a66..ca31ac5985 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -41,6 +41,11 @@ DPDK Release 23.11
New Features
------------
+ * **Added support for models with multiple I/O in mldev library.**
+
+ Added support in mldev library for models with multiple inputs and outputs.
+
+
.. This section should contain new features added in this release.
Sample format:
@@ -97,6 +102,8 @@ Removed Items
* kni: Removed the Kernel Network Interface (KNI) library and driver.
+* mldev: Removed APIs ``rte_ml_io_input_size_get`` and ``rte_ml_io_output_size_get``.
+
API Changes
-----------
@@ -119,6 +126,14 @@ API Changes
except ``rte_thread_setname()`` and ``rte_ctrl_thread_create()`` which are
replaced with ``rte_thread_set_name()`` and ``rte_thread_create_control()``.
+* mldev: Updated mldev API to support models with multiple inputs and outputs.
+ Updated the structure ``rte_ml_model_info`` to support input and output with
+ arbitrary shapes. Introduced support for ``rte_ml_io_layout``. Two layout types
+ split and packed are supported by the specification, which enables higher
+ control in handling models with multiple inputs and outputs. Updated ``rte_ml_op``,
+ ``rte_ml_io_quantize`` and ``rte_ml_io_dequantize`` to support an array of
+ ``rte_ml_buff_seg`` for inputs and outputs and removed use of batches argument.
+
ABI Changes
-----------
--
2.41.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 1/3] lib: introduce dispatcher library
2023-09-27 8:13 3% ` Bruce Richardson
@ 2023-09-28 7:44 0% ` Mattias Rönnblom
2023-10-03 17:31 0% ` Jerin Jacob
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2023-09-28 7:44 UTC (permalink / raw)
To: Bruce Richardson, Jerin Jacob
Cc: Mattias Rönnblom, dev, Jerin Jacob, techboard,
harry.van.haaren, Peter Nilsson, Heng Wang, Naga Harish K S V,
Pavan Nikhilesh, Gujjar Abhinandan S, Erik Gabriel Carrillo,
Shijith Thotton, Hemant Agrawal, Sachin Saxena, Liang Ma,
Peter Mccarthy, Zhirun Yan
On 2023-09-27 10:13, Bruce Richardson wrote:
> On Tue, Sep 26, 2023 at 11:58:37PM +0530, Jerin Jacob wrote:
>> On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom <hofors@lysator.liu.se> wrote:
>>>
>>> On 2023-09-22 09:38, Mattias Rönnblom wrote:
>>>
>>> <snip>
>>>
>>>> +int
>>>> +rte_dispatcher_create(uint8_t id, uint8_t event_dev_id)
>>>> +{
>>>
>>>
>>> There are two changes I'm considering:
>>>
>>> 1) Removing the "id" to identify the dispatcher, replacing it with an
>>> forward-declared rte_dispatcher struct pointer.
>>>
>>> struct rte_dispatcher;
>>>
>>> struct rte_dispatcher *
>>> rte_dispatcher_create(uint8_t event_dev_id);
>>>
>>>
>>> The original reason for using an integer id to identify a dispatcher is
>>> to make it look like everything else in Eventdev. I find this pattern a
>>> little awkward to use - in particular the fact the id is
>>> application-allocated (and thus require coordination between different
>>> part of the application in case multiple instances are used).
>>>
>>> 2) Adding a flags field to the create function "for future use". But
>>> since the API is experimental, there may not be that much need to
>>> attempt to be future-proof?
>>>
>>> Any thoughts are appreciated.
>>
>> IMO, better to have rte_dispatcher_create(struct
>> rte_dispatch_create_params *params)
>> for better future proofing with specific
>> rte_dispatch_crearte_params_init() API(No need to add reserved fields
>> in rte_dispatch_create_params now, may need only for before removing
>> experimental status)
>>
>> Just 2c.
>>
>
> I don't like using structs in those cases, I'd much rather have a flags
> parameter, as flags can be checked for explicit zeros for future proofing,
> while a struct cannot be checked for extra space on the end for future
> fields added.
>
> Furthermore, if we need to add new parameters to the create function, I
> actually believe it is better to add them as explicit parameters rather
> than new fields to the struct. Struct fields can be missed by a user just
> recompiling, while new function parameters will be flagged by the compiler
> to make the user aware of the change. [There would be no change for ABI
> compatibility as function versioning would be usable in both cases]
>
I will just have the create() function take the eventdev id, only, and
thus make no attempt at "future-proofing". Then we will see what the
future holds; flags, function parameters, or function parameters packed
into structs.
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 13:13 0% ` Ferruh Yigit
@ 2023-09-28 9:31 0% ` Tummala, Sivaprasad
0 siblings, 0 replies; 200+ results
From: Tummala, Sivaprasad @ 2023-09-28 9:31 UTC (permalink / raw)
To: Yigit, Ferruh, ruifeng.wang, zhoumin, drc, kda, bruce.richardson,
konstantin.v.ananyev
Cc: dev
[AMD Official Use Only - General]
> -----Original Message-----
> From: Yigit, Ferruh <Ferruh.Yigit@amd.com>
> Sent: Wednesday, September 27, 2023 6:44 PM
> To: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>;
> ruifeng.wang@arm.com; zhoumin@loongson.cn; drc@linux.vnet.ibm.com;
> kda@semihalf.com; bruce.richardson@intel.com; konstantin.v.ananyev@yandex.ru
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
>
> On 8/11/2023 7:07 AM, Sivaprasad Tummala wrote:
> > This patch removes RTE_CPUFLAG_NUMFLAGS to allow new CPU features
> > without breaking ABI each time.
> >
> > Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
> > ---
> > lib/eal/arm/include/rte_cpuflags_32.h | 1 -
> > lib/eal/arm/include/rte_cpuflags_64.h | 1 -
> > lib/eal/arm/rte_cpuflags.c | 7 +++++--
> > lib/eal/loongarch/include/rte_cpuflags.h | 1 -
> > lib/eal/loongarch/rte_cpuflags.c | 7 +++++--
> > lib/eal/ppc/include/rte_cpuflags.h | 1 -
> > lib/eal/ppc/rte_cpuflags.c | 7 +++++--
> > lib/eal/riscv/include/rte_cpuflags.h | 1 -
> > lib/eal/riscv/rte_cpuflags.c | 7 +++++--
> > lib/eal/x86/include/rte_cpuflags.h | 1 -
> > lib/eal/x86/rte_cpuflags.c | 7 +++++--
> > 11 files changed, 25 insertions(+), 16 deletions(-)
> >
>
> Hi Sivaprasad,
>
> Is the relevant deprecation notice removed somewhere, if not can you please
> remove it in this set?
>
> Thanks,
> Ferruh
Sure, will do the needful
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6 0/6] rte atomics API for optional stdatomic
@ 2023-09-29 14:09 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-09-29 14:09 UTC (permalink / raw)
To: Tyler Retzlaff
Cc: dev, techboard, Bruce Richardson, Honnappa Nagarahalli,
Ruifeng Wang, Jerin Jacob, Sunil Kumar Kori,
Mattias Rönnblom, Joyce Kong, David Christensen,
Konstantin Ananyev, David Hunt, Thomas Monjalon
Hello,
On Tue, Aug 22, 2023 at 11:00 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> This series introduces API additions prefixed in the rte namespace that allow
> the optional use of stdatomics.h from C11 using enable_stdatomics=true for
> targets where enable_stdatomics=false no functional change is intended.
>
> Be aware this does not contain all changes to use stdatomics across the DPDK
> tree it only introduces the minimum to allow the option to be used which is
> a pre-requisite for a clean CI (probably using clang) that can be run
> with enable_stdatomics=true enabled.
>
> It is planned that subsequent series will be introduced per lib/driver as
> appropriate to further enable stdatomics use when enable_stdatomics=true.
>
> Notes:
>
> * Additional libraries beyond EAL make visible atomics use across the
> API/ABI surface they will be converted in the subsequent series.
>
> * The eal: add rte atomic qualifier with casts patch needs some discussion
> as to whether or not the legacy rte_atomic APIs should be converted to
> work with enable_stdatomic=true right now some implementation dependent
> casts are used to prevent cascading / having to convert too much in
> the intial series.
>
> * Windows will obviously need complete conversion of libraries including
> atomics that are not crossing API/ABI boundaries. those conversions will
> introduced in separate series as new along side the existing msvc series.
>
> Please keep in mind we would like to prioritize the review / acceptance of
> this patch since it needs to be completed in the 23.11 merge window.
>
> Thank you all for the discussion that lead to the formation of this series.
I did a number of updates on this v6:
- moved rte_stdatomic.h from patch 1 to later patches where needed,
- added a RN entry,
- tried to consistently/adjusted indent,
- fixed mentions of stdatomic*s* to simple atomic, like in the build
option name,
- removed unneded comments (Thomas review on patch 1),
Series applied, thanks Tyler.
Two things are missing:
- add doxygen tags in the new API (this can be fixed later in this
release, can you look at it?),
- add compilation tests for enable_stdatomic (I'll send a patch soon
for devtools and GHA),
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3] bus/cdx: provide driver flag for optional resource mapping
@ 2023-09-29 15:17 3% ` David Marchand
2023-10-04 10:06 0% ` Gangurde, Abhijit
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-09-29 15:17 UTC (permalink / raw)
To: Abhijit Gangurde; +Cc: Nipun.Gupta, nikhil.agarwal, dev, Ferruh.Yigit, thomas
On Tue, Jul 11, 2023 at 7:52 AM Abhijit Gangurde
<abhijit.gangurde@amd.com> wrote:
> @@ -383,10 +384,12 @@ cdx_probe_one_driver(struct rte_cdx_driver *dr,
> CDX_BUS_DEBUG(" probe device %s using driver: %s", dev_name,
> dr->driver.name);
>
> - ret = cdx_vfio_map_resource(dev);
> - if (ret != 0) {
> - CDX_BUS_ERR("CDX map device failed: %d", ret);
> - goto error_map_device;
> + if (dr->drv_flags & RTE_CDX_DRV_NEED_MAPPING) {
> + ret = cdx_vfio_map_resource(dev);
> + if (ret != 0) {
> + CDX_BUS_ERR("CDX map device failed: %d", ret);
> + goto error_map_device;
> + }
> }
>
> /* call the driver probe() function */
> diff --git a/drivers/bus/cdx/rte_bus_cdx.h b/drivers/bus/cdx/rte_bus_cdx.h
> new file mode 100644
> index 0000000000..4ca12f90c4
> --- /dev/null
> +++ b/drivers/bus/cdx/rte_bus_cdx.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright (C) 2023, Advanced Micro Devices, Inc.
> + */
> +
> +#ifndef RTE_BUS_CDX_H
> +#define RTE_BUS_CDX_H
> +
> +/**
> + * @file
> + * CDX device & driver interface
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/* Forward declarations */
> +struct rte_cdx_device;
> +
> +/**
> + * Map the CDX device resources in user space virtual memory address.
> + *
> + * Note that driver should not call this function when flag
> + * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
> + * you when it's on.
Why should we export this function in the application ABI, if it is
only used by drivers?
> + *
> + * @param dev
> + * A pointer to a rte_cdx_device structure describing the device
> + * to use.
> + *
> + * @return
> + * 0 on success, negative on error and positive if no driver
> + * is found for the device.
> + */
> +__rte_experimental
> +int rte_cdx_map_device(struct rte_cdx_device *dev);
>
--
David Marchand
^ permalink raw reply [relevance 3%]
* [PATCH v4 1/3] mldev: add support for arbitrary shape dimensions
@ 2023-10-02 9:58 2% ` Srikanth Yalavarthi
2023-10-02 9:58 1% ` [PATCH v4 2/3] mldev: introduce support for IO layout Srikanth Yalavarthi
1 sibling, 0 replies; 200+ results
From: Srikanth Yalavarthi @ 2023-10-02 9:58 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev, sshankarnara, aprabhu, ptakkar
Updated rte_ml_io_info to support shape of arbitrary
number of dimensions. Dropped use of rte_ml_io_shape
and rte_ml_io_format. Introduced new fields nb_elements
and size in rte_ml_io_info.
Updated drivers and app/mldev to support the changes.
Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
---
app/test-mldev/test_inference_common.c | 97 +++++---------------------
doc/guides/rel_notes/release_23_11.rst | 3 +
drivers/ml/cnxk/cn10k_ml_model.c | 78 +++++++++++++--------
drivers/ml/cnxk/cn10k_ml_model.h | 12 ++++
drivers/ml/cnxk/cn10k_ml_ops.c | 11 +--
lib/mldev/mldev_utils.c | 30 --------
lib/mldev/mldev_utils.h | 16 -----
lib/mldev/rte_mldev.h | 59 ++++------------
lib/mldev/version.map | 1 -
9 files changed, 97 insertions(+), 210 deletions(-)
diff --git a/app/test-mldev/test_inference_common.c b/app/test-mldev/test_inference_common.c
index 05b221401b..b40519b5e3 100644
--- a/app/test-mldev/test_inference_common.c
+++ b/app/test-mldev/test_inference_common.c
@@ -3,6 +3,7 @@
*/
#include <errno.h>
+#include <math.h>
#include <stdio.h>
#include <unistd.h>
@@ -18,11 +19,6 @@
#include "ml_common.h"
#include "test_inference_common.h"
-#define ML_TEST_READ_TYPE(buffer, type) (*((type *)buffer))
-
-#define ML_TEST_CHECK_OUTPUT(output, reference, tolerance) \
- (((float)output - (float)reference) <= (((float)reference * tolerance) / 100.0))
-
#define ML_OPEN_WRITE_GET_ERR(name, buffer, size, err) \
do { \
FILE *fp = fopen(name, "w+"); \
@@ -763,9 +759,9 @@ ml_inference_validation(struct ml_test *test, struct ml_request *req)
{
struct test_inference *t = ml_test_priv((struct ml_test *)test);
struct ml_model *model;
- uint32_t nb_elements;
- uint8_t *reference;
- uint8_t *output;
+ float *reference;
+ float *output;
+ float deviation;
bool match;
uint32_t i;
uint32_t j;
@@ -777,89 +773,30 @@ ml_inference_validation(struct ml_test *test, struct ml_request *req)
match = (rte_hash_crc(model->output, model->out_dsize, 0) ==
rte_hash_crc(model->reference, model->out_dsize, 0));
} else {
- output = model->output;
- reference = model->reference;
+ output = (float *)model->output;
+ reference = (float *)model->reference;
i = 0;
next_output:
- nb_elements =
- model->info.output_info[i].shape.w * model->info.output_info[i].shape.x *
- model->info.output_info[i].shape.y * model->info.output_info[i].shape.z;
j = 0;
next_element:
match = false;
- switch (model->info.output_info[i].dtype) {
- case RTE_ML_IO_TYPE_INT8:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, int8_t),
- ML_TEST_READ_TYPE(reference, int8_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(int8_t);
- reference += sizeof(int8_t);
- break;
- case RTE_ML_IO_TYPE_UINT8:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, uint8_t),
- ML_TEST_READ_TYPE(reference, uint8_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(float);
- reference += sizeof(float);
- break;
- case RTE_ML_IO_TYPE_INT16:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, int16_t),
- ML_TEST_READ_TYPE(reference, int16_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(int16_t);
- reference += sizeof(int16_t);
- break;
- case RTE_ML_IO_TYPE_UINT16:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, uint16_t),
- ML_TEST_READ_TYPE(reference, uint16_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(uint16_t);
- reference += sizeof(uint16_t);
- break;
- case RTE_ML_IO_TYPE_INT32:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, int32_t),
- ML_TEST_READ_TYPE(reference, int32_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(int32_t);
- reference += sizeof(int32_t);
- break;
- case RTE_ML_IO_TYPE_UINT32:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, uint32_t),
- ML_TEST_READ_TYPE(reference, uint32_t),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(uint32_t);
- reference += sizeof(uint32_t);
- break;
- case RTE_ML_IO_TYPE_FP32:
- if (ML_TEST_CHECK_OUTPUT(ML_TEST_READ_TYPE(output, float),
- ML_TEST_READ_TYPE(reference, float),
- t->cmn.opt->tolerance))
- match = true;
-
- output += sizeof(float);
- reference += sizeof(float);
- break;
- default: /* other types, fp8, fp16, bfloat16 */
+ deviation =
+ (*reference == 0 ? 0 : 100 * fabs(*output - *reference) / fabs(*reference));
+ if (deviation <= t->cmn.opt->tolerance)
match = true;
- }
+ else
+ ml_err("id = %d, element = %d, output = %f, reference = %f, deviation = %f %%\n",
+ i, j, *output, *reference, deviation);
+
+ output++;
+ reference++;
if (!match)
goto done;
+
j++;
- if (j < nb_elements)
+ if (j < model->info.output_info[i].nb_elements)
goto next_element;
i++;
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 9746809a66..e553554b3a 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -119,6 +119,9 @@ API Changes
except ``rte_thread_setname()`` and ``rte_ctrl_thread_create()`` which are
replaced with ``rte_thread_set_name()`` and ``rte_thread_create_control()``.
+* mldev: Updated mldev API to support models with multiple inputs and outputs
+ Updated the structure ``rte_ml_model_info`` to support input and output with
+ arbitrary shapes.
ABI Changes
-----------
diff --git a/drivers/ml/cnxk/cn10k_ml_model.c b/drivers/ml/cnxk/cn10k_ml_model.c
index 92c47d39ba..26df8d9ff9 100644
--- a/drivers/ml/cnxk/cn10k_ml_model.c
+++ b/drivers/ml/cnxk/cn10k_ml_model.c
@@ -366,6 +366,12 @@ cn10k_ml_model_addr_update(struct cn10k_ml_model *model, uint8_t *buffer, uint8_
addr->total_input_sz_q = 0;
for (i = 0; i < metadata->model.num_input; i++) {
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
+ addr->input[i].nb_dims = 4;
+ addr->input[i].shape[0] = metadata->input1[i].shape.w;
+ addr->input[i].shape[1] = metadata->input1[i].shape.x;
+ addr->input[i].shape[2] = metadata->input1[i].shape.y;
+ addr->input[i].shape[3] = metadata->input1[i].shape.z;
+
addr->input[i].nb_elements =
metadata->input1[i].shape.w * metadata->input1[i].shape.x *
metadata->input1[i].shape.y * metadata->input1[i].shape.z;
@@ -386,6 +392,13 @@ cn10k_ml_model_addr_update(struct cn10k_ml_model *model, uint8_t *buffer, uint8_
addr->input[i].sz_q);
} else {
j = i - MRVL_ML_NUM_INPUT_OUTPUT_1;
+
+ addr->input[i].nb_dims = 4;
+ addr->input[i].shape[0] = metadata->input2[j].shape.w;
+ addr->input[i].shape[1] = metadata->input2[j].shape.x;
+ addr->input[i].shape[2] = metadata->input2[j].shape.y;
+ addr->input[i].shape[3] = metadata->input2[j].shape.z;
+
addr->input[i].nb_elements =
metadata->input2[j].shape.w * metadata->input2[j].shape.x *
metadata->input2[j].shape.y * metadata->input2[j].shape.z;
@@ -412,6 +425,8 @@ cn10k_ml_model_addr_update(struct cn10k_ml_model *model, uint8_t *buffer, uint8_
addr->total_output_sz_d = 0;
for (i = 0; i < metadata->model.num_output; i++) {
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
+ addr->output[i].nb_dims = 1;
+ addr->output[i].shape[0] = metadata->output1[i].size;
addr->output[i].nb_elements = metadata->output1[i].size;
addr->output[i].sz_d =
addr->output[i].nb_elements *
@@ -426,6 +441,9 @@ cn10k_ml_model_addr_update(struct cn10k_ml_model *model, uint8_t *buffer, uint8_
model->model_id, i, addr->output[i].sz_d, addr->output[i].sz_q);
} else {
j = i - MRVL_ML_NUM_INPUT_OUTPUT_1;
+
+ addr->output[i].nb_dims = 1;
+ addr->output[i].shape[0] = metadata->output2[j].size;
addr->output[i].nb_elements = metadata->output2[j].size;
addr->output[i].sz_d =
addr->output[i].nb_elements *
@@ -498,6 +516,7 @@ void
cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
{
struct cn10k_ml_model_metadata *metadata;
+ struct cn10k_ml_model_addr *addr;
struct rte_ml_model_info *info;
struct rte_ml_io_info *output;
struct rte_ml_io_info *input;
@@ -508,6 +527,7 @@ cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
info = PLT_PTR_CAST(model->info);
input = PLT_PTR_ADD(info, sizeof(struct rte_ml_model_info));
output = PLT_PTR_ADD(input, metadata->model.num_input * sizeof(struct rte_ml_io_info));
+ addr = &model->addr;
/* Set model info */
memset(info, 0, sizeof(struct rte_ml_model_info));
@@ -529,24 +549,25 @@ cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
rte_memcpy(input[i].name, metadata->input1[i].input_name,
MRVL_ML_INPUT_NAME_LEN);
- input[i].dtype = metadata->input1[i].input_type;
- input[i].qtype = metadata->input1[i].model_input_type;
- input[i].shape.format = metadata->input1[i].shape.format;
- input[i].shape.w = metadata->input1[i].shape.w;
- input[i].shape.x = metadata->input1[i].shape.x;
- input[i].shape.y = metadata->input1[i].shape.y;
- input[i].shape.z = metadata->input1[i].shape.z;
+ input[i].nb_dims = addr->input[i].nb_dims;
+ input[i].shape = addr->input[i].shape;
+ input[i].type = metadata->input1[i].model_input_type;
+ input[i].nb_elements = addr->input[i].nb_elements;
+ input[i].size =
+ addr->input[i].nb_elements *
+ rte_ml_io_type_size_get(metadata->input1[i].model_input_type);
} else {
j = i - MRVL_ML_NUM_INPUT_OUTPUT_1;
+
rte_memcpy(input[i].name, metadata->input2[j].input_name,
MRVL_ML_INPUT_NAME_LEN);
- input[i].dtype = metadata->input2[j].input_type;
- input[i].qtype = metadata->input2[j].model_input_type;
- input[i].shape.format = metadata->input2[j].shape.format;
- input[i].shape.w = metadata->input2[j].shape.w;
- input[i].shape.x = metadata->input2[j].shape.x;
- input[i].shape.y = metadata->input2[j].shape.y;
- input[i].shape.z = metadata->input2[j].shape.z;
+ input[i].nb_dims = addr->input[i].nb_dims;
+ input[i].shape = addr->input[i].shape;
+ input[i].type = metadata->input2[j].model_input_type;
+ input[i].nb_elements = addr->input[i].nb_elements;
+ input[i].size =
+ addr->input[i].nb_elements *
+ rte_ml_io_type_size_get(metadata->input2[j].model_input_type);
}
}
@@ -555,24 +576,25 @@ cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
rte_memcpy(output[i].name, metadata->output1[i].output_name,
MRVL_ML_OUTPUT_NAME_LEN);
- output[i].dtype = metadata->output1[i].output_type;
- output[i].qtype = metadata->output1[i].model_output_type;
- output[i].shape.format = RTE_ML_IO_FORMAT_1D;
- output[i].shape.w = metadata->output1[i].size;
- output[i].shape.x = 1;
- output[i].shape.y = 1;
- output[i].shape.z = 1;
+ output[i].nb_dims = addr->output[i].nb_dims;
+ output[i].shape = addr->output[i].shape;
+ output[i].type = metadata->output1[i].model_output_type;
+ output[i].nb_elements = addr->output[i].nb_elements;
+ output[i].size =
+ addr->output[i].nb_elements *
+ rte_ml_io_type_size_get(metadata->output1[i].model_output_type);
} else {
j = i - MRVL_ML_NUM_INPUT_OUTPUT_1;
+
rte_memcpy(output[i].name, metadata->output2[j].output_name,
MRVL_ML_OUTPUT_NAME_LEN);
- output[i].dtype = metadata->output2[j].output_type;
- output[i].qtype = metadata->output2[j].model_output_type;
- output[i].shape.format = RTE_ML_IO_FORMAT_1D;
- output[i].shape.w = metadata->output2[j].size;
- output[i].shape.x = 1;
- output[i].shape.y = 1;
- output[i].shape.z = 1;
+ output[i].nb_dims = addr->output[i].nb_dims;
+ output[i].shape = addr->output[i].shape;
+ output[i].type = metadata->output2[j].model_output_type;
+ output[i].nb_elements = addr->output[i].nb_elements;
+ output[i].size =
+ addr->output[i].nb_elements *
+ rte_ml_io_type_size_get(metadata->output2[j].model_output_type);
}
}
}
diff --git a/drivers/ml/cnxk/cn10k_ml_model.h b/drivers/ml/cnxk/cn10k_ml_model.h
index 1f689363fc..4cc0744891 100644
--- a/drivers/ml/cnxk/cn10k_ml_model.h
+++ b/drivers/ml/cnxk/cn10k_ml_model.h
@@ -409,6 +409,12 @@ struct cn10k_ml_model_addr {
/* Input address and size */
struct {
+ /* Number of dimensions in shape */
+ uint32_t nb_dims;
+
+ /* Shape of input */
+ uint32_t shape[4];
+
/* Number of elements */
uint32_t nb_elements;
@@ -421,6 +427,12 @@ struct cn10k_ml_model_addr {
/* Output address and size */
struct {
+ /* Number of dimensions in shape */
+ uint32_t nb_dims;
+
+ /* Shape of input */
+ uint32_t shape[4];
+
/* Number of elements */
uint32_t nb_elements;
diff --git a/drivers/ml/cnxk/cn10k_ml_ops.c b/drivers/ml/cnxk/cn10k_ml_ops.c
index 656467d891..e3faab81ba 100644
--- a/drivers/ml/cnxk/cn10k_ml_ops.c
+++ b/drivers/ml/cnxk/cn10k_ml_ops.c
@@ -321,8 +321,8 @@ cn10k_ml_model_print(struct rte_ml_dev *dev, uint16_t model_id, FILE *fp)
fprintf(fp, "\n");
print_line(fp, LINE_LEN);
- fprintf(fp, "%8s %16s %12s %18s %12s %14s\n", "input", "input_name", "input_type",
- "model_input_type", "quantize", "format");
+ fprintf(fp, "%8s %16s %12s %18s %12s\n", "input", "input_name", "input_type",
+ "model_input_type", "quantize");
print_line(fp, LINE_LEN);
for (i = 0; i < model->metadata.model.num_input; i++) {
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
@@ -335,12 +335,10 @@ cn10k_ml_model_print(struct rte_ml_dev *dev, uint16_t model_id, FILE *fp)
fprintf(fp, "%*s ", 18, str);
fprintf(fp, "%*s", 12,
(model->metadata.input1[i].quantize == 1 ? "Yes" : "No"));
- rte_ml_io_format_to_str(model->metadata.input1[i].shape.format, str,
- STR_LEN);
- fprintf(fp, "%*s", 16, str);
fprintf(fp, "\n");
} else {
j = i - MRVL_ML_NUM_INPUT_OUTPUT_1;
+
fprintf(fp, "%8u ", i);
fprintf(fp, "%*s ", 16, model->metadata.input2[j].input_name);
rte_ml_io_type_to_str(model->metadata.input2[j].input_type, str, STR_LEN);
@@ -350,9 +348,6 @@ cn10k_ml_model_print(struct rte_ml_dev *dev, uint16_t model_id, FILE *fp)
fprintf(fp, "%*s ", 18, str);
fprintf(fp, "%*s", 12,
(model->metadata.input2[j].quantize == 1 ? "Yes" : "No"));
- rte_ml_io_format_to_str(model->metadata.input2[j].shape.format, str,
- STR_LEN);
- fprintf(fp, "%*s", 16, str);
fprintf(fp, "\n");
}
}
diff --git a/lib/mldev/mldev_utils.c b/lib/mldev/mldev_utils.c
index d2442b123b..ccd2c39ca8 100644
--- a/lib/mldev/mldev_utils.c
+++ b/lib/mldev/mldev_utils.c
@@ -86,33 +86,3 @@ rte_ml_io_type_to_str(enum rte_ml_io_type type, char *str, int len)
rte_strlcpy(str, "invalid", len);
}
}
-
-void
-rte_ml_io_format_to_str(enum rte_ml_io_format format, char *str, int len)
-{
- switch (format) {
- case RTE_ML_IO_FORMAT_NCHW:
- rte_strlcpy(str, "NCHW", len);
- break;
- case RTE_ML_IO_FORMAT_NHWC:
- rte_strlcpy(str, "NHWC", len);
- break;
- case RTE_ML_IO_FORMAT_CHWN:
- rte_strlcpy(str, "CHWN", len);
- break;
- case RTE_ML_IO_FORMAT_3D:
- rte_strlcpy(str, "3D", len);
- break;
- case RTE_ML_IO_FORMAT_2D:
- rte_strlcpy(str, "Matrix", len);
- break;
- case RTE_ML_IO_FORMAT_1D:
- rte_strlcpy(str, "Vector", len);
- break;
- case RTE_ML_IO_FORMAT_SCALAR:
- rte_strlcpy(str, "Scalar", len);
- break;
- default:
- rte_strlcpy(str, "invalid", len);
- }
-}
diff --git a/lib/mldev/mldev_utils.h b/lib/mldev/mldev_utils.h
index 5bc8020453..220afb42f0 100644
--- a/lib/mldev/mldev_utils.h
+++ b/lib/mldev/mldev_utils.h
@@ -52,22 +52,6 @@ __rte_internal
void
rte_ml_io_type_to_str(enum rte_ml_io_type type, char *str, int len);
-/**
- * @internal
- *
- * Get the name of an ML IO format.
- *
- * @param[in] type
- * Enumeration of ML IO format.
- * @param[in] str
- * Address of character array.
- * @param[in] len
- * Length of character array.
- */
-__rte_internal
-void
-rte_ml_io_format_to_str(enum rte_ml_io_format format, char *str, int len);
-
/**
* @internal
*
diff --git a/lib/mldev/rte_mldev.h b/lib/mldev/rte_mldev.h
index fc3525c1ab..6204df0930 100644
--- a/lib/mldev/rte_mldev.h
+++ b/lib/mldev/rte_mldev.h
@@ -863,47 +863,6 @@ enum rte_ml_io_type {
/**< 16-bit brain floating point number. */
};
-/**
- * Input and output format. This is used to represent the encoding type of multi-dimensional
- * used by ML models.
- */
-enum rte_ml_io_format {
- RTE_ML_IO_FORMAT_NCHW = 1,
- /**< Batch size (N) x channels (C) x height (H) x width (W) */
- RTE_ML_IO_FORMAT_NHWC,
- /**< Batch size (N) x height (H) x width (W) x channels (C) */
- RTE_ML_IO_FORMAT_CHWN,
- /**< Channels (C) x height (H) x width (W) x batch size (N) */
- RTE_ML_IO_FORMAT_3D,
- /**< Format to represent a 3 dimensional data */
- RTE_ML_IO_FORMAT_2D,
- /**< Format to represent matrix data */
- RTE_ML_IO_FORMAT_1D,
- /**< Format to represent vector data */
- RTE_ML_IO_FORMAT_SCALAR,
- /**< Format to represent scalar data */
-};
-
-/**
- * Input and output shape. This structure represents the encoding format and dimensions
- * of the tensor or vector.
- *
- * The data can be a 4D / 3D tensor, matrix, vector or a scalar. Number of dimensions used
- * for the data would depend on the format. Unused dimensions to be set to 1.
- */
-struct rte_ml_io_shape {
- enum rte_ml_io_format format;
- /**< Format of the data */
- uint32_t w;
- /**< First dimension */
- uint32_t x;
- /**< Second dimension */
- uint32_t y;
- /**< Third dimension */
- uint32_t z;
- /**< Fourth dimension */
-};
-
/** Input and output data information structure
*
* Specifies the type and shape of input and output data.
@@ -911,12 +870,18 @@ struct rte_ml_io_shape {
struct rte_ml_io_info {
char name[RTE_ML_STR_MAX];
/**< Name of data */
- struct rte_ml_io_shape shape;
- /**< Shape of data */
- enum rte_ml_io_type qtype;
- /**< Type of quantized data */
- enum rte_ml_io_type dtype;
- /**< Type of de-quantized data */
+ uint32_t nb_dims;
+ /**< Number of dimensions in shape */
+ uint32_t *shape;
+ /**< Shape of the tensor */
+ enum rte_ml_io_type type;
+ /**< Type of data
+ * @see enum rte_ml_io_type
+ */
+ uint64_t nb_elements;
+ /** Number of elements in tensor */
+ uint64_t size;
+ /** Size of tensor in bytes */
};
/** Model information structure */
diff --git a/lib/mldev/version.map b/lib/mldev/version.map
index 0706b565be..40ff27f4b9 100644
--- a/lib/mldev/version.map
+++ b/lib/mldev/version.map
@@ -51,7 +51,6 @@ INTERNAL {
rte_ml_io_type_size_get;
rte_ml_io_type_to_str;
- rte_ml_io_format_to_str;
rte_ml_io_float32_to_int8;
rte_ml_io_int8_to_float32;
rte_ml_io_float32_to_uint8;
--
2.41.0
^ permalink raw reply [relevance 2%]
* [PATCH v4 2/3] mldev: introduce support for IO layout
2023-10-02 9:58 2% ` [PATCH v4 1/3] mldev: add support for arbitrary shape dimensions Srikanth Yalavarthi
@ 2023-10-02 9:58 1% ` Srikanth Yalavarthi
1 sibling, 0 replies; 200+ results
From: Srikanth Yalavarthi @ 2023-10-02 9:58 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev, sshankarnara, aprabhu, ptakkar
Introduce IO layout in ML device specification. IO layout
defines the expected arrangement of model input and output
buffers in the memory. Packed and Split layout support is
added in the specification.
Updated rte_ml_op to support array of rte_ml_buff_seg
pointers to support packed and split I/O layouts. Updated
ML quantize and dequantize APIs to support rte_ml_buff_seg
pointer arrays. Replaced batch_size with min_batches and
max_batches in rte_ml_model_info.
Implement support for model IO layout in ml/cnxk driver.
Updated the ML test application to support IO layout and
dropped support for '--batches' in test application.
Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
---
app/test-mldev/ml_options.c | 16 --
app/test-mldev/ml_options.h | 2 -
app/test-mldev/test_inference_common.c | 327 +++++++++++++++++++++----
app/test-mldev/test_inference_common.h | 6 +
app/test-mldev/test_model_common.c | 6 -
app/test-mldev/test_model_common.h | 1 -
doc/guides/rel_notes/release_23_11.rst | 10 +
doc/guides/tools/testmldev.rst | 6 -
drivers/ml/cnxk/cn10k_ml_dev.h | 3 +
drivers/ml/cnxk/cn10k_ml_model.c | 6 +-
drivers/ml/cnxk/cn10k_ml_ops.c | 74 +++---
lib/mldev/meson.build | 2 +-
lib/mldev/rte_mldev.c | 12 +-
lib/mldev/rte_mldev.h | 90 +++++--
lib/mldev/rte_mldev_core.h | 14 +-
15 files changed, 428 insertions(+), 147 deletions(-)
diff --git a/app/test-mldev/ml_options.c b/app/test-mldev/ml_options.c
index d068b30df5..eeaffec399 100644
--- a/app/test-mldev/ml_options.c
+++ b/app/test-mldev/ml_options.c
@@ -28,7 +28,6 @@ ml_options_default(struct ml_options *opt)
opt->burst_size = 1;
opt->queue_pairs = 1;
opt->queue_size = 1;
- opt->batches = 0;
opt->tolerance = 0.0;
opt->stats = false;
opt->debug = false;
@@ -213,18 +212,6 @@ ml_parse_queue_size(struct ml_options *opt, const char *arg)
return ret;
}
-static int
-ml_parse_batches(struct ml_options *opt, const char *arg)
-{
- int ret;
-
- ret = parser_read_uint16(&opt->batches, arg);
- if (ret != 0)
- ml_err("Invalid option, batches = %s\n", arg);
-
- return ret;
-}
-
static int
ml_parse_tolerance(struct ml_options *opt, const char *arg)
{
@@ -255,7 +242,6 @@ ml_dump_test_options(const char *testname)
"\t\t--burst_size : inference burst size\n"
"\t\t--queue_pairs : number of queue pairs to create\n"
"\t\t--queue_size : size of queue-pair\n"
- "\t\t--batches : number of batches of input\n"
"\t\t--tolerance : maximum tolerance (%%) for output validation\n"
"\t\t--stats : enable reporting device and model statistics\n");
printf("\n");
@@ -287,7 +273,6 @@ static struct option lgopts[] = {
{ML_BURST_SIZE, 1, 0, 0},
{ML_QUEUE_PAIRS, 1, 0, 0},
{ML_QUEUE_SIZE, 1, 0, 0},
- {ML_BATCHES, 1, 0, 0},
{ML_TOLERANCE, 1, 0, 0},
{ML_STATS, 0, 0, 0},
{ML_DEBUG, 0, 0, 0},
@@ -309,7 +294,6 @@ ml_opts_parse_long(int opt_idx, struct ml_options *opt)
{ML_BURST_SIZE, ml_parse_burst_size},
{ML_QUEUE_PAIRS, ml_parse_queue_pairs},
{ML_QUEUE_SIZE, ml_parse_queue_size},
- {ML_BATCHES, ml_parse_batches},
{ML_TOLERANCE, ml_parse_tolerance},
};
diff --git a/app/test-mldev/ml_options.h b/app/test-mldev/ml_options.h
index 622a4c05fc..90e22adeac 100644
--- a/app/test-mldev/ml_options.h
+++ b/app/test-mldev/ml_options.h
@@ -21,7 +21,6 @@
#define ML_BURST_SIZE ("burst_size")
#define ML_QUEUE_PAIRS ("queue_pairs")
#define ML_QUEUE_SIZE ("queue_size")
-#define ML_BATCHES ("batches")
#define ML_TOLERANCE ("tolerance")
#define ML_STATS ("stats")
#define ML_DEBUG ("debug")
@@ -44,7 +43,6 @@ struct ml_options {
uint16_t burst_size;
uint16_t queue_pairs;
uint16_t queue_size;
- uint16_t batches;
float tolerance;
bool stats;
bool debug;
diff --git a/app/test-mldev/test_inference_common.c b/app/test-mldev/test_inference_common.c
index b40519b5e3..846f71abb1 100644
--- a/app/test-mldev/test_inference_common.c
+++ b/app/test-mldev/test_inference_common.c
@@ -47,7 +47,10 @@ ml_enqueue_single(void *arg)
uint64_t start_cycle;
uint32_t burst_enq;
uint32_t lcore_id;
+ uint64_t offset;
+ uint64_t bufsz;
uint16_t fid;
+ uint32_t i;
int ret;
lcore_id = rte_lcore_id();
@@ -66,24 +69,64 @@ ml_enqueue_single(void *arg)
if (ret != 0)
goto next_model;
-retry:
+retry_req:
ret = rte_mempool_get(t->model[fid].io_pool, (void **)&req);
if (ret != 0)
- goto retry;
+ goto retry_req;
+
+retry_inp_segs:
+ ret = rte_mempool_get_bulk(t->buf_seg_pool, (void **)req->inp_buf_segs,
+ t->model[fid].info.nb_inputs);
+ if (ret != 0)
+ goto retry_inp_segs;
+
+retry_out_segs:
+ ret = rte_mempool_get_bulk(t->buf_seg_pool, (void **)req->out_buf_segs,
+ t->model[fid].info.nb_outputs);
+ if (ret != 0)
+ goto retry_out_segs;
op->model_id = t->model[fid].id;
- op->nb_batches = t->model[fid].nb_batches;
+ op->nb_batches = t->model[fid].info.min_batches;
op->mempool = t->op_pool;
+ op->input = req->inp_buf_segs;
+ op->output = req->out_buf_segs;
+ op->user_ptr = req;
- op->input.addr = req->input;
- op->input.length = t->model[fid].inp_qsize;
- op->input.next = NULL;
+ if (t->model[fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED) {
+ op->input[0]->addr = req->input;
+ op->input[0]->iova_addr = rte_mem_virt2iova(req->input);
+ op->input[0]->length = t->model[fid].inp_qsize;
+ op->input[0]->next = NULL;
+
+ op->output[0]->addr = req->output;
+ op->output[0]->iova_addr = rte_mem_virt2iova(req->output);
+ op->output[0]->length = t->model[fid].out_qsize;
+ op->output[0]->next = NULL;
+ } else {
+ offset = 0;
+ for (i = 0; i < t->model[fid].info.nb_inputs; i++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[fid].info.input_info[i].size,
+ t->cmn.dev_info.align_size);
+ op->input[i]->addr = req->input + offset;
+ op->input[i]->iova_addr = rte_mem_virt2iova(req->input + offset);
+ op->input[i]->length = bufsz;
+ op->input[i]->next = NULL;
+ offset += bufsz;
+ }
- op->output.addr = req->output;
- op->output.length = t->model[fid].out_qsize;
- op->output.next = NULL;
+ offset = 0;
+ for (i = 0; i < t->model[fid].info.nb_outputs; i++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[fid].info.output_info[i].size,
+ t->cmn.dev_info.align_size);
+ op->output[i]->addr = req->output + offset;
+ op->output[i]->iova_addr = rte_mem_virt2iova(req->output + offset);
+ op->output[i]->length = bufsz;
+ op->output[i]->next = NULL;
+ offset += bufsz;
+ }
+ }
- op->user_ptr = req;
req->niters++;
req->fid = fid;
@@ -143,6 +186,10 @@ ml_dequeue_single(void *arg)
}
req = (struct ml_request *)op->user_ptr;
rte_mempool_put(t->model[req->fid].io_pool, req);
+ rte_mempool_put_bulk(t->buf_seg_pool, (void **)op->input,
+ t->model[req->fid].info.nb_inputs);
+ rte_mempool_put_bulk(t->buf_seg_pool, (void **)op->output,
+ t->model[req->fid].info.nb_outputs);
rte_mempool_put(t->op_pool, op);
}
@@ -164,9 +211,12 @@ ml_enqueue_burst(void *arg)
uint16_t burst_enq;
uint32_t lcore_id;
uint16_t pending;
+ uint64_t offset;
+ uint64_t bufsz;
uint16_t idx;
uint16_t fid;
uint16_t i;
+ uint16_t j;
int ret;
lcore_id = rte_lcore_id();
@@ -186,25 +236,70 @@ ml_enqueue_burst(void *arg)
if (ret != 0)
goto next_model;
-retry:
+retry_reqs:
ret = rte_mempool_get_bulk(t->model[fid].io_pool, (void **)args->reqs, ops_count);
if (ret != 0)
- goto retry;
+ goto retry_reqs;
for (i = 0; i < ops_count; i++) {
+retry_inp_segs:
+ ret = rte_mempool_get_bulk(t->buf_seg_pool, (void **)args->reqs[i]->inp_buf_segs,
+ t->model[fid].info.nb_inputs);
+ if (ret != 0)
+ goto retry_inp_segs;
+
+retry_out_segs:
+ ret = rte_mempool_get_bulk(t->buf_seg_pool, (void **)args->reqs[i]->out_buf_segs,
+ t->model[fid].info.nb_outputs);
+ if (ret != 0)
+ goto retry_out_segs;
+
args->enq_ops[i]->model_id = t->model[fid].id;
- args->enq_ops[i]->nb_batches = t->model[fid].nb_batches;
+ args->enq_ops[i]->nb_batches = t->model[fid].info.min_batches;
args->enq_ops[i]->mempool = t->op_pool;
+ args->enq_ops[i]->input = args->reqs[i]->inp_buf_segs;
+ args->enq_ops[i]->output = args->reqs[i]->out_buf_segs;
+ args->enq_ops[i]->user_ptr = args->reqs[i];
- args->enq_ops[i]->input.addr = args->reqs[i]->input;
- args->enq_ops[i]->input.length = t->model[fid].inp_qsize;
- args->enq_ops[i]->input.next = NULL;
+ if (t->model[fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED) {
+ args->enq_ops[i]->input[0]->addr = args->reqs[i]->input;
+ args->enq_ops[i]->input[0]->iova_addr =
+ rte_mem_virt2iova(args->reqs[i]->input);
+ args->enq_ops[i]->input[0]->length = t->model[fid].inp_qsize;
+ args->enq_ops[i]->input[0]->next = NULL;
+
+ args->enq_ops[i]->output[0]->addr = args->reqs[i]->output;
+ args->enq_ops[i]->output[0]->iova_addr =
+ rte_mem_virt2iova(args->reqs[i]->output);
+ args->enq_ops[i]->output[0]->length = t->model[fid].out_qsize;
+ args->enq_ops[i]->output[0]->next = NULL;
+ } else {
+ offset = 0;
+ for (j = 0; j < t->model[fid].info.nb_inputs; j++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[fid].info.input_info[i].size,
+ t->cmn.dev_info.align_size);
+
+ args->enq_ops[i]->input[j]->addr = args->reqs[i]->input + offset;
+ args->enq_ops[i]->input[j]->iova_addr =
+ rte_mem_virt2iova(args->reqs[i]->input + offset);
+ args->enq_ops[i]->input[j]->length = t->model[fid].inp_qsize;
+ args->enq_ops[i]->input[j]->next = NULL;
+ offset += bufsz;
+ }
- args->enq_ops[i]->output.addr = args->reqs[i]->output;
- args->enq_ops[i]->output.length = t->model[fid].out_qsize;
- args->enq_ops[i]->output.next = NULL;
+ offset = 0;
+ for (j = 0; j < t->model[fid].info.nb_outputs; j++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[fid].info.output_info[i].size,
+ t->cmn.dev_info.align_size);
+ args->enq_ops[i]->output[j]->addr = args->reqs[i]->output + offset;
+ args->enq_ops[i]->output[j]->iova_addr =
+ rte_mem_virt2iova(args->reqs[i]->output + offset);
+ args->enq_ops[i]->output[j]->length = t->model[fid].out_qsize;
+ args->enq_ops[i]->output[j]->next = NULL;
+ offset += bufsz;
+ }
+ }
- args->enq_ops[i]->user_ptr = args->reqs[i];
args->reqs[i]->niters++;
args->reqs[i]->fid = fid;
}
@@ -275,8 +370,15 @@ ml_dequeue_burst(void *arg)
t->error_count[lcore_id]++;
}
req = (struct ml_request *)args->deq_ops[i]->user_ptr;
- if (req != NULL)
+ if (req != NULL) {
rte_mempool_put(t->model[req->fid].io_pool, req);
+ rte_mempool_put_bulk(t->buf_seg_pool,
+ (void **)args->deq_ops[i]->input,
+ t->model[req->fid].info.nb_inputs);
+ rte_mempool_put_bulk(t->buf_seg_pool,
+ (void **)args->deq_ops[i]->output,
+ t->model[req->fid].info.nb_outputs);
+ }
}
rte_mempool_put_bulk(t->op_pool, (void *)args->deq_ops, burst_deq);
}
@@ -315,6 +417,12 @@ test_inference_cap_check(struct ml_options *opt)
return false;
}
+ if (dev_info.max_io < ML_TEST_MAX_IO_SIZE) {
+ ml_err("Insufficient capabilities: Max I/O, count = %u > (max limit = %u)",
+ ML_TEST_MAX_IO_SIZE, dev_info.max_io);
+ return false;
+ }
+
return true;
}
@@ -403,11 +511,6 @@ test_inference_opt_dump(struct ml_options *opt)
ml_dump("tolerance", "%-7.3f", opt->tolerance);
ml_dump("stats", "%s", (opt->stats ? "true" : "false"));
- if (opt->batches == 0)
- ml_dump("batches", "%u (default batch size)", opt->batches);
- else
- ml_dump("batches", "%u", opt->batches);
-
ml_dump_begin("filelist");
for (i = 0; i < opt->nb_filelist; i++) {
ml_dump_list("model", i, opt->filelist[i].model);
@@ -492,10 +595,18 @@ void
test_inference_destroy(struct ml_test *test, struct ml_options *opt)
{
struct test_inference *t;
+ uint32_t lcore_id;
RTE_SET_USED(opt);
t = ml_test_priv(test);
+
+ for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
+ rte_free(t->args[lcore_id].enq_ops);
+ rte_free(t->args[lcore_id].deq_ops);
+ rte_free(t->args[lcore_id].reqs);
+ }
+
rte_free(t);
}
@@ -572,19 +683,62 @@ ml_request_initialize(struct rte_mempool *mp, void *opaque, void *obj, unsigned
{
struct test_inference *t = ml_test_priv((struct ml_test *)opaque);
struct ml_request *req = (struct ml_request *)obj;
+ struct rte_ml_buff_seg dbuff_seg[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg qbuff_seg[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg *q_segs[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg *d_segs[ML_TEST_MAX_IO_SIZE];
+ uint64_t offset;
+ uint64_t bufsz;
+ uint32_t i;
RTE_SET_USED(mp);
RTE_SET_USED(obj_idx);
req->input = (uint8_t *)obj +
- RTE_ALIGN_CEIL(sizeof(struct ml_request), t->cmn.dev_info.min_align_size);
- req->output = req->input +
- RTE_ALIGN_CEIL(t->model[t->fid].inp_qsize, t->cmn.dev_info.min_align_size);
+ RTE_ALIGN_CEIL(sizeof(struct ml_request), t->cmn.dev_info.align_size);
+ req->output =
+ req->input + RTE_ALIGN_CEIL(t->model[t->fid].inp_qsize, t->cmn.dev_info.align_size);
req->niters = 0;
+ if (t->model[t->fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED) {
+ dbuff_seg[0].addr = t->model[t->fid].input;
+ dbuff_seg[0].iova_addr = rte_mem_virt2iova(t->model[t->fid].input);
+ dbuff_seg[0].length = t->model[t->fid].inp_dsize;
+ dbuff_seg[0].next = NULL;
+ d_segs[0] = &dbuff_seg[0];
+
+ qbuff_seg[0].addr = req->input;
+ qbuff_seg[0].iova_addr = rte_mem_virt2iova(req->input);
+ qbuff_seg[0].length = t->model[t->fid].inp_qsize;
+ qbuff_seg[0].next = NULL;
+ q_segs[0] = &qbuff_seg[0];
+ } else {
+ offset = 0;
+ for (i = 0; i < t->model[t->fid].info.nb_inputs; i++) {
+ bufsz = t->model[t->fid].info.input_info[i].nb_elements * sizeof(float);
+ dbuff_seg[i].addr = t->model[t->fid].input + offset;
+ dbuff_seg[i].iova_addr = rte_mem_virt2iova(t->model[t->fid].input + offset);
+ dbuff_seg[i].length = bufsz;
+ dbuff_seg[i].next = NULL;
+ d_segs[i] = &dbuff_seg[i];
+ offset += bufsz;
+ }
+
+ offset = 0;
+ for (i = 0; i < t->model[t->fid].info.nb_inputs; i++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[t->fid].info.input_info[i].size,
+ t->cmn.dev_info.align_size);
+ qbuff_seg[i].addr = req->input + offset;
+ qbuff_seg[i].iova_addr = rte_mem_virt2iova(req->input + offset);
+ qbuff_seg[i].length = bufsz;
+ qbuff_seg[i].next = NULL;
+ q_segs[i] = &qbuff_seg[i];
+ offset += bufsz;
+ }
+ }
+
/* quantize data */
- rte_ml_io_quantize(t->cmn.opt->dev_id, t->model[t->fid].id, t->model[t->fid].nb_batches,
- t->model[t->fid].input, req->input);
+ rte_ml_io_quantize(t->cmn.opt->dev_id, t->model[t->fid].id, d_segs, q_segs);
}
int
@@ -599,24 +753,39 @@ ml_inference_iomem_setup(struct ml_test *test, struct ml_options *opt, uint16_t
uint32_t buff_size;
uint32_t mz_size;
size_t fsize;
+ uint32_t i;
int ret;
/* get input buffer size */
- ret = rte_ml_io_input_size_get(opt->dev_id, t->model[fid].id, t->model[fid].nb_batches,
- &t->model[fid].inp_qsize, &t->model[fid].inp_dsize);
- if (ret != 0) {
- ml_err("Failed to get input size, model : %s\n", opt->filelist[fid].model);
- return ret;
+ t->model[fid].inp_qsize = 0;
+ for (i = 0; i < t->model[fid].info.nb_inputs; i++) {
+ if (t->model[fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED)
+ t->model[fid].inp_qsize += t->model[fid].info.input_info[i].size;
+ else
+ t->model[fid].inp_qsize += RTE_ALIGN_CEIL(
+ t->model[fid].info.input_info[i].size, t->cmn.dev_info.align_size);
}
/* get output buffer size */
- ret = rte_ml_io_output_size_get(opt->dev_id, t->model[fid].id, t->model[fid].nb_batches,
- &t->model[fid].out_qsize, &t->model[fid].out_dsize);
- if (ret != 0) {
- ml_err("Failed to get input size, model : %s\n", opt->filelist[fid].model);
- return ret;
+ t->model[fid].out_qsize = 0;
+ for (i = 0; i < t->model[fid].info.nb_outputs; i++) {
+ if (t->model[fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED)
+ t->model[fid].out_qsize += t->model[fid].info.output_info[i].size;
+ else
+ t->model[fid].out_qsize += RTE_ALIGN_CEIL(
+ t->model[fid].info.output_info[i].size, t->cmn.dev_info.align_size);
}
+ t->model[fid].inp_dsize = 0;
+ for (i = 0; i < t->model[fid].info.nb_inputs; i++)
+ t->model[fid].inp_dsize +=
+ t->model[fid].info.input_info[i].nb_elements * sizeof(float);
+
+ t->model[fid].out_dsize = 0;
+ for (i = 0; i < t->model[fid].info.nb_outputs; i++)
+ t->model[fid].out_dsize +=
+ t->model[fid].info.output_info[i].nb_elements * sizeof(float);
+
/* allocate buffer for user data */
mz_size = t->model[fid].inp_dsize + t->model[fid].out_dsize;
if (strcmp(opt->filelist[fid].reference, "\0") != 0)
@@ -675,9 +844,9 @@ ml_inference_iomem_setup(struct ml_test *test, struct ml_options *opt, uint16_t
/* create mempool for quantized input and output buffers. ml_request_initialize is
* used as a callback for object creation.
*/
- buff_size = RTE_ALIGN_CEIL(sizeof(struct ml_request), t->cmn.dev_info.min_align_size) +
- RTE_ALIGN_CEIL(t->model[fid].inp_qsize, t->cmn.dev_info.min_align_size) +
- RTE_ALIGN_CEIL(t->model[fid].out_qsize, t->cmn.dev_info.min_align_size);
+ buff_size = RTE_ALIGN_CEIL(sizeof(struct ml_request), t->cmn.dev_info.align_size) +
+ RTE_ALIGN_CEIL(t->model[fid].inp_qsize, t->cmn.dev_info.align_size) +
+ RTE_ALIGN_CEIL(t->model[fid].out_qsize, t->cmn.dev_info.align_size);
nb_buffers = RTE_MIN((uint64_t)ML_TEST_MAX_POOL_SIZE, opt->repetitions);
t->fid = fid;
@@ -740,6 +909,18 @@ ml_inference_mem_setup(struct ml_test *test, struct ml_options *opt)
return -ENOMEM;
}
+ /* create buf_segs pool of with element of uint8_t. external buffers are attached to the
+ * buf_segs while queuing inference requests.
+ */
+ t->buf_seg_pool = rte_mempool_create("ml_test_mbuf_pool", ML_TEST_MAX_POOL_SIZE * 2,
+ sizeof(struct rte_ml_buff_seg), 0, 0, NULL, NULL, NULL,
+ NULL, opt->socket_id, 0);
+ if (t->buf_seg_pool == NULL) {
+ ml_err("Failed to create buf_segs pool : %s\n", "ml_test_mbuf_pool");
+ rte_ml_op_pool_free(t->op_pool);
+ return -ENOMEM;
+ }
+
return 0;
}
@@ -752,6 +933,9 @@ ml_inference_mem_destroy(struct ml_test *test, struct ml_options *opt)
/* release op pool */
rte_mempool_free(t->op_pool);
+
+ /* release buf_segs pool */
+ rte_mempool_free(t->buf_seg_pool);
}
static bool
@@ -781,8 +965,10 @@ ml_inference_validation(struct ml_test *test, struct ml_request *req)
j = 0;
next_element:
match = false;
- deviation =
- (*reference == 0 ? 0 : 100 * fabs(*output - *reference) / fabs(*reference));
+ if ((*reference == 0) && (*output == 0))
+ deviation = 0;
+ else
+ deviation = 100 * fabs(*output - *reference) / fabs(*reference);
if (deviation <= t->cmn.opt->tolerance)
match = true;
else
@@ -817,14 +1003,59 @@ ml_request_finish(struct rte_mempool *mp, void *opaque, void *obj, unsigned int
bool error = false;
char *dump_path;
+ struct rte_ml_buff_seg qbuff_seg[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg dbuff_seg[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg *q_segs[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg *d_segs[ML_TEST_MAX_IO_SIZE];
+ uint64_t offset;
+ uint64_t bufsz;
+ uint32_t i;
+
RTE_SET_USED(mp);
if (req->niters == 0)
return;
t->nb_used++;
- rte_ml_io_dequantize(t->cmn.opt->dev_id, model->id, t->model[req->fid].nb_batches,
- req->output, model->output);
+
+ if (t->model[req->fid].info.io_layout == RTE_ML_IO_LAYOUT_PACKED) {
+ qbuff_seg[0].addr = req->output;
+ qbuff_seg[0].iova_addr = rte_mem_virt2iova(req->output);
+ qbuff_seg[0].length = t->model[req->fid].out_qsize;
+ qbuff_seg[0].next = NULL;
+ q_segs[0] = &qbuff_seg[0];
+
+ dbuff_seg[0].addr = model->output;
+ dbuff_seg[0].iova_addr = rte_mem_virt2iova(model->output);
+ dbuff_seg[0].length = t->model[req->fid].out_dsize;
+ dbuff_seg[0].next = NULL;
+ d_segs[0] = &dbuff_seg[0];
+ } else {
+ offset = 0;
+ for (i = 0; i < t->model[req->fid].info.nb_outputs; i++) {
+ bufsz = RTE_ALIGN_CEIL(t->model[req->fid].info.output_info[i].size,
+ t->cmn.dev_info.align_size);
+ qbuff_seg[i].addr = req->output + offset;
+ qbuff_seg[i].iova_addr = rte_mem_virt2iova(req->output + offset);
+ qbuff_seg[i].length = bufsz;
+ qbuff_seg[i].next = NULL;
+ q_segs[i] = &qbuff_seg[i];
+ offset += bufsz;
+ }
+
+ offset = 0;
+ for (i = 0; i < t->model[req->fid].info.nb_outputs; i++) {
+ bufsz = t->model[req->fid].info.output_info[i].nb_elements * sizeof(float);
+ dbuff_seg[i].addr = model->output + offset;
+ dbuff_seg[i].iova_addr = rte_mem_virt2iova(model->output + offset);
+ dbuff_seg[i].length = bufsz;
+ dbuff_seg[i].next = NULL;
+ d_segs[i] = &dbuff_seg[i];
+ offset += bufsz;
+ }
+ }
+
+ rte_ml_io_dequantize(t->cmn.opt->dev_id, model->id, q_segs, d_segs);
if (model->reference == NULL)
goto dump_output_pass;
diff --git a/app/test-mldev/test_inference_common.h b/app/test-mldev/test_inference_common.h
index 8f27af25e4..3f4ba3219b 100644
--- a/app/test-mldev/test_inference_common.h
+++ b/app/test-mldev/test_inference_common.h
@@ -11,11 +11,16 @@
#include "test_model_common.h"
+#define ML_TEST_MAX_IO_SIZE 32
+
struct ml_request {
uint8_t *input;
uint8_t *output;
uint16_t fid;
uint64_t niters;
+
+ struct rte_ml_buff_seg *inp_buf_segs[ML_TEST_MAX_IO_SIZE];
+ struct rte_ml_buff_seg *out_buf_segs[ML_TEST_MAX_IO_SIZE];
};
struct ml_core_args {
@@ -38,6 +43,7 @@ struct test_inference {
/* test specific data */
struct ml_model model[ML_TEST_MAX_MODELS];
+ struct rte_mempool *buf_seg_pool;
struct rte_mempool *op_pool;
uint64_t nb_used;
diff --git a/app/test-mldev/test_model_common.c b/app/test-mldev/test_model_common.c
index 8dbb0ff89f..c517a50611 100644
--- a/app/test-mldev/test_model_common.c
+++ b/app/test-mldev/test_model_common.c
@@ -50,12 +50,6 @@ ml_model_load(struct ml_test *test, struct ml_options *opt, struct ml_model *mod
return ret;
}
- /* Update number of batches */
- if (opt->batches == 0)
- model->nb_batches = model->info.batch_size;
- else
- model->nb_batches = opt->batches;
-
model->state = MODEL_LOADED;
return 0;
diff --git a/app/test-mldev/test_model_common.h b/app/test-mldev/test_model_common.h
index c1021ef1b6..a207e54ab7 100644
--- a/app/test-mldev/test_model_common.h
+++ b/app/test-mldev/test_model_common.h
@@ -31,7 +31,6 @@ struct ml_model {
uint8_t *reference;
struct rte_mempool *io_pool;
- uint32_t nb_batches;
};
int ml_model_load(struct ml_test *test, struct ml_options *opt, struct ml_model *model,
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index e553554b3a..8562bac77c 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -41,6 +41,11 @@ DPDK Release 23.11
New Features
------------
+ * **Added support for models with multiple I/O in mldev library.**
+
+ Added support in mldev library for models with multiple inputs and outputs.
+
+
.. This section should contain new features added in this release.
Sample format:
@@ -122,6 +127,11 @@ API Changes
* mldev: Updated mldev API to support models with multiple inputs and outputs
Updated the structure ``rte_ml_model_info`` to support input and output with
arbitrary shapes.
+ Added support for ``rte_ml_io_layout``. Two layout types split and packed are
+ supported by the specification, which enables higher control in handling models
+ with multiple inputs and outputs. Updated ``rte_ml_op``, ``rte_ml_io_quantize``
+ and ``rte_ml_io_dequantize`` to support an array of ``rte_ml_buff_seg`` for
+ inputs and outputs and removed use of batches argument.
ABI Changes
-----------
diff --git a/doc/guides/tools/testmldev.rst b/doc/guides/tools/testmldev.rst
index 741abd722e..9b1565a457 100644
--- a/doc/guides/tools/testmldev.rst
+++ b/doc/guides/tools/testmldev.rst
@@ -106,11 +106,6 @@ The following are the command-line options supported by the test application.
Queue size would translate into ``rte_ml_dev_qp_conf::nb_desc`` field during queue-pair creation.
Default value is ``1``.
-``--batches <n>``
- Set the number batches in the input file provided for inference run.
- When not specified, the test would assume the number of batches
- is the batch size of the model.
-
``--tolerance <n>``
Set the tolerance value in percentage to be used for output validation.
Default value is ``0``.
@@ -282,7 +277,6 @@ Supported command line options for inference tests are following::
--burst_size
--queue_pairs
--queue_size
- --batches
--tolerance
--stats
diff --git a/drivers/ml/cnxk/cn10k_ml_dev.h b/drivers/ml/cnxk/cn10k_ml_dev.h
index 6ca0b0bb6e..c73bf7d001 100644
--- a/drivers/ml/cnxk/cn10k_ml_dev.h
+++ b/drivers/ml/cnxk/cn10k_ml_dev.h
@@ -30,6 +30,9 @@
/* Maximum number of descriptors per queue-pair */
#define ML_CN10K_MAX_DESC_PER_QP 1024
+/* Maximum number of inputs / outputs per model */
+#define ML_CN10K_MAX_INPUT_OUTPUT 32
+
/* Maximum number of segments for IO data */
#define ML_CN10K_MAX_SEGMENTS 1
diff --git a/drivers/ml/cnxk/cn10k_ml_model.c b/drivers/ml/cnxk/cn10k_ml_model.c
index 26df8d9ff9..e0b750cd8e 100644
--- a/drivers/ml/cnxk/cn10k_ml_model.c
+++ b/drivers/ml/cnxk/cn10k_ml_model.c
@@ -520,9 +520,11 @@ cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
struct rte_ml_model_info *info;
struct rte_ml_io_info *output;
struct rte_ml_io_info *input;
+ struct cn10k_ml_dev *mldev;
uint8_t i;
uint8_t j;
+ mldev = dev->data->dev_private;
metadata = &model->metadata;
info = PLT_PTR_CAST(model->info);
input = PLT_PTR_ADD(info, sizeof(struct rte_ml_model_info));
@@ -537,7 +539,9 @@ cn10k_ml_model_info_set(struct rte_ml_dev *dev, struct cn10k_ml_model *model)
metadata->model.version[3]);
info->model_id = model->model_id;
info->device_id = dev->data->dev_id;
- info->batch_size = model->batch_size;
+ info->io_layout = RTE_ML_IO_LAYOUT_PACKED;
+ info->min_batches = model->batch_size;
+ info->max_batches = mldev->fw.req->jd.fw_load.cap.s.max_num_batches / model->batch_size;
info->nb_inputs = metadata->model.num_input;
info->input_info = input;
info->nb_outputs = metadata->model.num_output;
diff --git a/drivers/ml/cnxk/cn10k_ml_ops.c b/drivers/ml/cnxk/cn10k_ml_ops.c
index e3faab81ba..1d72fb52a6 100644
--- a/drivers/ml/cnxk/cn10k_ml_ops.c
+++ b/drivers/ml/cnxk/cn10k_ml_ops.c
@@ -471,9 +471,9 @@ cn10k_ml_prep_fp_job_descriptor(struct rte_ml_dev *dev, struct cn10k_ml_req *req
req->jd.hdr.sp_flags = 0x0;
req->jd.hdr.result = roc_ml_addr_ap2mlip(&mldev->roc, &req->result);
req->jd.model_run.input_ddr_addr =
- PLT_U64_CAST(roc_ml_addr_ap2mlip(&mldev->roc, op->input.addr));
+ PLT_U64_CAST(roc_ml_addr_ap2mlip(&mldev->roc, op->input[0]->addr));
req->jd.model_run.output_ddr_addr =
- PLT_U64_CAST(roc_ml_addr_ap2mlip(&mldev->roc, op->output.addr));
+ PLT_U64_CAST(roc_ml_addr_ap2mlip(&mldev->roc, op->output[0]->addr));
req->jd.model_run.num_batches = op->nb_batches;
}
@@ -856,7 +856,11 @@ cn10k_ml_model_xstats_reset(struct rte_ml_dev *dev, int32_t model_id, const uint
static int
cn10k_ml_cache_model_data(struct rte_ml_dev *dev, uint16_t model_id)
{
+ struct rte_ml_model_info *info;
struct cn10k_ml_model *model;
+ struct rte_ml_buff_seg seg[2];
+ struct rte_ml_buff_seg *inp;
+ struct rte_ml_buff_seg *out;
struct rte_ml_op op;
char str[RTE_MEMZONE_NAMESIZE];
@@ -864,12 +868,22 @@ cn10k_ml_cache_model_data(struct rte_ml_dev *dev, uint16_t model_id)
uint64_t isize = 0;
uint64_t osize = 0;
int ret = 0;
+ uint32_t i;
model = dev->data->models[model_id];
+ info = (struct rte_ml_model_info *)model->info;
+ inp = &seg[0];
+ out = &seg[1];
/* Create input and output buffers. */
- rte_ml_io_input_size_get(dev->data->dev_id, model_id, model->batch_size, &isize, NULL);
- rte_ml_io_output_size_get(dev->data->dev_id, model_id, model->batch_size, &osize, NULL);
+ for (i = 0; i < info->nb_inputs; i++)
+ isize += info->input_info[i].size;
+
+ for (i = 0; i < info->nb_outputs; i++)
+ osize += info->output_info[i].size;
+
+ isize = model->batch_size * isize;
+ osize = model->batch_size * osize;
snprintf(str, RTE_MEMZONE_NAMESIZE, "%s_%u", "ml_dummy_io", model_id);
mz = plt_memzone_reserve_aligned(str, isize + osize, 0, ML_CN10K_ALIGN_SIZE);
@@ -877,17 +891,22 @@ cn10k_ml_cache_model_data(struct rte_ml_dev *dev, uint16_t model_id)
return -ENOMEM;
memset(mz->addr, 0, isize + osize);
+ seg[0].addr = mz->addr;
+ seg[0].iova_addr = mz->iova;
+ seg[0].length = isize;
+ seg[0].next = NULL;
+
+ seg[1].addr = PLT_PTR_ADD(mz->addr, isize);
+ seg[1].iova_addr = mz->iova + isize;
+ seg[1].length = osize;
+ seg[1].next = NULL;
+
op.model_id = model_id;
op.nb_batches = model->batch_size;
op.mempool = NULL;
- op.input.addr = mz->addr;
- op.input.length = isize;
- op.input.next = NULL;
-
- op.output.addr = PLT_PTR_ADD(op.input.addr, isize);
- op.output.length = osize;
- op.output.next = NULL;
+ op.input = &inp;
+ op.output = &out;
memset(model->req, 0, sizeof(struct cn10k_ml_req));
ret = cn10k_ml_inference_sync(dev, &op);
@@ -919,8 +938,9 @@ cn10k_ml_dev_info_get(struct rte_ml_dev *dev, struct rte_ml_dev_info *dev_info)
else if (strcmp(mldev->fw.poll_mem, "ddr") == 0)
dev_info->max_desc = ML_CN10K_MAX_DESC_PER_QP;
+ dev_info->max_io = ML_CN10K_MAX_INPUT_OUTPUT;
dev_info->max_segments = ML_CN10K_MAX_SEGMENTS;
- dev_info->min_align_size = ML_CN10K_ALIGN_SIZE;
+ dev_info->align_size = ML_CN10K_ALIGN_SIZE;
return 0;
}
@@ -2139,15 +2159,14 @@ cn10k_ml_io_output_size_get(struct rte_ml_dev *dev, uint16_t model_id, uint32_t
}
static int
-cn10k_ml_io_quantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batches, void *dbuffer,
- void *qbuffer)
+cn10k_ml_io_quantize(struct rte_ml_dev *dev, uint16_t model_id, struct rte_ml_buff_seg **dbuffer,
+ struct rte_ml_buff_seg **qbuffer)
{
struct cn10k_ml_model *model;
uint8_t model_input_type;
uint8_t *lcl_dbuffer;
uint8_t *lcl_qbuffer;
uint8_t input_type;
- uint32_t batch_id;
float qscale;
uint32_t i;
uint32_t j;
@@ -2160,11 +2179,9 @@ cn10k_ml_io_quantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batc
return -EINVAL;
}
- lcl_dbuffer = dbuffer;
- lcl_qbuffer = qbuffer;
- batch_id = 0;
+ lcl_dbuffer = dbuffer[0]->addr;
+ lcl_qbuffer = qbuffer[0]->addr;
-next_batch:
for (i = 0; i < model->metadata.model.num_input; i++) {
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
input_type = model->metadata.input1[i].input_type;
@@ -2218,23 +2235,18 @@ cn10k_ml_io_quantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batc
lcl_qbuffer += model->addr.input[i].sz_q;
}
- batch_id++;
- if (batch_id < PLT_DIV_CEIL(nb_batches, model->batch_size))
- goto next_batch;
-
return 0;
}
static int
-cn10k_ml_io_dequantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batches,
- void *qbuffer, void *dbuffer)
+cn10k_ml_io_dequantize(struct rte_ml_dev *dev, uint16_t model_id, struct rte_ml_buff_seg **qbuffer,
+ struct rte_ml_buff_seg **dbuffer)
{
struct cn10k_ml_model *model;
uint8_t model_output_type;
uint8_t *lcl_qbuffer;
uint8_t *lcl_dbuffer;
uint8_t output_type;
- uint32_t batch_id;
float dscale;
uint32_t i;
uint32_t j;
@@ -2247,11 +2259,9 @@ cn10k_ml_io_dequantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_ba
return -EINVAL;
}
- lcl_dbuffer = dbuffer;
- lcl_qbuffer = qbuffer;
- batch_id = 0;
+ lcl_dbuffer = dbuffer[0]->addr;
+ lcl_qbuffer = qbuffer[0]->addr;
-next_batch:
for (i = 0; i < model->metadata.model.num_output; i++) {
if (i < MRVL_ML_NUM_INPUT_OUTPUT_1) {
output_type = model->metadata.output1[i].output_type;
@@ -2306,10 +2316,6 @@ cn10k_ml_io_dequantize(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_ba
lcl_dbuffer += model->addr.output[i].sz_d;
}
- batch_id++;
- if (batch_id < PLT_DIV_CEIL(nb_batches, model->batch_size))
- goto next_batch;
-
return 0;
}
diff --git a/lib/mldev/meson.build b/lib/mldev/meson.build
index 5769b0640a..0079ccd205 100644
--- a/lib/mldev/meson.build
+++ b/lib/mldev/meson.build
@@ -35,7 +35,7 @@ driver_sdk_headers += files(
'mldev_utils.h',
)
-deps += ['mempool']
+deps += ['mempool', 'mbuf']
if get_option('buildtype').contains('debug')
cflags += [ '-DRTE_LIBRTE_ML_DEV_DEBUG' ]
diff --git a/lib/mldev/rte_mldev.c b/lib/mldev/rte_mldev.c
index 0d8ccd3212..9a48ed3e94 100644
--- a/lib/mldev/rte_mldev.c
+++ b/lib/mldev/rte_mldev.c
@@ -730,8 +730,8 @@ rte_ml_io_output_size_get(int16_t dev_id, uint16_t model_id, uint32_t nb_batches
}
int
-rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void *dbuffer,
- void *qbuffer)
+rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, struct rte_ml_buff_seg **dbuffer,
+ struct rte_ml_buff_seg **qbuffer)
{
struct rte_ml_dev *dev;
@@ -754,12 +754,12 @@ rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void
return -EINVAL;
}
- return (*dev->dev_ops->io_quantize)(dev, model_id, nb_batches, dbuffer, qbuffer);
+ return (*dev->dev_ops->io_quantize)(dev, model_id, dbuffer, qbuffer);
}
int
-rte_ml_io_dequantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void *qbuffer,
- void *dbuffer)
+rte_ml_io_dequantize(int16_t dev_id, uint16_t model_id, struct rte_ml_buff_seg **qbuffer,
+ struct rte_ml_buff_seg **dbuffer)
{
struct rte_ml_dev *dev;
@@ -782,7 +782,7 @@ rte_ml_io_dequantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, voi
return -EINVAL;
}
- return (*dev->dev_ops->io_dequantize)(dev, model_id, nb_batches, qbuffer, dbuffer);
+ return (*dev->dev_ops->io_dequantize)(dev, model_id, qbuffer, dbuffer);
}
/** Initialise rte_ml_op mempool element */
diff --git a/lib/mldev/rte_mldev.h b/lib/mldev/rte_mldev.h
index 6204df0930..316c6fd018 100644
--- a/lib/mldev/rte_mldev.h
+++ b/lib/mldev/rte_mldev.h
@@ -228,12 +228,14 @@ struct rte_ml_dev_info {
/**< Maximum allowed number of descriptors for queue pair by the device.
* @see struct rte_ml_dev_qp_conf::nb_desc
*/
+ uint16_t max_io;
+ /**< Maximum number of inputs/outputs supported per model. */
uint16_t max_segments;
/**< Maximum number of scatter-gather entries supported by the device.
* @see struct rte_ml_buff_seg struct rte_ml_buff_seg::next
*/
- uint16_t min_align_size;
- /**< Minimum alignment size of IO buffers used by the device. */
+ uint16_t align_size;
+ /**< Alignment size of IO buffers used by the device. */
};
/**
@@ -429,10 +431,28 @@ struct rte_ml_op {
/**< Reserved for future use. */
struct rte_mempool *mempool;
/**< Pool from which operation is allocated. */
- struct rte_ml_buff_seg input;
- /**< Input buffer to hold the inference data. */
- struct rte_ml_buff_seg output;
- /**< Output buffer to hold the inference output by the driver. */
+ struct rte_ml_buff_seg **input;
+ /**< Array of buffer segments to hold the inference input data.
+ *
+ * When the model supports IO layout RTE_ML_IO_LAYOUT_PACKED, size of
+ * the array is 1.
+ *
+ * When the model supports IO layout RTE_ML_IO_LAYOUT_SPLIT, size of
+ * the array is rte_ml_model_info::nb_inputs.
+ *
+ * @see struct rte_ml_dev_info::io_layout
+ */
+ struct rte_ml_buff_seg **output;
+ /**< Array of buffer segments to hold the inference output data.
+ *
+ * When the model supports IO layout RTE_ML_IO_LAYOUT_PACKED, size of
+ * the array is 1.
+ *
+ * When the model supports IO layout RTE_ML_IO_LAYOUT_SPLIT, size of
+ * the array is rte_ml_model_info::nb_outputs.
+ *
+ * @see struct rte_ml_dev_info::io_layout
+ */
union {
uint64_t user_u64;
/**< User data as uint64_t.*/
@@ -863,7 +883,37 @@ enum rte_ml_io_type {
/**< 16-bit brain floating point number. */
};
-/** Input and output data information structure
+/** ML I/O buffer layout */
+enum rte_ml_io_layout {
+ RTE_ML_IO_LAYOUT_PACKED,
+ /**< All inputs for the model should packed in a single buffer with
+ * no padding between individual inputs. The buffer is expected to
+ * be aligned to rte_ml_dev_info::align_size.
+ *
+ * When I/O segmentation is supported by the device, the packed
+ * data can be split into multiple segments. In this case, each
+ * segment is expected to be aligned to rte_ml_dev_info::align_size
+ *
+ * Same applies to output.
+ *
+ * @see struct rte_ml_dev_info::max_segments
+ */
+ RTE_ML_IO_LAYOUT_SPLIT
+ /**< Each input for the model should be stored as separate buffers
+ * and each input should be aligned to rte_ml_dev_info::align_size.
+ *
+ * When I/O segmentation is supported, each input can be split into
+ * multiple segments. In this case, each segment is expected to be
+ * aligned to rte_ml_dev_info::align_size
+ *
+ * Same applies to output.
+ *
+ * @see struct rte_ml_dev_info::max_segments
+ */
+};
+
+/**
+ * Input and output data information structure
*
* Specifies the type and shape of input and output data.
*/
@@ -873,7 +923,7 @@ struct rte_ml_io_info {
uint32_t nb_dims;
/**< Number of dimensions in shape */
uint32_t *shape;
- /**< Shape of the tensor */
+ /**< Shape of the tensor for rte_ml_model_info::min_batches of the model. */
enum rte_ml_io_type type;
/**< Type of data
* @see enum rte_ml_io_type
@@ -894,8 +944,16 @@ struct rte_ml_model_info {
/**< Model ID */
uint16_t device_id;
/**< Device ID */
- uint16_t batch_size;
- /**< Maximum number of batches that the model can process simultaneously */
+ enum rte_ml_io_layout io_layout;
+ /**< I/O buffer layout for the model */
+ uint16_t min_batches;
+ /**< Minimum number of batches that the model can process
+ * in one inference request
+ */
+ uint16_t max_batches;
+ /**< Maximum number of batches that the model can process
+ * in one inference request
+ */
uint32_t nb_inputs;
/**< Number of inputs */
const struct rte_ml_io_info *input_info;
@@ -1021,8 +1079,6 @@ rte_ml_io_output_size_get(int16_t dev_id, uint16_t model_id, uint32_t nb_batches
* The identifier of the device.
* @param[in] model_id
* Identifier for the model
- * @param[in] nb_batches
- * Number of batches in the dequantized input buffer
* @param[in] dbuffer
* Address of dequantized input data
* @param[in] qbuffer
@@ -1034,8 +1090,8 @@ rte_ml_io_output_size_get(int16_t dev_id, uint16_t model_id, uint32_t nb_batches
*/
__rte_experimental
int
-rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void *dbuffer,
- void *qbuffer);
+rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, struct rte_ml_buff_seg **dbuffer,
+ struct rte_ml_buff_seg **qbuffer);
/**
* Dequantize output data.
@@ -1047,8 +1103,6 @@ rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void
* The identifier of the device.
* @param[in] model_id
* Identifier for the model
- * @param[in] nb_batches
- * Number of batches in the dequantized output buffer
* @param[in] qbuffer
* Address of quantized output data
* @param[in] dbuffer
@@ -1060,8 +1114,8 @@ rte_ml_io_quantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void
*/
__rte_experimental
int
-rte_ml_io_dequantize(int16_t dev_id, uint16_t model_id, uint16_t nb_batches, void *qbuffer,
- void *dbuffer);
+rte_ml_io_dequantize(int16_t dev_id, uint16_t model_id, struct rte_ml_buff_seg **qbuffer,
+ struct rte_ml_buff_seg **dbuffer);
/* ML op pool operations */
diff --git a/lib/mldev/rte_mldev_core.h b/lib/mldev/rte_mldev_core.h
index 78b8b7633d..8530b07316 100644
--- a/lib/mldev/rte_mldev_core.h
+++ b/lib/mldev/rte_mldev_core.h
@@ -523,8 +523,6 @@ typedef int (*mldev_io_output_size_get_t)(struct rte_ml_dev *dev, uint16_t model
* ML device pointer.
* @param model_id
* Model ID to use.
- * @param nb_batches
- * Number of batches.
* @param dbuffer
* Pointer t de-quantized data buffer.
* @param qbuffer
@@ -534,8 +532,9 @@ typedef int (*mldev_io_output_size_get_t)(struct rte_ml_dev *dev, uint16_t model
* - 0 on success.
* - <0, error on failure.
*/
-typedef int (*mldev_io_quantize_t)(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batches,
- void *dbuffer, void *qbuffer);
+typedef int (*mldev_io_quantize_t)(struct rte_ml_dev *dev, uint16_t model_id,
+ struct rte_ml_buff_seg **dbuffer,
+ struct rte_ml_buff_seg **qbuffer);
/**
* @internal
@@ -546,8 +545,6 @@ typedef int (*mldev_io_quantize_t)(struct rte_ml_dev *dev, uint16_t model_id, ui
* ML device pointer.
* @param model_id
* Model ID to use.
- * @param nb_batches
- * Number of batches.
* @param qbuffer
* Pointer t de-quantized data buffer.
* @param dbuffer
@@ -557,8 +554,9 @@ typedef int (*mldev_io_quantize_t)(struct rte_ml_dev *dev, uint16_t model_id, ui
* - 0 on success.
* - <0, error on failure.
*/
-typedef int (*mldev_io_dequantize_t)(struct rte_ml_dev *dev, uint16_t model_id, uint16_t nb_batches,
- void *qbuffer, void *dbuffer);
+typedef int (*mldev_io_dequantize_t)(struct rte_ml_dev *dev, uint16_t model_id,
+ struct rte_ml_buff_seg **qbuffer,
+ struct rte_ml_buff_seg **dbuffer);
/**
* @internal
--
2.41.0
^ permalink raw reply [relevance 1%]
* Re: [PATCH v4 1/3] lib: introduce dispatcher library
2023-09-27 8:13 3% ` Bruce Richardson
2023-09-28 7:44 0% ` Mattias Rönnblom
@ 2023-10-03 17:31 0% ` Jerin Jacob
1 sibling, 0 replies; 200+ results
From: Jerin Jacob @ 2023-10-03 17:31 UTC (permalink / raw)
To: Bruce Richardson
Cc: Mattias Rönnblom, Mattias Rönnblom, dev, Jerin Jacob,
techboard, harry.van.haaren, Peter Nilsson, Heng Wang,
Naga Harish K S V, Pavan Nikhilesh, Gujjar Abhinandan S,
Erik Gabriel Carrillo, Shijith Thotton, Hemant Agrawal,
Sachin Saxena, Liang Ma, Peter Mccarthy, Zhirun Yan
On Wed, Sep 27, 2023 at 1:43 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Tue, Sep 26, 2023 at 11:58:37PM +0530, Jerin Jacob wrote:
> > On Mon, Sep 25, 2023 at 12:41 PM Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> > >
> > > On 2023-09-22 09:38, Mattias Rönnblom wrote:
> > >
> > > <snip>
> > >
> > > > +int
> > > > +rte_dispatcher_create(uint8_t id, uint8_t event_dev_id)
> > > > +{
> > >
> > >
> > > There are two changes I'm considering:
> > >
> > > 1) Removing the "id" to identify the dispatcher, replacing it with an
> > > forward-declared rte_dispatcher struct pointer.
> > >
> > > struct rte_dispatcher;
> > >
> > > struct rte_dispatcher *
> > > rte_dispatcher_create(uint8_t event_dev_id);
> > >
> > >
> > > The original reason for using an integer id to identify a dispatcher is
> > > to make it look like everything else in Eventdev. I find this pattern a
> > > little awkward to use - in particular the fact the id is
> > > application-allocated (and thus require coordination between different
> > > part of the application in case multiple instances are used).
> > >
> > > 2) Adding a flags field to the create function "for future use". But
> > > since the API is experimental, there may not be that much need to
> > > attempt to be future-proof?
> > >
> > > Any thoughts are appreciated.
> >
> > IMO, better to have rte_dispatcher_create(struct
> > rte_dispatch_create_params *params)
> > for better future proofing with specific
> > rte_dispatch_crearte_params_init() API(No need to add reserved fields
> > in rte_dispatch_create_params now, may need only for before removing
> > experimental status)
> >
> > Just 2c.
> >
>
> I don't like using structs in those cases, I'd much rather have a flags
> parameter, as flags can be checked for explicit zeros for future proofing,
> while a struct cannot be checked for extra space on the end for future
> fields added.
For lib/dispatcher library, I have don't have specific preference. So
anything is fine for me.
However, I thought of understanding your rationale for arguments vs
structure(Looks like more of vi vs emac discussion) for _my
understanding_.
In my view,
# Use flags for setting up to express specific behavior, not as
inputting a lot of input parameters.
# Do we need to check extra space if struct have reserved fields and
having init() functions for filling default
>
> Furthermore, if we need to add new parameters to the create function, I
> actually believe it is better to add them as explicit parameters rather
> than new fields to the struct. Struct fields can be missed by a user just
> recompiling, while new function parameters will be flagged by the compiler
I would see this as on the positive side, when
- Same code base needs to support multiple DPDK versions.
- A lot of times, API consumer may need only _default_ values. Like
local_cache value in mempool_create API. So struct with _init() get
required values in easy way.
My views are based mostly used existing rte_mempool_create() APIs. For
some reason, I don't like this scheme.
struct rte_mempool *
rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
unsigned cache_size, unsigned private_data_size,
rte_mempool_ctor_t *mp_init, void *mp_init_arg,
rte_mempool_obj_cb_t *obj_init, void *obj_init_arg,
int socket_id, unsigned flags);
> to make the user aware of the change. [There would be no change for ABI
> compatibility as function versioning would be usable in both cases]
Yes. But need to too much template code via VERSION_SYMBOL where
structure scheme does not need.
>
> /Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH v3] bus/cdx: provide driver flag for optional resource mapping
2023-09-29 15:17 3% ` David Marchand
@ 2023-10-04 10:06 0% ` Gangurde, Abhijit
2023-10-04 12:54 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Gangurde, Abhijit @ 2023-10-04 10:06 UTC (permalink / raw)
To: David Marchand; +Cc: Gupta, Nipun, Agarwal, Nikhil, dev, Yigit, Ferruh, thomas
[AMD Official Use Only - General]
> <abhijit.gangurde@amd.com> wrote:
> > @@ -383,10 +384,12 @@ cdx_probe_one_driver(struct rte_cdx_driver *dr,
> > CDX_BUS_DEBUG(" probe device %s using driver: %s", dev_name,
> > dr->driver.name);
> >
> > - ret = cdx_vfio_map_resource(dev);
> > - if (ret != 0) {
> > - CDX_BUS_ERR("CDX map device failed: %d", ret);
> > - goto error_map_device;
> > + if (dr->drv_flags & RTE_CDX_DRV_NEED_MAPPING) {
> > + ret = cdx_vfio_map_resource(dev);
> > + if (ret != 0) {
> > + CDX_BUS_ERR("CDX map device failed: %d", ret);
> > + goto error_map_device;
> > + }
> > }
> >
> > /* call the driver probe() function */
> > diff --git a/drivers/bus/cdx/rte_bus_cdx.h b/drivers/bus/cdx/rte_bus_cdx.h
> > new file mode 100644
> > index 0000000000..4ca12f90c4
> > --- /dev/null
> > +++ b/drivers/bus/cdx/rte_bus_cdx.h
> > @@ -0,0 +1,52 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright (C) 2023, Advanced Micro Devices, Inc.
> > + */
> > +
> > +#ifndef RTE_BUS_CDX_H
> > +#define RTE_BUS_CDX_H
> > +
> > +/**
> > + * @file
> > + * CDX device & driver interface
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/* Forward declarations */
> > +struct rte_cdx_device;
> > +
> > +/**
> > + * Map the CDX device resources in user space virtual memory address.
> > + *
> > + * Note that driver should not call this function when flag
> > + * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
> > + * you when it's on.
>
> Why should we export this function in the application ABI, if it is
> only used by drivers?
This can be called from an application as well if this flag is not set hence, we need to export this function.
If needed, I can update the description of the API.
Thanks,
Abhijit
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3] bus/cdx: provide driver flag for optional resource mapping
2023-10-04 10:06 0% ` Gangurde, Abhijit
@ 2023-10-04 12:54 0% ` David Marchand
2023-10-13 11:51 0% ` Gangurde, Abhijit
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-10-04 12:54 UTC (permalink / raw)
To: Gangurde, Abhijit
Cc: Gupta, Nipun, Agarwal, Nikhil, dev, Yigit, Ferruh, thomas
On Wed, Oct 4, 2023 at 12:06 PM Gangurde, Abhijit
<abhijit.gangurde@amd.com> wrote:
> > > +/**
> > > + * Map the CDX device resources in user space virtual memory address.
> > > + *
> > > + * Note that driver should not call this function when flag
> > > + * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
> > > + * you when it's on.
> >
> > Why should we export this function in the application ABI, if it is
> > only used by drivers?
>
> This can be called from an application as well if this flag is not set hence, we need to export this function.
What kind of applications / in which usecase, one would need to map
the device resources?
Except a driver?
--
David Marchand
^ permalink raw reply [relevance 0%]
* [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code
@ 2023-10-04 12:59 3% Nithin Dabilpuram
2023-10-10 13:10 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Nithin Dabilpuram @ 2023-10-04 12:59 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko
Cc: jerinj, dev, Nithin Dabilpuram
Add IPsec event subtype range for PMD specific code in order
to accommodate wide range of errors that PMD supports.
These IPsec event subtypes are used when an error doesn't
match the spec defined subtypes between RTE_ETH_EVENT_IPSEC_UNKNOWN
and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
to avoid ABI breakage.
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
---
lib/ethdev/rte_ethdev.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 8542257721..f949dfc83d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
* eth device.
*/
enum rte_eth_event_ipsec_subtype {
+ /** PMD specific error start */
+ RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
+ /** PMD specific error end */
+ RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
/** Unknown event type */
RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
/** Sequence number overflow */
--
2.25.1
^ permalink raw reply [relevance 3%]
* Minutes of Technical Board Meeting, 2023-05-31
@ 2023-10-04 15:11 4% Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2023-10-04 15:11 UTC (permalink / raw)
To: techboard, dev
Attendees:
- Aaron
- Bruce
- David
- Ferruh
- Jerin
- Kevin
- Konstantin
- Maxime
- Nathan
- Patrick
- Stephen
- Tyler
Minutes:
- Bruce will be moderator on June 14, 2023
- Call for additional items
- Userspace Dublin
- CFP - Ready to go.
- Awaiting on final TB review, feedback received from
Kevin, Thomas
- Virtual Speakers
- Do we exclude or include? Reality is we will need to include
- In-person is always the most desirable, we can't exclude virtual
speakers
- Quality of Virtual experience needs to improve
Any feedback to the LF team re: virtual experience
- Form review from Evi with Nathan
- Submit all the changes
- Review process is open for the entire board, to be sent out by
Nathan.
- Nathan to send out an invite for Thu, July 6
- Submit expenses ASAP
- LF hires
- Ben Thomas to solicit feedback from others and building more
content to promote project
- Feel free to reach out and help Ben with this effort
- David Young starts on June 12
- Discuss on how to align the next LTS release for
- From https://mails.dpdk.org/archives/dev/2023-May/269411.html
- YAGNI vs reserved fields with init()
- Discussion with Jerin, should we follow YAGNI which will need
to use next-abi.
- Testing concerns with next-abi. Needs even more CI runs to ensure
proper coverage
- More time, and additional matrix functions
- Adding checks for reserved fields as a key.
- Checks are needed for the old code + new library case
- Reserved fields also cause bad behavior w.r.t. development
- Reserved fields also take up space that may never be needed
- General discussions about ABIs
- Thomas prefers the two versions approach (current, next)
- Have a single define and just removing it should work.
- NEXT abi is "cleaner" in some cases
- NEXT ABI is probably the best approach and we will try it out when
going forward on a case-by-case basis
- What it takes to Extend the API breaking release more than a
year as first step.
- Cannot discuss today, but we need to discuss the period of
compatibility that we currently support
- Maybe it can be extended based on some other approach
- Discuss how to better share tree maintenance work for the main
libraries.
- new maintainers?
- Need for more maintainers in the libraries / examples, not enough
reviewers, etc.
- Reach out to existing maintainers for additional subtree splitting
- Always depends on the library, and some have plenty of coverage
- Maybe also doing some restructuring of the libraries
- new tree maintainers
- lack of faster merging because there aren't enough tree
maintainers
- Create more subtrees?
- Creates a more maintainership burden
- Next step to start looking at what to split, who to do the work,
etc. Needs more discussions, though.
(Didn't get to...)
- Thomas requests people read email on Power management brainstorm
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH] eventdev: ensure 16-byte alignment for events
@ 2023-10-05 12:06 3% ` Bruce Richardson
2023-10-05 13:11 0% ` Jerin Jacob
2023-10-06 9:37 5% ` [PATCH v2] " Bruce Richardson
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-10-05 12:06 UTC (permalink / raw)
To: dev; +Cc: Jerin Jacob
On Thu, Oct 05, 2023 at 12:51:00PM +0100, Bruce Richardson wrote:
> The event structure in DPDK is 16-bytes in size, and events are
> regularly passed as parameters directly rather than being passed as
> pointers. To help compiler optimize correctly, we can explicitly request
> 16-byte alignment for events, which means that we should be able
> to do aligned vector loads/stores (e.g. with SSE or Neon) when working
> with those events.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> lib/eventdev/rte_eventdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index 2ba8a7b090..bb0d59b059 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -1344,7 +1344,7 @@ struct rte_event {
> struct rte_event_vector *vec;
> /**< Event vector pointer. */
> };
> -};
> +} __rte_aligned(16);
>
Looking for feedback on this idea - hence the fact this is going as an RFC.
It seems to me something that should be done for performance reasons, but
I'm not sure if there are any negative consequences of doing this.
Since this is an ABI-affecting change, a decision on this needs to be made
for 23.11, or else it will be locked in for at least another year. Hence me
sending it now as an RFC late in the release cycle, rather than deferring
to next release.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH] eventdev: ensure 16-byte alignment for events
2023-10-05 12:06 3% ` Bruce Richardson
@ 2023-10-05 13:11 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-10-05 13:11 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Jerin Jacob, Pavan Nikhilesh, Abdullah Sevincer,
Shijith Thotton, Hemant Agrawal, Sachin Saxena, Van Haaren,
Harry, Mattias Rönnblom, Liang Ma, Peter Mccarthy,
Honnappa Nagarahalli
On Thu, Oct 5, 2023 at 6:01 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Oct 05, 2023 at 12:51:00PM +0100, Bruce Richardson wrote:
> > The event structure in DPDK is 16-bytes in size, and events are
> > regularly passed as parameters directly rather than being passed as
> > pointers. To help compiler optimize correctly, we can explicitly request
> > 16-byte alignment for events, which means that we should be able
> > to do aligned vector loads/stores (e.g. with SSE or Neon) when working
> > with those events.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> > lib/eventdev/rte_eventdev.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index 2ba8a7b090..bb0d59b059 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1344,7 +1344,7 @@ struct rte_event {
> > struct rte_event_vector *vec;
> > /**< Event vector pointer. */
> > };
> > -};
> > +} __rte_aligned(16);
> >
>
+ Eventdev driver maintainers for review and for performance testing.
> Looking for feedback on this idea - hence the fact this is going as an RFC.
Are you seeing any performance improvement ? Look like only DLB2
driver only using SEE or AVX512 instructions.
> It seems to me something that should be done for performance reasons, but
> I'm not sure if there are any negative consequences of doing this.
In general, it looks OK, However, We may need more testing.
I can only speculate the following as of now, Since event memory is
allocated from stack most case,
there may stack pointer fix up in code for desired alignment ie. some
add/sub instructions which comes for free most likely due to pipeline.
We will test on Marvel HW. Request others to test on their HWs.
>
> Since this is an ABI-affecting change, a decision on this needs to be made
> for 23.11, or else it will be locked in for at least another year. Hence me
> sending it now as an RFC late in the release cycle, rather than deferring
> to next release.
>
> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH] eventdev: ensure 16-byte alignment for events
@ 2023-10-06 7:19 3% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-10-06 7:19 UTC (permalink / raw)
To: Bruce Richardson, Thomas Monjalon
Cc: dev, Jerin Jacob, Pavan Nikhilesh, Abdullah Sevincer,
Shijith Thotton, Hemant Agrawal, Sachin Saxena, Van Haaren,
Harry, Mattias Rönnblom, Liang Ma, Peter Mccarthy,
Honnappa Nagarahalli
On Thu, Oct 5, 2023 at 6:52 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Oct 05, 2023 at 06:41:34PM +0530, Jerin Jacob wrote:
> > On Thu, Oct 5, 2023 at 6:01 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Thu, Oct 05, 2023 at 12:51:00PM +0100, Bruce Richardson wrote:
> > > > The event structure in DPDK is 16-bytes in size, and events are
> > > > regularly passed as parameters directly rather than being passed as
> > > > pointers. To help compiler optimize correctly, we can explicitly request
> > > > 16-byte alignment for events, which means that we should be able
> > > > to do aligned vector loads/stores (e.g. with SSE or Neon) when working
> > > > with those events.
> > > >
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > ---
> > > > lib/eventdev/rte_eventdev.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > > > index 2ba8a7b090..bb0d59b059 100644
> > > > --- a/lib/eventdev/rte_eventdev.h
> > > > +++ b/lib/eventdev/rte_eventdev.h
> > > > @@ -1344,7 +1344,7 @@ struct rte_event {
> > > > struct rte_event_vector *vec;
> > > > /**< Event vector pointer. */
> > > > };
> > > > -};
> > > > +} __rte_aligned(16);
> > > >
> > >
> >
> > + Eventdev driver maintainers for review and for performance testing.
> >
> > > Looking for feedback on this idea - hence the fact this is going as an RFC.
> >
> > Are you seeing any performance improvement ? Look like only DLB2
> > driver only using SEE or AVX512 instructions.
> >
>
> The idea would be that the driver code (and eventdev code) should not need
> to use SSE directly. If we mark the event struct as aligned, it should help
> encourage the compiler to use these instructions under-the-hood. For
> example, when copying an event, the compiler should be emitting 128-bit
> loads and stores for most platforms.
With limited testing, there is no performance regression is seen. In
fact, the compiler is generating the
same instruction stream on both cases.
If there are no objections from others, Please send v1 with "ABI
change" update in doc/guides/rel_notes/release_23_11.rst.
With above change,
Acked-by: Jerin Jacob <jerinj@marvell.com>
NOTE: I already made PR to Thomas for rc1. Since is needs to part of
rc1, I need to sync with @Thomas Monjalon as well.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-09-27 13:13 0% ` Ferruh Yigit
@ 2023-10-06 8:27 3% ` David Marchand
2023-10-06 11:19 0% ` Ferruh Yigit
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-10-06 8:27 UTC (permalink / raw)
To: Sivaprasad Tummala
Cc: ruifeng.wang, zhoumin, drc, kda, bruce.richardson,
konstantin.v.ananyev, dev, Ferruh Yigit
On Fri, Aug 11, 2023 at 8:08 AM Sivaprasad Tummala
<sivaprasad.tummala@amd.com> wrote:
>
> This patch removes RTE_CPUFLAG_NUMFLAGS to allow new CPU
> features without breaking ABI each time.
>
> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
I relooked at the API and I see one case (that I had missed in my
previous reply) where an ABI issue may be present so I updated the
commitlog in this regard.
And then I merged this patch, with a few modifications.
- removed the deprecation notice and updated RN,
- removed leftover "Last item" comments in arch cpuflag headers,
I hope everyone is happy with this.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH 4/4] pcapng: move timestamp calculation into pdump
@ 2023-10-06 9:10 3% ` David Marchand
2023-10-06 14:59 0% ` Kevin Traynor
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-10-06 9:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, Reshma Pattan, Quentin Armitage, Thomas Monjalon, Kevin Traynor
On Wed, Oct 4, 2023 at 7:13 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 2 Oct 2023 10:15:25 +0200
> David Marchand <david.marchand@redhat.com> wrote:
>
> > >
> >
> > Bugzilla ID: 1291 ?
> >
> > This patch (and patch 3) updates some pcapng API, is it worth a RN update?
> >
> > > Fixes: c882eb544842 ("pcapng: fix timestamp wrapping in output files")
> >
> > Is it worth backporting?
> > I would say no, as some API update was needed to fix the issue.
> > But on the other hand, this is an experimental API, so I prefer to ask.
> >
> >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> Good question.
> Is experimental API allowed to change in a stable release?
I don't think this is cleary described in our ABI policy.
An experimental API may be changed at any time, but nothing is said
wrt backports.
Breaking an API is always a pain, and for a LTS release it would
probably be badly accepted by users.
Cc: Kevin for his opinion.
We may need a clarification on this topic in the doc.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [PATCH v2] eventdev: ensure 16-byte alignment for events
2023-10-05 12:06 3% ` Bruce Richardson
@ 2023-10-06 9:37 5% ` Bruce Richardson
2023-10-06 9:45 8% ` [PATCH v3] " Bruce Richardson
2023-10-06 10:29 8% ` [PATCH v4] " Bruce Richardson
3 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-10-06 9:37 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Jerin Jacob
The event structure in DPDK is 16-bytes in size, and events are
regularly passed as parameters directly rather than being passed as
pointers. To help compiler optimize correctly, we can explicitly request
16-byte alignment for events, which means that we should be able
to do aligned vector loads/stores (e.g. with SSE or Neon) when working
with those events.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
doc/guides/rel_notes/release_23_11.rst | 4 ++++
lib/eventdev/rte_eventdev.h | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 261594aacc..48c19ae52a 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -158,6 +158,10 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* The ``rte_event`` structure, used by eventdev library and DPDK "event" class drivers,
+ is now 16-byte aligned, as well as being 16-bytes in size.
+ In previous releases, the structure only required 8-byte alignement.
+
Known Issues
------------
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 2ea98302b8..5b7c5b3399 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1284,6 +1284,8 @@ struct rte_event_vector {
/**
* The generic *rte_event* structure to hold the event attributes
* for dequeue and enqueue operation
+ *
+ * This structure must be kept at 16-bytes in size, and has 16-byte alignment.
*/
struct rte_event {
/** WORD0 */
@@ -1356,7 +1358,9 @@ struct rte_event {
struct rte_event_vector *vec;
/**< Event vector pointer. */
};
-};
+} __rte_aligned(16);
+
+_Static_assert(sizeof(struct rte_event) == 16, "Event structure size is not 16-bytes in size");
/* Ethdev Rx adapter capability bitmap flags */
#define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT 0x1
--
2.39.2
^ permalink raw reply [relevance 5%]
* [PATCH v3] eventdev: ensure 16-byte alignment for events
2023-10-05 12:06 3% ` Bruce Richardson
2023-10-06 9:37 5% ` [PATCH v2] " Bruce Richardson
@ 2023-10-06 9:45 8% ` Bruce Richardson
2023-10-06 10:29 8% ` [PATCH v4] " Bruce Richardson
3 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-10-06 9:45 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Jerin Jacob
The event structure in DPDK is 16-bytes in size, and events are
regularly passed as parameters directly rather than being passed as
pointers. To help compiler optimize correctly, we can explicitly request
16-byte alignment for events, which means that we should be able
to do aligned vector loads/stores (e.g. with SSE or Neon) when working
with those events.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
v3: Fix spelling mistake in RN entry
rebase on latest eventdev tree HEAD
v2: added release note entry for ABI change
added structure comment on 16-byte size and alignment
added static assert for structure size
---
doc/guides/rel_notes/release_23_11.rst | 4 ++++
lib/eventdev/rte_eventdev.h | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 0903046b0c..33fed3e433 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -209,6 +209,10 @@ ABI Changes
fields, to move ``rxq`` and ``txq`` fields, to change the size of
``reserved1`` and ``reserved2`` fields.
+* The ``rte_event`` structure, used by eventdev library and DPDK "event" class drivers,
+ is now 16-byte aligned, as well as being 16-bytes in size.
+ In previous releases, the structure only required 8-byte alignment.
+
Known Issues
------------
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 2ea98302b8..5b7c5b3399 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1284,6 +1284,8 @@ struct rte_event_vector {
/**
* The generic *rte_event* structure to hold the event attributes
* for dequeue and enqueue operation
+ *
+ * This structure must be kept at 16-bytes in size, and has 16-byte alignment.
*/
struct rte_event {
/** WORD0 */
@@ -1356,7 +1358,9 @@ struct rte_event {
struct rte_event_vector *vec;
/**< Event vector pointer. */
};
-};
+} __rte_aligned(16);
+
+_Static_assert(sizeof(struct rte_event) == 16, "Event structure size is not 16-bytes in size");
/* Ethdev Rx adapter capability bitmap flags */
#define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT 0x1
--
2.39.2
^ permalink raw reply [relevance 8%]
* [PATCH v4] eventdev: ensure 16-byte alignment for events
` (2 preceding siblings ...)
2023-10-06 9:45 8% ` [PATCH v3] " Bruce Richardson
@ 2023-10-06 10:29 8% ` Bruce Richardson
3 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-10-06 10:29 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Jerin Jacob
The event structure in DPDK is 16-bytes in size, and events are
regularly passed as parameters directly rather than being passed as
pointers. To help compiler optimize correctly, we can explicitly request
16-byte alignment for events, which means that we should be able
to do aligned vector loads/stores (e.g. with SSE or Neon) when working
with those events.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
v4: change _Static_assert to static_assert for fwd compatibility
moved size check on event structure to C file from header file
v3: Fix spelling mistake in RN entry
rebase on latest eventdev tree HEAD
v2: added release note entry for ABI change
added structure comment on 16-byte size and alignment
added static assert for structure size
---
doc/guides/rel_notes/release_23_11.rst | 4 ++++
lib/eventdev/rte_eventdev.c | 3 +++
lib/eventdev/rte_eventdev.h | 4 +++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 0903046b0c..33fed3e433 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -209,6 +209,10 @@ ABI Changes
fields, to move ``rxq`` and ``txq`` fields, to change the size of
``reserved1`` and ``reserved2`` fields.
+* The ``rte_event`` structure, used by eventdev library and DPDK "event" class drivers,
+ is now 16-byte aligned, as well as being 16-bytes in size.
+ In previous releases, the structure only required 8-byte alignment.
+
Known Issues
------------
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index 95373bbaad..adc9751cef 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -9,6 +9,7 @@
#include <errno.h>
#include <stdint.h>
#include <inttypes.h>
+#include <assert.h>
#include <rte_string_fns.h>
#include <rte_log.h>
@@ -28,6 +29,8 @@
#include "eventdev_pmd.h"
#include "eventdev_trace.h"
+static_assert(sizeof(struct rte_event) == 16, "Event structure size is not 16-bytes in size");
+
static struct rte_eventdev rte_event_devices[RTE_EVENT_MAX_DEVS];
struct rte_eventdev *rte_eventdevs = rte_event_devices;
diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
index 2ea98302b8..758ee83a3f 100644
--- a/lib/eventdev/rte_eventdev.h
+++ b/lib/eventdev/rte_eventdev.h
@@ -1284,6 +1284,8 @@ struct rte_event_vector {
/**
* The generic *rte_event* structure to hold the event attributes
* for dequeue and enqueue operation
+ *
+ * This structure must be kept at 16-bytes in size, and has 16-byte alignment.
*/
struct rte_event {
/** WORD0 */
@@ -1356,7 +1358,7 @@ struct rte_event {
struct rte_event_vector *vec;
/**< Event vector pointer. */
};
-};
+} __rte_aligned(16);
/* Ethdev Rx adapter capability bitmap flags */
#define RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT 0x1
--
2.39.2
^ permalink raw reply [relevance 8%]
* Re: [PATCH v2 2/2] eal: remove NUMFLAGS enumeration
2023-10-06 8:27 3% ` David Marchand
@ 2023-10-06 11:19 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-10-06 11:19 UTC (permalink / raw)
To: David Marchand, Sivaprasad Tummala
Cc: ruifeng.wang, zhoumin, drc, kda, bruce.richardson,
konstantin.v.ananyev, dev
On 10/6/2023 9:27 AM, David Marchand wrote:
> On Fri, Aug 11, 2023 at 8:08 AM Sivaprasad Tummala
> <sivaprasad.tummala@amd.com> wrote:
>>
>> This patch removes RTE_CPUFLAG_NUMFLAGS to allow new CPU
>> features without breaking ABI each time.
>>
>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
>
> I relooked at the API and I see one case (that I had missed in my
> previous reply) where an ABI issue may be present so I updated the
> commitlog in this regard.
>
> And then I merged this patch, with a few modifications.
> - removed the deprecation notice and updated RN,
> - removed leftover "Last item" comments in arch cpuflag headers,
>
> I hope everyone is happy with this.
>
>
Looks good to me, thanks David.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 4/4] pcapng: move timestamp calculation into pdump
2023-10-06 9:10 3% ` David Marchand
@ 2023-10-06 14:59 0% ` Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2023-10-06 14:59 UTC (permalink / raw)
To: David Marchand, Stephen Hemminger
Cc: dev, Reshma Pattan, Quentin Armitage, Thomas Monjalon,
Luca Boccassi, Xueming(Steven) Li, Christian Ehrhardt
On 06/10/2023 10:10, David Marchand wrote:
> On Wed, Oct 4, 2023 at 7:13 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>>
>> On Mon, 2 Oct 2023 10:15:25 +0200
>> David Marchand <david.marchand@redhat.com> wrote:
>>
>>>>
>>>
>>> Bugzilla ID: 1291 ?
>>>
>>> This patch (and patch 3) updates some pcapng API, is it worth a RN update?
>>>
>>>> Fixes: c882eb544842 ("pcapng: fix timestamp wrapping in output files")
>>>
>>> Is it worth backporting?
>>> I would say no, as some API update was needed to fix the issue.
>>> But on the other hand, this is an experimental API, so I prefer to ask.
>>>
>>>
>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>
>> Good question.
>> Is experimental API allowed to change in a stable release?
>
> I don't think this is cleary described in our ABI policy.
> An experimental API may be changed at any time, but nothing is said
> wrt backports.
>
> Breaking an API is always a pain, and for a LTS release it would
> probably be badly accepted by users.
>
yes, I agree. IIRC, this arose sometime in the past with a branch that
Luca was maintaining and I think the consensus among LTS maintainers was
not to change experimental API on stable branches.
> Cc: Kevin for his opinion.
>
> We may need a clarification on this topic in the doc.
>
>
Perhaps it's not a "rule" since experimental API comes with no
guarantee, but I can add something to the docs that it is a guideline
not to break experimental API on stable branch.
^ permalink raw reply [relevance 0%]
* Re: [PATCH RESEND v6 0/5] app/testpmd: support multiple process attach and detach port
@ 2023-10-09 10:34 0% ` lihuisong (C)
2023-10-30 12:17 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-10-09 10:34 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, fengchengwen,
liudongdong3, liuyonglong
Hi Ferruh and Thomas,
Can you take a look at this series? They've been over a year on
disscussion.
在 2023/8/2 11:15, Huisong Li 写道:
> This patchset fix some bugs and support attaching and detaching port
> in primary and secondary.
>
> ---
> -v6: adjust rte_eth_dev_is_used position based on alphabetical order
> in version.map
> -v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi break.
> -v4: fix a misspelling.
> -v3:
> #1 merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
> for other bus type.
> #2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
> the probelm in patch 2/5.
> -v2: resend due to CI unexplained failure.
>
> Huisong Li (5):
> drivers/bus: restore driver assignment at front of probing
> ethdev: fix skip valid port in probing callback
> app/testpmd: check the validity of the port
> app/testpmd: add attach and detach port for multiple process
> app/testpmd: stop forwarding in new or destroy event
>
> app/test-pmd/testpmd.c | 47 +++++++++++++++---------
> app/test-pmd/testpmd.h | 1 -
> drivers/bus/auxiliary/auxiliary_common.c | 9 ++++-
> drivers/bus/dpaa/dpaa_bus.c | 9 ++++-
> drivers/bus/fslmc/fslmc_bus.c | 8 +++-
> drivers/bus/ifpga/ifpga_bus.c | 12 ++++--
> drivers/bus/pci/pci_common.c | 9 ++++-
> drivers/bus/vdev/vdev.c | 10 ++++-
> drivers/bus/vmbus/vmbus_common.c | 9 ++++-
> drivers/net/bnxt/bnxt_ethdev.c | 3 +-
> drivers/net/bonding/bonding_testpmd.c | 1 -
> drivers/net/mlx5/mlx5.c | 2 +-
> lib/ethdev/ethdev_driver.c | 13 +++++--
> lib/ethdev/ethdev_driver.h | 12 ++++++
> lib/ethdev/ethdev_pci.h | 2 +-
> lib/ethdev/rte_class_eth.c | 2 +-
> lib/ethdev/rte_ethdev.c | 4 +-
> lib/ethdev/rte_ethdev.h | 4 +-
> lib/ethdev/version.map | 1 +
> 19 files changed, 114 insertions(+), 44 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7 0/3] add telemetry cmds for ring
@ 2023-10-10 2:25 0% ` Jie Hai
2023-10-25 1:22 0% ` Jie Hai
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-10-10 2:25 UTC (permalink / raw)
Cc: dev, liudongdong3
Hi, Thomas,
Kindly ping for review.
Thanks,
Jie Hai
On 2023/7/4 17:04, Jie Hai wrote:
> This patch set supports telemetry cmd to list rings and dump information
> of a ring by its name.
>
> v1->v2:
> 1. Add space after "switch".
> 2. Fix wrong strlen parameter.
>
> v2->v3:
> 1. Remove prefix "rte_" for static function.
> 2. Add Acked-by Konstantin Ananyev for PATCH 1.
> 3. Introduce functions to return strings instead copy strings.
> 4. Check pointer to memzone of ring.
> 5. Remove redundant variable.
> 6. Hold lock when access ring data.
>
> v3->v4:
> 1. Update changelog according to reviews of Honnappa Nagarahalli.
> 2. Add Reviewed-by Honnappa Nagarahalli.
> 3. Correct grammar in help information.
> 4. Correct spell warning on "te" reported by checkpatch.pl.
> 5. Use ring_walk() to query ring info instead of rte_ring_lookup().
> 6. Fix that type definition the flag field of rte_ring does not match the usage.
> 7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
> for mask and flags.
>
> v4->v5:
> 1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
> 2. Add ABI change explanation for commit message of patch 1/3.
>
> v5->v6:
> 1. Add Acked-by Morten Brørup.
> 2. Fix incorrect reference of commit.
>
> v6->v7:
> 1. Remove prod/consumer head/tail info.
>
> Jie Hai (3):
> ring: fix unmatched type definition and usage
> ring: add telemetry cmd to list rings
> ring: add telemetry cmd for ring info
>
> lib/ring/meson.build | 1 +
> lib/ring/rte_ring.c | 135 +++++++++++++++++++++++++++++++++++++++
> lib/ring/rte_ring_core.h | 2 +-
> 3 files changed, 137 insertions(+), 1 deletion(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code
2023-10-04 12:59 3% [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code Nithin Dabilpuram
@ 2023-10-10 13:10 0% ` Ferruh Yigit
2023-10-10 14:48 0% ` [EXT] " Akhil Goyal
2023-10-10 14:50 0% ` Anoob Joseph
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2023-10-10 13:10 UTC (permalink / raw)
To: Nithin Dabilpuram, Akhil Goyal, Anoob Joseph
Cc: jerinj, dev, Thomas Monjalon, Andrew Rybchenko
On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> Add IPsec event subtype range for PMD specific code in order
> to accommodate wide range of errors that PMD supports.
> These IPsec event subtypes are used when an error doesn't
> match the spec defined subtypes between RTE_ETH_EVENT_IPSEC_UNKNOWN
> and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
> to avoid ABI breakage.
>
> Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
> ---
> lib/ethdev/rte_ethdev.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 8542257721..f949dfc83d 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
> * eth device.
> */
> enum rte_eth_event_ipsec_subtype {
> + /** PMD specific error start */
> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> + /** PMD specific error end */
> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
> /** Unknown event type */
> RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
> /** Sequence number overflow */
>
I don't see any problem to extend event subtype with custom error range,
@Akhil, @Anoob what do you think?
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code
2023-10-10 13:10 0% ` Ferruh Yigit
@ 2023-10-10 14:48 0% ` Akhil Goyal
2023-10-12 9:32 0% ` Ferruh Yigit
2023-10-10 14:50 0% ` Anoob Joseph
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2023-10-10 14:48 UTC (permalink / raw)
To: Ferruh Yigit, Nithin Kumar Dabilpuram, Anoob Joseph
Cc: Jerin Jacob Kollanukkaran, dev, Thomas Monjalon, Andrew Rybchenko
> On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> > Add IPsec event subtype range for PMD specific code in order
> > to accommodate wide range of errors that PMD supports.
> > These IPsec event subtypes are used when an error doesn't
> > match the spec defined subtypes between
> RTE_ETH_EVENT_IPSEC_UNKNOWN
> > and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
> > to avoid ABI breakage.
> >
> > Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
> > ---
> > lib/ethdev/rte_ethdev.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > index 8542257721..f949dfc83d 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
> > * eth device.
> > */
> > enum rte_eth_event_ipsec_subtype {
> > + /** PMD specific error start */
> > + RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> > + /** PMD specific error end */
> > + RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
> > /** Unknown event type */
> > RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
> > /** Sequence number overflow */
> >
>
> I don't see any problem to extend event subtype with custom error range,
> @Akhil, @Anoob what do you think?
I believe it is ok to add the custom error range.
It is just that the user will need to check the negative values too, which I believe is ok.
Acked-by: Akhil Goyal <gakhil@marvell.com>
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code
2023-10-10 13:10 0% ` Ferruh Yigit
2023-10-10 14:48 0% ` [EXT] " Akhil Goyal
@ 2023-10-10 14:50 0% ` Anoob Joseph
1 sibling, 0 replies; 200+ results
From: Anoob Joseph @ 2023-10-10 14:50 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Jerin Jacob Kollanukkaran, dev, Thomas Monjalon,
Nithin Kumar Dabilpuram, Andrew Rybchenko, Akhil Goyal
Hi Ferruh,
>
> ----------------------------------------------------------------------
> On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> > Add IPsec event subtype range for PMD specific code in order to
> > accommodate wide range of errors that PMD supports.
> > These IPsec event subtypes are used when an error doesn't match the
> > spec defined subtypes between RTE_ETH_EVENT_IPSEC_UNKNOWN and
> > RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range to avoid ABI
> > breakage.
> >
> > Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
> > ---
> > lib/ethdev/rte_ethdev.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 8542257721..f949dfc83d 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
> > * eth device.
> > */
> > enum rte_eth_event_ipsec_subtype {
> > + /** PMD specific error start */
> > + RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> > + /** PMD specific error end */
> > + RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
> > /** Unknown event type */
> > RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
> > /** Sequence number overflow */
> >
>
> I don't see any problem to extend event subtype with custom error range,
> @Akhil, @Anoob what do you think?
[Anoob] Thanks for looping in. I do not see an issue with the approach either.
Acked-by: Anoob Joseph <anoobj@marvell.com>
Thanks,
Anoob
^ permalink raw reply [relevance 0%]
* [PATCH v5 00/40] support setting and querying RSS algorithms
@ 2023-10-11 9:27 2% ` Jie Hai
2023-10-11 9:27 4% ` [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Jie Hai
` (4 more replies)
1 sibling, 5 replies; 200+ results
From: Jie Hai @ 2023-10-11 9:27 UTC (permalink / raw)
To: dev; +Cc: lihuisong, fengchengwen, liudongdong3
This patchset is to support setting and querying RSS algorithms.
--
v5:
1. rewrite some comments.
2. check RSS algorithm for drivers supporting RSS.
3. change field "func" of rss_conf to "algorithm".
4. fix commit log for [PATCH v4 4/7].
5. add Acked-by Reshma Pattan.
6. add symmetric_toeplitz_sort for showing.
7. change "hf" to "hash function" for showing.
v4:
1. recomment some definitions related to RSS.
2. allocate static memory for rss_key instead of dynamic.
3. use array of strings to get the name of rss algorithm.
4. add display of rss algorithm with testpmd.
v3:
1. fix commit log for PATCH [1/5].
2. make RSS ABI changes description to start the actual text at the margin.
3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
4. fix some comment codes.
v2:
1. return error if "func" is invalid.
2. modify the comments of the "func" field.
3. modify commit log of patch [3/5].
4. use malloc instead of rte_malloc.
5. adjust display format of RSS info.
6. remove the string display of rss_hf.
Huisong Li (1):
net/hns3: support setting and querying RSS hash function
Jie Hai (39):
ethdev: overwrite some comment related to RSS
ethdev: support setting and querying RSS algorithm
net/atlantic: check RSS hash algorithms
net/axgbe: check RSS hash algorithms
net/bnx2x: check RSS hash algorithms
net/bnxt: check RSS hash algorithms
net/bonding: check RSS hash algorithms
net/cnxk: check RSS hash algorithms
net/cpfl: check RSS hash algorithms
net/cxgbe: check RSS hash algorithms
net/dpaa: check RSS hash algorithms
net/dpaa2: check RSS hash algorithms
net/ena: check RSS hash algorithms
net/enic: check RSS hash algorithms
net/fm10k: check RSS hash algorithms
net/hinic: check RSS hash algorithms
net/i40e: check RSS hash algorithms
net/iavf: check RSS hash algorithms
net/ice: check RSS hash algorithms
net/idpf: check RSS hash algorithms
net/igc: check RSS hash algorithms
net/ionic: check RSS hash algorithms
net/ixgbe: check RSS hash algorithms
net/mana: check RSS hash algorithms
net/mlx5: check RSS hash algorithms
net/mvpp2: check RSS hash algorithms
net/netvsc: check RSS hash algorithms
net/ngbe: : check RSS hash algorithms
net/nfp: check RSS hash algorithms
net/null: check RSS hash algorithms
net/qede: check RSS hash algorithms
net/sfc: check RSS hash algorithms
net/tap: check RSS hash algorithms
net/thunderx: check RSS hash algorithms
net/txgbe: check RSS hash algorithms
app/proc-info: fix never show RSS info
app/proc-info: adjust the display format of RSS info
app/proc-info: support querying RSS hash algorithm
app/testpmd: add RSS hash algorithms display
app/proc-info/main.c | 32 ++++++++++-----
app/test-pmd/cmdline.c | 29 ++++++++++---
app/test-pmd/config.c | 38 ++++++++---------
app/test-pmd/testpmd.h | 2 +-
doc/guides/rel_notes/release_23_11.rst | 2 +
drivers/net/atlantic/atl_ethdev.c | 2 +
drivers/net/axgbe/axgbe_ethdev.c | 9 +++++
drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++
drivers/net/bnxt/bnxt_ethdev.c | 6 +++
drivers/net/bonding/rte_eth_bond_pmd.c | 6 +++
drivers/net/cnxk/cnxk_ethdev.c | 5 +++
drivers/net/cnxk/cnxk_ethdev_ops.c | 3 ++
drivers/net/cpfl/cpfl_ethdev.c | 6 +++
drivers/net/cxgbe/cxgbe_ethdev.c | 9 ++++-
drivers/net/dpaa/dpaa_ethdev.c | 7 ++++
drivers/net/dpaa2/dpaa2_ethdev.c | 7 ++++
drivers/net/ena/ena_rss.c | 3 ++
drivers/net/enic/enic_ethdev.c | 1 +
drivers/net/enic/enic_main.c | 3 ++
drivers/net/fm10k/fm10k_ethdev.c | 9 ++++-
drivers/net/hinic/hinic_pmd_ethdev.c | 3 ++
drivers/net/hinic/hinic_pmd_rx.c | 3 ++
drivers/net/hns3/hns3_rss.c | 47 ++++++++++++---------
drivers/net/i40e/i40e_ethdev.c | 7 ++++
drivers/net/iavf/iavf_ethdev.c | 6 +++
drivers/net/ice/ice_dcf.c | 3 ++
drivers/net/ice/ice_dcf_ethdev.c | 3 ++
drivers/net/ice/ice_ethdev.c | 7 ++++
drivers/net/idpf/idpf_ethdev.c | 6 +++
drivers/net/igc/igc_ethdev.c | 4 ++
drivers/net/igc/igc_txrx.c | 5 +++
drivers/net/ionic/ionic_ethdev.c | 6 +++
drivers/net/ixgbe/ixgbe_ethdev.c | 12 +++++-
drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++
drivers/net/mana/mana.c | 11 ++++-
drivers/net/mlx5/mlx5_ethdev.c | 4 ++
drivers/net/mlx5/mlx5_rss.c | 3 +-
drivers/net/mvpp2/mrvl_ethdev.c | 3 ++
drivers/net/netvsc/hn_ethdev.c | 6 +++
drivers/net/nfp/nfp_common.c | 9 ++++-
drivers/net/ngbe/ngbe_ethdev.c | 6 ++-
drivers/net/ngbe/ngbe_rxtx.c | 3 ++
drivers/net/null/rte_eth_null.c | 8 ++++
drivers/net/qede/qede_ethdev.c | 9 ++++-
drivers/net/sfc/sfc_ethdev.c | 3 ++
drivers/net/sfc/sfc_rx.c | 3 ++
drivers/net/tap/rte_eth_tap.c | 8 ++++
drivers/net/thunderx/nicvf_ethdev.c | 10 ++++-
drivers/net/txgbe/txgbe_ethdev.c | 7 +++-
drivers/net/txgbe/txgbe_ethdev_vf.c | 7 +++-
drivers/net/txgbe/txgbe_rxtx.c | 3 ++
lib/ethdev/rte_ethdev.c | 17 ++++++++
lib/ethdev/rte_ethdev.h | 56 +++++++++++++++++++-------
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 25 +-----------
55 files changed, 395 insertions(+), 106 deletions(-)
--
2.30.0
^ permalink raw reply [relevance 2%]
* [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm
2023-10-11 9:27 2% ` [PATCH v5 00/40] support setting and querying RSS algorithms Jie Hai
@ 2023-10-11 9:27 4% ` Jie Hai
2023-10-11 17:39 4% ` Stephen Hemminger
2023-10-11 18:19 0% ` [PATCH v5 00/40] support setting and querying RSS algorithms Ferruh Yigit
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Jie Hai @ 2023-10-11 9:27 UTC (permalink / raw)
To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
The following API will be affected:
- rte_eth_dev_configure
- rte_eth_dev_rss_hash_update
- rte_eth_dev_rss_hash_conf_get
If the value of "algorithm" used for configuration is a gibberish
value, report the error and return. Do the same for
rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
To check whether the drivers report valid "algorithm", it is set
to default value before querying.
Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 2 ++
lib/ethdev/rte_ethdev.c | 17 ++++++++++++++++
lib/ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 28 ++------------------------
5 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index e13d57728071..92a445ab2ed3 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -197,6 +197,8 @@ ABI Changes
fields, to move ``rxq`` and ``txq`` fields, to change the size of
``reserved1`` and ``reserved2`` fields.
+* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm.
Known Issues
------------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 18a4b950b184..2eda1b8072e5 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1464,6 +1464,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ if (dev_conf->rx_adv_conf.rss_conf.algorithm >= RTE_ETH_HASH_FUNCTION_MAX) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n",
+ port_id, dev_conf->rx_adv_conf.rss_conf.algorithm);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/* Check if Rx RSS distribution is disabled but RSS hash is enabled. */
if (((dev_conf->rxmode.mq_mode & RTE_ETH_MQ_RX_RSS_FLAG) == 0) &&
(dev_conf->rxmode.offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)) {
@@ -4673,6 +4681,13 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -ENOTSUP;
}
+ if (rss_conf->algorithm >= RTE_ETH_HASH_FUNCTION_MAX) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n",
+ port_id, rss_conf->algorithm);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4700,6 +4715,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index b9e4e21189d2..42c4250bd509 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,32 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /**
+ * DEFAULT means driver decides which hash algorithm to pick.
+ */
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+ * Symmetric Toeplitz: src, dst will be replaced by
+ * xor(src, dst). For the case with src/dst only,
+ * src or dst address will xor with zero pair.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ /**
+ * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
+ * the hash function.
+ * If src_ip > dst_ip, swap src_ip and dst_ip.
+ * If src_port > dst_port, swap src_port and dst_port.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -465,6 +491,7 @@ struct rte_eth_rss_conf {
* Setting *rss_hf* to zero disables the RSS feature.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
};
/*
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index ba8bf27090fb..deedce08fb0a 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -13,7 +13,6 @@
#include <rte_branch_prediction.h>
#include <rte_string_fns.h>
#include <rte_mbuf_dyn.h>
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 5d9e3c68af7b..877a2e1d6ad3 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -40,6 +40,8 @@
#include <rte_macsec.h>
#include <rte_ib.h>
+#include "rte_ethdev.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -3223,32 +3225,6 @@ struct rte_flow_query_count {
uint64_t bytes; /**< Number of bytes through this rule [out]. */
};
-/**
- * Hash function types.
- */
-enum rte_eth_hash_function {
- /**
- * DEFAULT means driver decides which hash algorithm to pick.
- */
- RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
- RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
- RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
- /**
- * Symmetric Toeplitz: src, dst will be replaced by
- * xor(src, dst). For the case with src/dst only,
- * src or dst address will xor with zero pair.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
- /**
- * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
- * the hash function.
- * If src_ip > dst_ip, swap src_ip and dst_ip.
- * If src_port > dst_port, swap src_port and dst_port.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
- RTE_ETH_HASH_FUNCTION_MAX,
-};
-
/**
* RTE_FLOW_ACTION_TYPE_RSS
*
--
2.30.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm
2023-10-11 9:27 4% ` [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-10-11 17:39 4% ` Stephen Hemminger
2023-10-12 2:21 0% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-10-11 17:39 UTC (permalink / raw)
To: Jie Hai
Cc: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam,
lihuisong, fengchengwen, liudongdong3
On Wed, 11 Oct 2023 17:27:27 +0800
Jie Hai <haijie1@huawei.com> wrote:
> Currently, rte_eth_rss_conf supports configuring and querying
> RSS hash functions, rss key and it's length, but not RSS hash
> algorithm.
>
> The structure ``rte_eth_rss_conf`` is extended by adding a new
> field "algorithm". This represents the RSS algorithms to apply.
> The following API will be affected:
> - rte_eth_dev_configure
> - rte_eth_dev_rss_hash_update
> - rte_eth_dev_rss_hash_conf_get
>
> If the value of "algorithm" used for configuration is a gibberish
> value, report the error and return. Do the same for
> rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
>
> To check whether the drivers report valid "algorithm", it is set
> to default value before querying.
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
> doc/guides/rel_notes/release_23_11.rst | 2 ++
> lib/ethdev/rte_ethdev.c | 17 ++++++++++++++++
> lib/ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 28 ++------------------------
> 5 files changed, 48 insertions(+), 27 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
> index e13d57728071..92a445ab2ed3 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -197,6 +197,8 @@ ABI Changes
> fields, to move ``rxq`` and ``txq`` fields, to change the size of
> ``reserved1`` and ``reserved2`` fields.
>
> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
> + hash algorithm.
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 18a4b950b184..2eda1b8072e5 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1464,6 +1464,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> goto rollback;
> }
>
> + if (dev_conf->rx_adv_conf.rss_conf.algorithm >= RTE_ETH_HASH_FUNCTION_MAX) {
> + RTE_ETHDEV_LOG(ERR,
> + "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n",
> + port_id, dev_conf->rx_adv_conf.rss_conf.algorithm);
> + ret = -EINVAL;
> + goto rollback;
> + }
> +
Rather than having every driver check the algorithm, why not handle this like
other features in DPDK (which may mean API/ABI changes).
Add a field rss_algo_capa which is bit field of available RSS functions.
Then the check for algorithm can be done in generic code. There a couple
of reserved fields that could be used.
It would mean updating all the drivers once with the capa field but
would provide way for application to know what fields are possible.
It has proved to be a problem in later ABI changes if a maximum value
is exposed. I.e don't expose RTE_ETH_HASH_FUNCTION_MAX.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v5 00/40] support setting and querying RSS algorithms
2023-10-11 9:27 2% ` [PATCH v5 00/40] support setting and querying RSS algorithms Jie Hai
2023-10-11 9:27 4% ` [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-10-11 18:19 0% ` Ferruh Yigit
2023-10-12 16:49 0% ` Stephen Hemminger
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-10-11 18:19 UTC (permalink / raw)
To: Jie Hai, dev; +Cc: lihuisong, fengchengwen, liudongdong3
On 10/11/2023 10:27 AM, Jie Hai wrote:
> This patchset is to support setting and querying RSS algorithms.
>
> --
> v5:
> 1. rewrite some comments.
> 2. check RSS algorithm for drivers supporting RSS.
> 3. change field "func" of rss_conf to "algorithm".
> 4. fix commit log for [PATCH v4 4/7].
> 5. add Acked-by Reshma Pattan.
> 6. add symmetric_toeplitz_sort for showing.
> 7. change "hf" to "hash function" for showing.
>
> v4:
> 1. recomment some definitions related to RSS.
> 2. allocate static memory for rss_key instead of dynamic.
> 3. use array of strings to get the name of rss algorithm.
> 4. add display of rss algorithm with testpmd.
>
> v3:
> 1. fix commit log for PATCH [1/5].
> 2. make RSS ABI changes description to start the actual text at the margin.
> 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
> 4. fix some comment codes.
>
> v2:
> 1. return error if "func" is invalid.
> 2. modify the comments of the "func" field.
> 3. modify commit log of patch [3/5].
> 4. use malloc instead of rte_malloc.
> 5. adjust display format of RSS info.
> 6. remove the string display of rss_hf.
>
> Huisong Li (1):
> net/hns3: support setting and querying RSS hash function
>
> Jie Hai (39):
> ethdev: overwrite some comment related to RSS
> ethdev: support setting and querying RSS algorithm
> net/atlantic: check RSS hash algorithms
> net/axgbe: check RSS hash algorithms
> net/bnx2x: check RSS hash algorithms
> net/bnxt: check RSS hash algorithms
> net/bonding: check RSS hash algorithms
> net/cnxk: check RSS hash algorithms
> net/cpfl: check RSS hash algorithms
> net/cxgbe: check RSS hash algorithms
> net/dpaa: check RSS hash algorithms
> net/dpaa2: check RSS hash algorithms
> net/ena: check RSS hash algorithms
> net/enic: check RSS hash algorithms
> net/fm10k: check RSS hash algorithms
> net/hinic: check RSS hash algorithms
> net/i40e: check RSS hash algorithms
> net/iavf: check RSS hash algorithms
> net/ice: check RSS hash algorithms
> net/idpf: check RSS hash algorithms
> net/igc: check RSS hash algorithms
> net/ionic: check RSS hash algorithms
> net/ixgbe: check RSS hash algorithms
> net/mana: check RSS hash algorithms
> net/mlx5: check RSS hash algorithms
> net/mvpp2: check RSS hash algorithms
> net/netvsc: check RSS hash algorithms
> net/ngbe: : check RSS hash algorithms
> net/nfp: check RSS hash algorithms
> net/null: check RSS hash algorithms
> net/qede: check RSS hash algorithms
> net/sfc: check RSS hash algorithms
> net/tap: check RSS hash algorithms
> net/thunderx: check RSS hash algorithms
> net/txgbe: check RSS hash algorithms
> app/proc-info: fix never show RSS info
> app/proc-info: adjust the display format of RSS info
> app/proc-info: support querying RSS hash algorithm
> app/testpmd: add RSS hash algorithms display
>
> app/proc-info/main.c | 32 ++++++++++-----
> app/test-pmd/cmdline.c | 29 ++++++++++---
> app/test-pmd/config.c | 38 ++++++++---------
> app/test-pmd/testpmd.h | 2 +-
> doc/guides/rel_notes/release_23_11.rst | 2 +
> drivers/net/atlantic/atl_ethdev.c | 2 +
> drivers/net/axgbe/axgbe_ethdev.c | 9 +++++
> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++
> drivers/net/bnxt/bnxt_ethdev.c | 6 +++
> drivers/net/bonding/rte_eth_bond_pmd.c | 6 +++
> drivers/net/cnxk/cnxk_ethdev.c | 5 +++
> drivers/net/cnxk/cnxk_ethdev_ops.c | 3 ++
> drivers/net/cpfl/cpfl_ethdev.c | 6 +++
> drivers/net/cxgbe/cxgbe_ethdev.c | 9 ++++-
> drivers/net/dpaa/dpaa_ethdev.c | 7 ++++
> drivers/net/dpaa2/dpaa2_ethdev.c | 7 ++++
> drivers/net/ena/ena_rss.c | 3 ++
> drivers/net/enic/enic_ethdev.c | 1 +
> drivers/net/enic/enic_main.c | 3 ++
> drivers/net/fm10k/fm10k_ethdev.c | 9 ++++-
> drivers/net/hinic/hinic_pmd_ethdev.c | 3 ++
> drivers/net/hinic/hinic_pmd_rx.c | 3 ++
> drivers/net/hns3/hns3_rss.c | 47 ++++++++++++---------
> drivers/net/i40e/i40e_ethdev.c | 7 ++++
> drivers/net/iavf/iavf_ethdev.c | 6 +++
> drivers/net/ice/ice_dcf.c | 3 ++
> drivers/net/ice/ice_dcf_ethdev.c | 3 ++
> drivers/net/ice/ice_ethdev.c | 7 ++++
> drivers/net/idpf/idpf_ethdev.c | 6 +++
> drivers/net/igc/igc_ethdev.c | 4 ++
> drivers/net/igc/igc_txrx.c | 5 +++
> drivers/net/ionic/ionic_ethdev.c | 6 +++
> drivers/net/ixgbe/ixgbe_ethdev.c | 12 +++++-
> drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++
> drivers/net/mana/mana.c | 11 ++++-
> drivers/net/mlx5/mlx5_ethdev.c | 4 ++
> drivers/net/mlx5/mlx5_rss.c | 3 +-
> drivers/net/mvpp2/mrvl_ethdev.c | 3 ++
> drivers/net/netvsc/hn_ethdev.c | 6 +++
> drivers/net/nfp/nfp_common.c | 9 ++++-
> drivers/net/ngbe/ngbe_ethdev.c | 6 ++-
> drivers/net/ngbe/ngbe_rxtx.c | 3 ++
> drivers/net/null/rte_eth_null.c | 8 ++++
> drivers/net/qede/qede_ethdev.c | 9 ++++-
> drivers/net/sfc/sfc_ethdev.c | 3 ++
> drivers/net/sfc/sfc_rx.c | 3 ++
> drivers/net/tap/rte_eth_tap.c | 8 ++++
> drivers/net/thunderx/nicvf_ethdev.c | 10 ++++-
> drivers/net/txgbe/txgbe_ethdev.c | 7 +++-
> drivers/net/txgbe/txgbe_ethdev_vf.c | 7 +++-
> drivers/net/txgbe/txgbe_rxtx.c | 3 ++
> lib/ethdev/rte_ethdev.c | 17 ++++++++
> lib/ethdev/rte_ethdev.h | 56 +++++++++++++++++++-------
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 25 +-----------
> 55 files changed, 395 insertions(+), 106 deletions(-)
>
Can update following drivers too:
- igb (drivers/net/e1000/igb_ethdev.c)
- octeontx, configure(), as it checks RSS mode there
- virtio
- vmxnet3, as it configures RSS
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 1/3] lib: introduce dispatcher library
@ 2023-10-11 20:51 3% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2023-10-11 20:51 UTC (permalink / raw)
To: David Marchand
Cc: Mattias Rönnblom, dev, Jerin Jacob, techboard,
harry.van.haaren, Peter Nilsson, Heng Wang, Naga Harish K S V,
Pavan Nikhilesh, Gujjar Abhinandan S, Erik Gabriel Carrillo,
Shijith Thotton, Hemant Agrawal, Sachin Saxena, Liang Ma,
Peter Mccarthy, Zhirun Yan
On 2023-10-11 16:57, David Marchand wrote:
> On Mon, Oct 9, 2023 at 6:50 PM Mattias Rönnblom <hofors@lysator.liu.se> wrote:
>
> [snip]
>
>>>>>> +static int
>>>>>> +evd_set_service_runstate(struct rte_dispatcher *dispatcher, int state)
>>>>>> +{
>>>>>> + int rc;
>>>>>> +
>>>>>> + rc = rte_service_component_runstate_set(dispatcher->service_id,
>>>>>> + state);
>>>>>> +
>>>>>> + if (rc != 0) {
>>>>>> + RTE_EDEV_LOG_ERR("Unexpected error %d occurred while setting "
>>>>>> + "service component run state to %d\n", rc,
>>>>>> + state);
>>>>>> + RTE_ASSERT(0);
>>>>>
>>>>> Why not propagating the error to callers?
>>>>>
>>>>>
>>>>
>>>> The root cause would be a programming error, hence an assertion is more
>>>> appropriate way to deal with the situation.
>>>
>>> Without building RTE_ENABLE_ASSERT (disabled by default), the code
>>> later in this function will still be executed.
>>>
>>
>> If RTE_ASSERT() is not the way to assure a consistent internal library
>> state, what is? RTE_VERIFY()?
>
> The usual way in DPDK is to use RTE_VERIFY or rte_panic with the error message.
> There is also libc assert().
>
> RTE_ASSERT is more of a debug macro since it is under a build option.
>
>
> But by making the library "panic" on some assertion, I have followup comments:
> - what is the point of returning an int for rte_dispatcher_start() /
> rte_dispatcher_stop()?
> - rte_dispatcher_start() and rte_dispatcher_stop() (doxygen)
> documentation needs updating, as they can't return anything but 0.
>
>
Those return vales are purely there for reasons of symmetry, or maybe
you can call it API consistent, with Eventdev APIs (e.g., the event
ethernet RX adapter). I guess that's less of an issue now, when it's a
separate library, but still relevant, since the programmer will be
familiar with those APIs.
You could also argue that in the future, there may be errors which needs
to be signaled to the caller. But that's a weak argument, since we don't
know exactly what those would be (and thus they can't be documented), so
it's still an API/ABI change, even though the function signature doesn't
change.
Now I'm leaning toward removing the return value. Please advise. Over.
^ permalink raw reply [relevance 3%]
* Re: [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm
2023-10-11 17:39 4% ` Stephen Hemminger
@ 2023-10-12 2:21 0% ` fengchengwen
2023-10-12 15:23 0% ` Stephen Hemminger
2023-10-24 12:54 0% ` Jie Hai
0 siblings, 2 replies; 200+ results
From: fengchengwen @ 2023-10-12 2:21 UTC (permalink / raw)
To: Stephen Hemminger, Jie Hai
Cc: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam,
lihuisong, liudongdong3
On 2023/10/12 1:39, Stephen Hemminger wrote:
> On Wed, 11 Oct 2023 17:27:27 +0800
> Jie Hai <haijie1@huawei.com> wrote:
>
>> Currently, rte_eth_rss_conf supports configuring and querying
>> RSS hash functions, rss key and it's length, but not RSS hash
>> algorithm.
>>
>> The structure ``rte_eth_rss_conf`` is extended by adding a new
>> field "algorithm". This represents the RSS algorithms to apply.
>> The following API will be affected:
>> - rte_eth_dev_configure
>> - rte_eth_dev_rss_hash_update
>> - rte_eth_dev_rss_hash_conf_get
>>
>> If the value of "algorithm" used for configuration is a gibberish
>> value, report the error and return. Do the same for
>> rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
>>
>> To check whether the drivers report valid "algorithm", it is set
>> to default value before querying.
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> ---
>> doc/guides/rel_notes/release_23_11.rst | 2 ++
>> lib/ethdev/rte_ethdev.c | 17 ++++++++++++++++
>> lib/ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++
>> lib/ethdev/rte_flow.c | 1 -
>> lib/ethdev/rte_flow.h | 28 ++------------------------
>> 5 files changed, 48 insertions(+), 27 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
>> index e13d57728071..92a445ab2ed3 100644
>> --- a/doc/guides/rel_notes/release_23_11.rst
>> +++ b/doc/guides/rel_notes/release_23_11.rst
>> @@ -197,6 +197,8 @@ ABI Changes
>> fields, to move ``rxq`` and ``txq`` fields, to change the size of
>> ``reserved1`` and ``reserved2`` fields.
>>
>> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
>> + hash algorithm.
>>
>> Known Issues
>> ------------
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 18a4b950b184..2eda1b8072e5 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -1464,6 +1464,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>> goto rollback;
>> }
>>
>> + if (dev_conf->rx_adv_conf.rss_conf.algorithm >= RTE_ETH_HASH_FUNCTION_MAX) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n",
>> + port_id, dev_conf->rx_adv_conf.rss_conf.algorithm);
>> + ret = -EINVAL;
>> + goto rollback;
>> + }
>> +
>
> Rather than having every driver check the algorithm, why not handle this like
> other features in DPDK (which may mean API/ABI changes).
>
> Add a field rss_algo_capa which is bit field of available RSS functions.
> Then the check for algorithm can be done in generic code. There a couple
> of reserved fields that could be used.
+1 for add a field
But there are two ways to config rss: ethdev-ops, ethdev-rteflow-ops, should distinguish them ? or just define for ethdev-ops ?
>
> It would mean updating all the drivers once with the capa field but
> would provide way for application to know what fields are possible.
>
> It has proved to be a problem in later ABI changes if a maximum value
> is exposed. I.e don't expose RTE_ETH_HASH_FUNCTION_MAX.
+1
>
> .
>
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code
2023-10-10 14:48 0% ` [EXT] " Akhil Goyal
@ 2023-10-12 9:32 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-10-12 9:32 UTC (permalink / raw)
To: Akhil Goyal, Nithin Kumar Dabilpuram, Anoob Joseph
Cc: Jerin Jacob Kollanukkaran, dev, Thomas Monjalon, Andrew Rybchenko
On 10/10/2023 3:48 PM, Akhil Goyal wrote:
>> On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
>>> Add IPsec event subtype range for PMD specific code in order
>>> to accommodate wide range of errors that PMD supports.
>>> These IPsec event subtypes are used when an error doesn't
>>> match the spec defined subtypes between
>> RTE_ETH_EVENT_IPSEC_UNKNOWN
>>> and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
>>> to avoid ABI breakage.
>>>
>>> Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
>>> ---
>>> lib/ethdev/rte_ethdev.h | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
>>> index 8542257721..f949dfc83d 100644
>>> --- a/lib/ethdev/rte_ethdev.h
>>> +++ b/lib/ethdev/rte_ethdev.h
>>> @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
>>> * eth device.
>>> */
>>> enum rte_eth_event_ipsec_subtype {
>>> + /** PMD specific error start */
>>> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
>>> + /** PMD specific error end */
>>> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
>>> /** Unknown event type */
>>> RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
>>> /** Sequence number overflow */
>>>
>>
>> I don't see any problem to extend event subtype with custom error range,
>> @Akhil, @Anoob what do you think?
>
> I believe it is ok to add the custom error range.
> It is just that the user will need to check the negative values too, which I believe is ok.
>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
>
>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
>
Series applied to dpdk-next-net/main, thanks.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm
2023-10-12 2:21 0% ` fengchengwen
@ 2023-10-12 15:23 0% ` Stephen Hemminger
2023-10-24 12:54 0% ` Jie Hai
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-12 15:23 UTC (permalink / raw)
To: fengchengwen
Cc: Jie Hai, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ori Kam, lihuisong, liudongdong3
On Thu, 12 Oct 2023 10:21:51 +0800
fengchengwen <fengchengwen@huawei.com> wrote:
> > Rather than having every driver check the algorithm, why not handle this like
> > other features in DPDK (which may mean API/ABI changes).
> >
> > Add a field rss_algo_capa which is bit field of available RSS functions.
> > Then the check for algorithm can be done in generic code. There a couple
> > of reserved fields that could be used.
>
> +1 for add a field
>
> But there are two ways to config rss: ethdev-ops, ethdev-rteflow-ops, should distinguish them ? or just define for ethdev-ops ?
One field is likely to be enough.
I would expect that if driver accepts RSS for rte flow, it would also take same RSS setting for non flow case.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 00/40] support setting and querying RSS algorithms
2023-10-11 9:27 2% ` [PATCH v5 00/40] support setting and querying RSS algorithms Jie Hai
2023-10-11 9:27 4% ` [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Jie Hai
2023-10-11 18:19 0% ` [PATCH v5 00/40] support setting and querying RSS algorithms Ferruh Yigit
@ 2023-10-12 16:49 0% ` Stephen Hemminger
2023-10-27 9:28 3% ` [PATCH 0/9] " Jie Hai
4 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-12 16:49 UTC (permalink / raw)
To: Jie Hai; +Cc: dev, lihuisong, fengchengwen, liudongdong3
On Wed, 11 Oct 2023 17:27:25 +0800
Jie Hai <haijie1@huawei.com> wrote:
> This patchset is to support setting and querying RSS algorithms.
>
> --
> v5:
> 1. rewrite some comments.
> 2. check RSS algorithm for drivers supporting RSS.
> 3. change field "func" of rss_conf to "algorithm".
> 4. fix commit log for [PATCH v4 4/7].
> 5. add Acked-by Reshma Pattan.
> 6. add symmetric_toeplitz_sort for showing.
> 7. change "hf" to "hash function" for showing.
>
> v4:
> 1. recomment some definitions related to RSS.
> 2. allocate static memory for rss_key instead of dynamic.
> 3. use array of strings to get the name of rss algorithm.
> 4. add display of rss algorithm with testpmd.
>
> v3:
> 1. fix commit log for PATCH [1/5].
> 2. make RSS ABI changes description to start the actual text at the margin.
> 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
> 4. fix some comment codes.
>
> v2:
> 1. return error if "func" is invalid.
> 2. modify the comments of the "func" field.
> 3. modify commit log of patch [3/5].
> 4. use malloc instead of rte_malloc.
> 5. adjust display format of RSS info.
> 6. remove the string display of rss_hf.
>
> Huisong Li (1):
> net/hns3: support setting and querying RSS hash function
>
> Jie Hai (39):
> ethdev: overwrite some comment related to RSS
> ethdev: support setting and querying RSS algorithm
> net/atlantic: check RSS hash algorithms
> net/axgbe: check RSS hash algorithms
> net/bnx2x: check RSS hash algorithms
> net/bnxt: check RSS hash algorithms
> net/bonding: check RSS hash algorithms
> net/cnxk: check RSS hash algorithms
> net/cpfl: check RSS hash algorithms
> net/cxgbe: check RSS hash algorithms
> net/dpaa: check RSS hash algorithms
> net/dpaa2: check RSS hash algorithms
> net/ena: check RSS hash algorithms
> net/enic: check RSS hash algorithms
> net/fm10k: check RSS hash algorithms
> net/hinic: check RSS hash algorithms
> net/i40e: check RSS hash algorithms
> net/iavf: check RSS hash algorithms
> net/ice: check RSS hash algorithms
> net/idpf: check RSS hash algorithms
> net/igc: check RSS hash algorithms
> net/ionic: check RSS hash algorithms
> net/ixgbe: check RSS hash algorithms
> net/mana: check RSS hash algorithms
> net/mlx5: check RSS hash algorithms
> net/mvpp2: check RSS hash algorithms
> net/netvsc: check RSS hash algorithms
> net/ngbe: : check RSS hash algorithms
> net/nfp: check RSS hash algorithms
> net/null: check RSS hash algorithms
> net/qede: check RSS hash algorithms
> net/sfc: check RSS hash algorithms
> net/tap: check RSS hash algorithms
> net/thunderx: check RSS hash algorithms
> net/txgbe: check RSS hash algorithms
> app/proc-info: fix never show RSS info
> app/proc-info: adjust the display format of RSS info
> app/proc-info: support querying RSS hash algorithm
> app/testpmd: add RSS hash algorithms display
>
> app/proc-info/main.c | 32 ++++++++++-----
> app/test-pmd/cmdline.c | 29 ++++++++++---
> app/test-pmd/config.c | 38 ++++++++---------
> app/test-pmd/testpmd.h | 2 +-
> doc/guides/rel_notes/release_23_11.rst | 2 +
> drivers/net/atlantic/atl_ethdev.c | 2 +
> drivers/net/axgbe/axgbe_ethdev.c | 9 +++++
> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++
> drivers/net/bnxt/bnxt_ethdev.c | 6 +++
> drivers/net/bonding/rte_eth_bond_pmd.c | 6 +++
> drivers/net/cnxk/cnxk_ethdev.c | 5 +++
> drivers/net/cnxk/cnxk_ethdev_ops.c | 3 ++
> drivers/net/cpfl/cpfl_ethdev.c | 6 +++
> drivers/net/cxgbe/cxgbe_ethdev.c | 9 ++++-
> drivers/net/dpaa/dpaa_ethdev.c | 7 ++++
> drivers/net/dpaa2/dpaa2_ethdev.c | 7 ++++
> drivers/net/ena/ena_rss.c | 3 ++
> drivers/net/enic/enic_ethdev.c | 1 +
> drivers/net/enic/enic_main.c | 3 ++
> drivers/net/fm10k/fm10k_ethdev.c | 9 ++++-
> drivers/net/hinic/hinic_pmd_ethdev.c | 3 ++
> drivers/net/hinic/hinic_pmd_rx.c | 3 ++
> drivers/net/hns3/hns3_rss.c | 47 ++++++++++++---------
> drivers/net/i40e/i40e_ethdev.c | 7 ++++
> drivers/net/iavf/iavf_ethdev.c | 6 +++
> drivers/net/ice/ice_dcf.c | 3 ++
> drivers/net/ice/ice_dcf_ethdev.c | 3 ++
> drivers/net/ice/ice_ethdev.c | 7 ++++
> drivers/net/idpf/idpf_ethdev.c | 6 +++
> drivers/net/igc/igc_ethdev.c | 4 ++
> drivers/net/igc/igc_txrx.c | 5 +++
> drivers/net/ionic/ionic_ethdev.c | 6 +++
> drivers/net/ixgbe/ixgbe_ethdev.c | 12 +++++-
> drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++
> drivers/net/mana/mana.c | 11 ++++-
> drivers/net/mlx5/mlx5_ethdev.c | 4 ++
> drivers/net/mlx5/mlx5_rss.c | 3 +-
> drivers/net/mvpp2/mrvl_ethdev.c | 3 ++
> drivers/net/netvsc/hn_ethdev.c | 6 +++
> drivers/net/nfp/nfp_common.c | 9 ++++-
> drivers/net/ngbe/ngbe_ethdev.c | 6 ++-
> drivers/net/ngbe/ngbe_rxtx.c | 3 ++
> drivers/net/null/rte_eth_null.c | 8 ++++
> drivers/net/qede/qede_ethdev.c | 9 ++++-
> drivers/net/sfc/sfc_ethdev.c | 3 ++
> drivers/net/sfc/sfc_rx.c | 3 ++
> drivers/net/tap/rte_eth_tap.c | 8 ++++
> drivers/net/thunderx/nicvf_ethdev.c | 10 ++++-
> drivers/net/txgbe/txgbe_ethdev.c | 7 +++-
> drivers/net/txgbe/txgbe_ethdev_vf.c | 7 +++-
> drivers/net/txgbe/txgbe_rxtx.c | 3 ++
> lib/ethdev/rte_ethdev.c | 17 ++++++++
> lib/ethdev/rte_ethdev.h | 56 +++++++++++++++++++-------
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 25 +-----------
> 55 files changed, 395 insertions(+), 106 deletions(-)
>
In future, it would be good to report the hash algorithm in the PCAPNG
output from dumpcap. The current code always reports it as Toeplitz.
One issue is that the PCAPNG standard:
https://www.ietf.org/staging/draft-tuexen-opsawg-pcapng-02.html#name-enhanced-packet-block
Only has values for a few types:
epb_hash:
The epb_hash option contains a hash of the packet. The first octet
specifies the hashing algorithm, while the following octets contain the
actual hash, whose size depends on the hashing algorithm, and hence
from the value in the first octet. The hashing algorithm can be: 2s
complement (algorithm octet = 0, size = XXX), XOR (algorithm octet = 1,
size=XXX), CRC32 (algorithm octet = 2, size = 4), MD-5 (algorithm octet
= 3, size = 16), SHA-1 (algorithm octet = 4, size = 20), Toeplitz
(algorithm octet = 5, size = 4). The hash covers only the packet, not
the header added by the capture driver: this gives the possibility to
calculate it inside the network card. The hash allows easier
comparison/merging of different capture files, and reliable data
transfer between the data acquisition system and the capture library.
I added the Toeplitz one when pcapng was being managed via github.
Now that it is more in IETF/RFC standard process adding new values probably
would take more effort.
^ permalink raw reply [relevance 0%]
* [PATCH v2 3/3] doc: add a relax rx mode requirement option
@ 2023-10-13 4:27 9% ` Trevor Tao
0 siblings, 0 replies; 200+ results
From: Trevor Tao @ 2023-10-13 4:27 UTC (permalink / raw)
To: dev; +Cc: Trevor Tao
Add an option to enable the RX mode requirement relax
in release notes and l3fwd sample guide.
Signed-off-by: Trevor Tao <taozj888@163.com>
---
doc/guides/rel_notes/release_23_11.rst | 251 +++++++++++++++++++++---
doc/guides/sample_app_ug/l3_forward.rst | 4 +-
2 files changed, 230 insertions(+), 25 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index f09ecd50fe..3f1d5039c3 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -20,26 +20,14 @@ DPDK Release 23.11
ninja -C build doc
xdg-open build/doc/guides/html/rel_notes/release_23_11.html
-* Build Requirements: From DPDK 23.11 onwards,
- building DPDK will require a C compiler which supports the C11 standard,
- including support for C11 standard atomics.
-
- More specifically, the requirements will be:
- * Support for flag "-std=c11" (or similar)
- * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
+New Features
+------------
- Please note:
+ * **Added support for models with multiple I/O in mldev library.**
- * C11, including standard atomics, is supported from GCC version 5 onwards,
- and is the default language version in that release
- (Ref: https://gcc.gnu.org/gcc-5/changes.html)
- * C11 is the default compilation mode in Clang from version 3.6,
- which also added support for standard atomics
- (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
+ Added support in mldev library for models with multiple inputs and outputs.
-New Features
-------------
.. This section should contain new features added in this release.
Sample format:
@@ -72,18 +60,177 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
-* build: Enabling deprecated libraries is now done using the new
- ``enable_deprecated_libraries`` build option.
+* **Build requirements increased for C11.**
+
+ From DPDK 23.11 onwards,
+ building DPDK will require a C compiler which supports the C11 standard,
+ including support for C11 standard atomics.
+
+ More specifically, the requirements will be:
-* build: Optional libraries can now be selected with the new ``enable_libs``
- build option similarly to the existing ``enable_drivers`` build option.
+ * Support for flag "-std=c11" (or similar)
+ * __STDC_NO_ATOMICS__ is *not defined* when using c11 flag
-* eal: Introduced a new API for atomic operations. This new API serves as a
- wrapper for transitioning to standard atomic operations as described in the
- C11 standard. This API implementation points at the compiler intrinsics by
- default. The implementation using C11 standard atomic operations is enabled
+ Please note:
+
+ * C11, including standard atomics, is supported from GCC version 5 onwards,
+ and is the default language version in that release
+ (Ref: https://gcc.gnu.org/gcc-5/changes.html)
+ * C11 is the default compilation mode in Clang from version 3.6,
+ which also added support for standard atomics
+ (Ref: https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html)
+
+* **Added new build options.**
+
+ * Enabling deprecated libraries is now done using
+ the new ``enable_deprecated_libraries`` build option.
+ * Optional libraries can now be selected with the new ``enable_libs``
+ build option similarly to the existing ``enable_drivers`` build option.
+
+* **Introduced a new API for atomic operations.**
+
+ This new API serves as a wrapper for transitioning
+ to standard atomic operations as described in the C11 standard.
+ This API implementation points at the compiler intrinsics by default.
+ The implementation using C11 standard atomic operations is enabled
via the ``enable_stdatomic`` build option.
+* **Added support for power intrinsics with AMD processors.**
+
+* **Added support for allow/block list in vmbus bus driver.***
+
+ The ``vmbus`` bus driver now supports -a and -b EAL options for selecting
+ devices.
+
+* **Added mbuf recycling support.**
+
+ Added ``rte_eth_recycle_rx_queue_info_get`` and ``rte_eth_recycle_mbufs``
+ functions which allow the user to copy used mbufs from the Tx mbuf ring
+ into the Rx mbuf ring. This feature supports the case that the Rx Ethernet
+ device is different from the Tx Ethernet device with respective driver
+ callback functions in ``rte_eth_recycle_mbufs``.
+
+* **Added amd-pstate driver support to the power management library.**
+
+ Added support for amd-pstate driver which works on AMD EPYC processors.
+
+* **Added a flow action type for P4-defined actions.**
+
+ For P4-programmable devices, hardware pipeline can be configured through
+ a new "PROG" action type and its associated custom arguments.
+ Such P4 pipeline, not using the standard blocks of the flow API,
+ can be managed with ``RTE_FLOW_ITEM_TYPE_FLEX`` and ``RTE_FLOW_ACTION_TYPE_PROG``.
+
+* **Added flow group set miss actions.**
+
+ Introduced ``rte_flow_group_set_miss_actions()`` API to explicitly set
+ a group's miss actions, which are the actions to be performed on packets
+ that didn't match any of the flow rules in the group.
+
+* **Updated Marvell cnxk net driver.**
+
+ * Added support for ``RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT`` flow item.
+ * Added support for ``RTE_FLOW_ACTION_TYPE_AGE`` flow action.
+
+* **Updated Solarflare net driver.**
+
+ * Added support for transfer flow action ``INDIRECT`` with subtype ``VXLAN_ENCAP``.
+ * Supported packet replay (multi-count / multi-delivery) in transfer flows.
+
+* **Updated Netronome/Corigine nfp driver.**
+
+ * Added inline IPsec offload based on the security framework.
+
+* **Updated Wangxun ngbe driver.**
+
+ * Added 100M and auto-neg support in YT PHY fiber mode.
+
+* **Added support for TLS and DTLS record processing.**
+
+ Added TLS and DTLS record transform for security session
+ and added enhancements to ``rte_crypto_op`` fields
+ to handle all datapath requirements of TLS and DTLS.
+ The support was added for TLS 1.2, TLS 1.3 and DTLS 1.2.
+
+* **Added out of place processing support for inline ingress security session.**
+
+ Similar to out of place processing support for lookaside security session,
+ added the same support for inline ingress security session.
+
+* **Added security Rx inject API.**
+
+ Added Rx inject API to allow applications to submit packets
+ for protocol offload and have them injected back to ethdev Rx
+ so that further ethdev Rx actions (IP reassembly, packet parsing and flow lookups)
+ can happen based on inner packet.
+
+ The API when implemented by an ethdev, application would be able to process
+ packets that are received without/failed inline offload processing
+ (such as fragmented ESP packets with inline IPsec offload).
+ The API when implemented by a cryptodev, can be used for injecting packets
+ to ethdev Rx after IPsec processing and take advantage of ethdev Rx actions
+ for the inner packet which cannot be accelerated in inline protocol offload mode.
+
+* **Updated cryptodev scheduler driver.**
+
+ * Added support for DOCSIS security protocol
+ through the ``rte_security`` API callbacks.
+
+* **Updated ipsec_mb crypto driver.**
+
+ * Added support for digest encrypted to AESNI_MB asynchronous crypto driver.
+
+* **Updated Intel QuickAssist Technology driver.**
+
+ * Enabled support for QAT 2.0c (4944) devices in QAT crypto driver.
+
+* **Updated Marvell cnxk crypto driver.**
+
+ * Added SM2 algorithm support in asymmetric crypto operations.
+
+* **Updated Intel vRAN Boost baseband driver.**
+
+ * Added support for the new Intel vRAN Boost v2 device variant (GNR-D)
+ within the unified driver.
+
+* **Added new eventdev Ethernet Rx adapter create API.**
+
+ Added new function ``rte_event_eth_rx_adapter_create_ext_with_params()``
+ for creating Rx adapter instance for the applications desire to
+ control both the event port allocation and event buffer size.
+
+* **Added event DMA adapter library.**
+
+ * Added the Event DMA Adapter Library. This library extends the event-based
+ model by introducing APIs that allow applications to enqueue/dequeue DMA
+ operations to/from dmadev as events scheduled by an event device.
+
+* **Added eventdev support to link queues to port with link profile.**
+
+ Introduced event link profiles that can be used to associated links between
+ event queues and an event port with a unique identifier termed as link profile.
+ The profile can be used to switch between the associated links in fast-path
+ without the additional overhead of linking/unlinking and waiting for unlinking.
+
+ * Added ``rte_event_port_profile_links_set``, ``rte_event_port_profile_unlink``
+ ``rte_event_port_profile_links_get`` and ``rte_event_port_profile_switch``
+ functions to enable this feature.
+
+* **Updated Marvell cnxk eventdev driver.**
+
+ * Added support for ``remaining_ticks_get`` timer adapter PMD callback
+ to get the remaining ticks to expire for a given event timer.
+ * Added link profiles support, up to two link profiles are supported.
+
+* **Added dispatcher library.**
+
+ Added dispatcher library which purpose is to help decouple different
+ parts (modules) of an eventdev-based application.
+
+* **Added a command option ``--relax-rx-mode`` in l3fwd example.**
+
+ Added a command option ``--relax-rx-mode`` in l3fwd example
+ to relax the rx RSS/Offload mode requirement if needed.
Removed Items
-------------
@@ -99,10 +246,23 @@ Removed Items
* eal: Removed deprecated ``RTE_FUNC_PTR_OR_*`` macros.
+* ethdev: Removed deprecated macro ``RTE_ETH_DEV_BONDED_SLAVE``.
+
* flow_classify: Removed flow classification library and examples.
* kni: Removed the Kernel Network Interface (KNI) library and driver.
+* cryptodev: Removed the arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+ ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+ ``rte_crypto_asym_xform_strings``.
+
+* cryptodev: Removed explicit SM2 xform parameter in asymmetric xform.
+
+* security: Removed deprecated field ``reserved_opts``
+ from struct ``rte_security_ipsec_sa_options``.
+
+* mldev: Removed functions ``rte_ml_io_input_size_get`` and ``rte_ml_io_output_size_get``.
+
API Changes
-----------
@@ -125,6 +285,38 @@ API Changes
except ``rte_thread_setname()`` and ``rte_ctrl_thread_create()`` which are
replaced with ``rte_thread_set_name()`` and ``rte_thread_create_control()``.
+* eal: Removed ``RTE_CPUFLAG_NUMFLAGS`` to avoid misusage and theoretical ABI
+ compatibility issue when adding new cpuflags.
+
+* bonding: Replaced master/slave to main/member. The data structure
+ ``struct rte_eth_bond_8023ad_slave_info`` was renamed to
+ ``struct rte_eth_bond_8023ad_member_info`` in DPDK 23.11.
+ The following functions were removed in DPDK 23.11.
+ The old functions:
+ ``rte_eth_bond_8023ad_slave_info``,
+ ``rte_eth_bond_active_slaves_get``,
+ ``rte_eth_bond_slave_add``,
+ ``rte_eth_bond_slave_remove``, and
+ ``rte_eth_bond_slaves_get``
+ will be replaced by:
+ ``rte_eth_bond_8023ad_member_info``,
+ ``rte_eth_bond_active_members_get``,
+ ``rte_eth_bond_member_add``,
+ ``rte_eth_bond_member_remove``, and
+ ``rte_eth_bond_members_get``.
+
+* cryptodev: The elliptic curve asymmetric private and public keys can be maintained
+ per session. These keys are moved from per packet ``rte_crypto_ecdsa_op_param`` and
+ ``rte_crypto_sm2_op_param`` to generic EC xform ``rte_crypto_ec_xform``.
+
+* security: Structures ``rte_security_ops`` and ``rte_security_ctx`` were moved to
+ internal library headers not visible to application.
+
+* mldev: Updated the structure ``rte_ml_model_info`` to support input and output
+ with arbitrary shapes.
+ Updated ``rte_ml_op``, ``rte_ml_io_quantize`` and ``rte_ml_io_dequantize``
+ to support an array of ``rte_ml_buff_seg``.
+
ABI Changes
-----------
@@ -141,6 +333,17 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: Added ``recycle_tx_mbufs_reuse`` and ``recycle_rx_descriptors_refill``
+ fields to ``rte_eth_dev`` structure.
+
+* ethdev: Structure ``rte_eth_fp_ops`` was affected to add
+ ``recycle_tx_mbufs_reuse`` and ``recycle_rx_descriptors_refill``
+ fields, to move ``rxq`` and ``txq`` fields, to change the size of
+ ``reserved1`` and ``reserved2`` fields.
+
+* security: struct ``rte_security_ipsec_sa_options`` was updated
+ due to inline out-of-place feature addition.
+
Known Issues
------------
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index 1cc2c1dd1d..00283f070c 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -126,6 +126,8 @@ Where,
* ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type.
+* ``--relax-rx-mode:`` Optional, set to enable rx mode relax when RSS/offload is not fully supported by the hardware. When the IPv4 cksum offload is relaxed, it is calculated by the software instead. Without this option, the RSS and cksum offload will be forced.
+
* ``--per-port-pool:`` Optional, set to use independent buffer pools per port. Without this option, single buffer pool is used for all ports.
* ``--mode:`` Optional, Packet transfer mode for I/O, poll or eventdev.
@@ -140,7 +142,7 @@ Where,
* ``--event-vector-tmo:`` Optional, Max timeout to form vector in nanoseconds if event vectorization is enabled.
-* ``--alg=<val>:`` optional, ACL classify method to use, one of:
+* ``--alg=<val>:`` Optional, ACL classify method to use, one of:
``scalar|sse|avx2|neon|altivec|avx512x16|avx512x32``
* ``-E:`` Optional, enable exact match,
--
2.34.1
^ permalink raw reply [relevance 9%]
* RE: [PATCH v3] bus/cdx: provide driver flag for optional resource mapping
2023-10-04 12:54 0% ` David Marchand
@ 2023-10-13 11:51 0% ` Gangurde, Abhijit
2023-10-13 12:15 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Gangurde, Abhijit @ 2023-10-13 11:51 UTC (permalink / raw)
To: David Marchand; +Cc: Gupta, Nipun, Agarwal, Nikhil, dev, Yigit, Ferruh, thomas
> > > > +/**
> > > > + * Map the CDX device resources in user space virtual memory address.
> > > > + *
> > > > + * Note that driver should not call this function when flag
> > > > + * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
> > > > + * you when it's on.
> > >
> > > Why should we export this function in the application ABI, if it is
> > > only used by drivers?
> >
> > This can be called from an application as well if this flag is not set hence, we
> need to export this function.
>
> What kind of applications / in which usecase, one would need to map
> the device resources?
> Except a driver?
I understand that it is probably not the ideal use case, but some of the customers
are using a single application which also registers itself as driver. Probably such
applications need to use internal APIs instead of making these APIs external.
Will analyze it further and send another rev of this patch.
Thanks,
Abhijit
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3] bus/cdx: provide driver flag for optional resource mapping
2023-10-13 11:51 0% ` Gangurde, Abhijit
@ 2023-10-13 12:15 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-10-13 12:15 UTC (permalink / raw)
To: Gangurde, Abhijit
Cc: Gupta, Nipun, Agarwal, Nikhil, dev, Yigit, Ferruh, thomas
On Fri, Oct 13, 2023 at 1:52 PM Gangurde, Abhijit
<abhijit.gangurde@amd.com> wrote:
>
> > > > > +/**
> > > > > + * Map the CDX device resources in user space virtual memory address.
> > > > > + *
> > > > > + * Note that driver should not call this function when flag
> > > > > + * RTE_CDX_DRV_NEED_MAPPING is set, as EAL will do that for
> > > > > + * you when it's on.
> > > >
> > > > Why should we export this function in the application ABI, if it is
> > > > only used by drivers?
> > >
> > > This can be called from an application as well if this flag is not set hence, we
> > need to export this function.
> >
> > What kind of applications / in which usecase, one would need to map
> > the device resources?
> > Except a driver?
>
> I understand that it is probably not the ideal use case, but some of the customers
> are using a single application which also registers itself as driver. Probably such
> applications need to use internal APIs instead of making these APIs external.
> Will analyze it further and send another rev of this patch.
External drivers should be supported with current code.
DPDK must be built with enable_driver_sdk option, and the external
driver code can include bus_cdx_driver.h.
Possibly compiling this code with -DENABLE_INTERNAL_API cflag will be necessary.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [PATCH v2] ci: test stdatomic API
@ 2023-10-17 7:15 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-10-17 7:15 UTC (permalink / raw)
To: dev; +Cc: thomas, Aaron Conole, Michael Santana, Bruce Richardson
Add some compilation tests with C11 atomics enabled.
The headers check can't be enabled (as gcc and clang don't provide
stdatomic before C++23).
Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
---
Changelog from v1:
- following Thomas offlist review, tweaked coverage in
test-meson-builds.sh to reduce the number of build targets,
---
.ci/linux-build.sh | 6 +++++-
.github/workflows/build.yml | 8 ++++++++
devtools/test-meson-builds.sh | 4 +++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index e0b62bac90..b09df07b55 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -92,7 +92,11 @@ fi
OPTS="$OPTS -Dplatform=generic"
OPTS="$OPTS -Ddefault_library=$DEF_LIB"
OPTS="$OPTS -Dbuildtype=$buildtype"
-OPTS="$OPTS -Dcheck_includes=true"
+if [ "$STDATOMIC" = "true" ]; then
+ OPTS="$OPTS -Denable_stdatomic=true"
+else
+ OPTS="$OPTS -Dcheck_includes=true"
+fi
if [ "$MINI" = "true" ]; then
OPTS="$OPTS -Denable_drivers=net/null"
OPTS="$OPTS -Ddisable_libs=*"
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 7a2ac0ceee..14328622fb 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -30,6 +30,7 @@ jobs:
REF_GIT_TAG: none
RISCV64: ${{ matrix.config.cross == 'riscv64' }}
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
+ STDATOMIC: ${{ contains(matrix.config.checks, 'stdatomic') }}
strategy:
fail-fast: false
@@ -38,6 +39,12 @@ jobs:
- os: ubuntu-20.04
compiler: gcc
mini: mini
+ - os: ubuntu-20.04
+ compiler: gcc
+ checks: stdatomic
+ - os: ubuntu-20.04
+ compiler: clang
+ checks: stdatomic
- os: ubuntu-20.04
compiler: gcc
checks: debug+doc+examples+tests
@@ -241,6 +248,7 @@ jobs:
> ~/env
echo CC=ccache ${{ matrix.config.compiler }} >> ~/env
echo DEF_LIB=${{ matrix.config.library }} >> ~/env
+ echo STDATOMIC=false >> ~/env
- name: Load the cached image
run: |
docker load -i ~/.image/${{ matrix.config.image }}.tar
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 605a855999..5c07063cbd 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -227,11 +227,13 @@ for c in gcc clang ; do
for s in static shared ; do
if [ $s = shared ] ; then
abicheck=ABI
+ stdatomic=-Denable_stdatomic=true
else
abicheck=skipABI # save time and disk space
+ stdatomic=-Denable_stdatomic=false
fi
export CC="$CCACHE $c"
- build build-$c-$s $c $abicheck --default-library=$s
+ build build-$c-$s $c $abicheck $stdatomic --default-library=$s
unset CC
done
done
--
2.41.0
^ permalink raw reply [relevance 4%]
* [PATCH] event/cnxk: fix symbol map
@ 2023-10-17 12:35 3% David Marchand
2023-10-17 12:38 0% ` [EXT] " Pavan Nikhilesh Bhagavatula
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-10-17 12:35 UTC (permalink / raw)
To: dev, thomas; +Cc: Pavan Nikhilesh, Shijith Thotton, Jerin Jacob
Caught while rebasing a series that check map files.
Remove superfluous whitespace.
Current ABI number is 24.
Sort experimental symbols and annotate them with the version they are
introduced in.
Fixes: 03714a41bd26 ("event/cnxk: add event port flow context API")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
drivers/event/cnxk/version.map | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/event/cnxk/version.map b/drivers/event/cnxk/version.map
index 9dbf8eb59d..3dd9a8fdd1 100644
--- a/drivers/event/cnxk/version.map
+++ b/drivers/event/cnxk/version.map
@@ -1,9 +1,11 @@
- DPDK_23 {
+DPDK_24 {
local: *;
- };
+};
- EXPERIMENTAL {
+EXPERIMENTAL {
global:
- rte_pmd_cnxk_eventdev_wait_head;
+
+ # added in 23.11
rte_pmd_cnxk_eventdev_is_head;
- };
+ rte_pmd_cnxk_eventdev_wait_head;
+};
--
2.41.0
^ permalink raw reply [relevance 3%]
* RE: [EXT] [PATCH] event/cnxk: fix symbol map
2023-10-17 12:35 3% [PATCH] event/cnxk: fix symbol map David Marchand
@ 2023-10-17 12:38 0% ` Pavan Nikhilesh Bhagavatula
0 siblings, 0 replies; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2023-10-17 12:38 UTC (permalink / raw)
To: David Marchand, dev, thomas; +Cc: Shijith Thotton, Jerin Jacob Kollanukkaran
> Caught while rebasing a series that check map files.
>
> Remove superfluous whitespace.
> Current ABI number is 24.
> Sort experimental symbols and annotate them with the version they are
> introduced in.
>
> Fixes: 03714a41bd26 ("event/cnxk: add event port flow context API")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Thank you.
Acked-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> drivers/event/cnxk/version.map | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/event/cnxk/version.map
> b/drivers/event/cnxk/version.map
> index 9dbf8eb59d..3dd9a8fdd1 100644
> --- a/drivers/event/cnxk/version.map
> +++ b/drivers/event/cnxk/version.map
> @@ -1,9 +1,11 @@
> - DPDK_23 {
> +DPDK_24 {
> local: *;
> - };
> +};
>
> - EXPERIMENTAL {
> +EXPERIMENTAL {
> global:
> - rte_pmd_cnxk_eventdev_wait_head;
> +
> + # added in 23.11
> rte_pmd_cnxk_eventdev_is_head;
> - };
> + rte_pmd_cnxk_eventdev_wait_head;
> +};
> --
> 2.41.0
^ permalink raw reply [relevance 0%]
* release candidate 23.11-rc1
@ 2023-10-17 20:36 4% Thomas Monjalon
[not found] ` <MW4PR11MB5912D298978501DAC2092EA49FD4A@MW4PR11MB5912.namprd11.prod.outlook.com>
2023-10-31 23:15 0% ` Thinh Tran
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-10-17 20:36 UTC (permalink / raw)
To: announce
A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v23.11-rc1
There are 617 new patches in this snapshot,
including many API/ABI compatibility breakages.
This release won't be ABI-compatible with previous ones.
Release notes:
https://doc.dpdk.org/guides/rel_notes/release_23_11.html
Highlights of 23.11-rc1:
- build requires C11 compiler
- early support of MSVC build
- new atomic operations API
- power management on AMD CPU
- mbuf recycling
- flow action type for P4-defined actions
- flow group miss action
- flow item for packet type matching
- TLS record offload
- security Rx inject
- eventdev link profiles
- eventdev adapter for dmadev
- event dispatcher library
Please test and report issues on bugs.dpdk.org.
DPDK 23.11-rc2 is expected in approximately two weeks.
Thank you everyone
^ permalink raw reply [relevance 4%]
* RE: [PATCH v1 5/6] power: add eventdev support for power management
@ 2023-10-18 7:08 3% ` Tummala, Sivaprasad
2023-10-18 7:13 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Tummala, Sivaprasad @ 2023-10-18 7:08 UTC (permalink / raw)
To: Jerin Jacob
Cc: harry.van.haaren, anatoly.burakov, dev, Yigit, Ferruh, david.hunt
[AMD Official Use Only - General]
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 17, 2023 8:53 AM
> To: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
> Cc: harry.van.haaren@intel.com; anatoly.burakov@intel.com; dev@dpdk.org; Yigit,
> Ferruh <Ferruh.Yigit@amd.com>; david.hunt@intel.com
> Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Tue, Oct 17, 2023 at 2:27 AM Sivaprasad Tummala
> <sivaprasad.tummala@amd.com> wrote:
> >
> > Add eventdev support to enable power saving when no events are
> > arriving. It is based on counting the number of empty polls and, when
> > the number reaches a certain threshold, entering an
> > architecture-defined optimized power state that will either wait until
> > a TSC timestamp expires, or when events arrive.
> >
> > This API mandates a core-to-single-port mapping (i.e. one core polling
> > multiple ports of event device is not supported). This should be ok as
> > the general use case will have one CPU core using one port to
> > enqueue/dequeue events from an eventdev.
> >
> > This design is using Eventdev PMD Dequeue callbacks.
> >
> > 1. MWAITX/MONITORX:
> >
> > When a certain threshold of empty polls is reached, the core will go
> > into a power optimized sleep while waiting on an address of next RX
> > descriptor to be written to.
> >
> > 2. Pause instruction
> >
> > This method uses the pause instruction to avoid busy polling.
> >
> > Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
>
>
> Hi Siva,
>
> It does not look it is aligned with previous discussion.
>
> I spend a couple of minutes to draft semantics. Please treat as reference.
>
> # IMO, only following public SLOW PATH eventdev API required.(Just share the
> concept)
>
> enum rte_event_pmgmt_modes {
> /** Default power management scheme */
> RTE_EVENT_POWER_MGMT_TYPE_DEFAULT;
> /** Use power-optimized monitoring to wait for incoming traffic */
> RTE_EVENT_POWER_MGMT_TYPE_F_CPU_MONITOR = RTE_BIT(0),
> /** Use power-optimized sleep to avoid busy polling */
> RTE_EVENT_POWER_MGMT_TYPE_F_CPU_PAUSE = RTE_BIT(1),
> /** HW based power management scheme found in ARM64 machines, where
> core goes to sleep state till event available on dequeue */
> RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE = RTE_BIT(2),
>
> };
>
> int rte_event_port_pmgmt_type_supported_get(uint8_t dev_id, enum
> rte_event_pmgmt_modes *mode_flags)
> /** Device must be in stop state */
> int rte_event_port_pmgmt_enable(uint8_t dev_id, uint8_t port_id, enum
> rte_event_pmgmt_modes mode); int rte_event_port_pmgmt_disable(uint8_t
> dev_id, uint8_t port_id);
>
> # It should be self-contained, No need to add to rte_power as it is CPU only power
> mgmt.(See RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE
> above)
>
> # Add: lib/eventdev/eventdev_pmd_pmgmt.c or so and have CPU based on power
> management helper functions so that all SW PMD can be reused.
> example:
> eventdev_pmd_pmgmt_handle_monitor(uint8_t dev_id, uint8_t port_id, struct
> rte_event ev[], uint16_t nb_events);
> eventdev_pmd_pmgmt_handle_pause(uint8_t dev_id, uint8_t port_id, struct
> rte_event ev[], uint16_t nb_events);
>
>
> # In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based power
> management is applicable,and it is selected.
> ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst +
> eventdev_pmd_pmgmt_handle_.. (based on power management mode selected)
Thanks for the clarification. Will incorporate the changes in next version of the patch (to support power management on event port).
With the time constraints, I will defer the power management support on event port to next release. However to avoid ABI breakage,
I will split the Patchset and push the patches to support callbacks in this release, so we don't have to wait for next stable release to
get these changes integrated.
Please let me know your thoughts.
Thanks & Regards,
Sivaprasad
^ permalink raw reply [relevance 3%]
* Re: [PATCH v1 5/6] power: add eventdev support for power management
2023-10-18 7:08 3% ` Tummala, Sivaprasad
@ 2023-10-18 7:13 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-10-18 7:13 UTC (permalink / raw)
To: Tummala, Sivaprasad
Cc: harry.van.haaren, anatoly.burakov, dev, Yigit, Ferruh, david.hunt
On Wed, Oct 18, 2023 at 12:38 PM Tummala, Sivaprasad
<Sivaprasad.Tummala@amd.com> wrote:
>
> [AMD Official Use Only - General]
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 17, 2023 8:53 AM
> > To: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
> > Cc: harry.van.haaren@intel.com; anatoly.burakov@intel.com; dev@dpdk.org; Yigit,
> > Ferruh <Ferruh.Yigit@amd.com>; david.hunt@intel.com
> > Subject: Re: [PATCH v1 5/6] power: add eventdev support for power management
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Tue, Oct 17, 2023 at 2:27 AM Sivaprasad Tummala
> > <sivaprasad.tummala@amd.com> wrote:
> > >
> > > Add eventdev support to enable power saving when no events are
> > > arriving. It is based on counting the number of empty polls and, when
> > > the number reaches a certain threshold, entering an
> > > architecture-defined optimized power state that will either wait until
> > > a TSC timestamp expires, or when events arrive.
> > >
> > > This API mandates a core-to-single-port mapping (i.e. one core polling
> > > multiple ports of event device is not supported). This should be ok as
> > > the general use case will have one CPU core using one port to
> > > enqueue/dequeue events from an eventdev.
> > >
> > > This design is using Eventdev PMD Dequeue callbacks.
> > >
> > > 1. MWAITX/MONITORX:
> > >
> > > When a certain threshold of empty polls is reached, the core will go
> > > into a power optimized sleep while waiting on an address of next RX
> > > descriptor to be written to.
> > >
> > > 2. Pause instruction
> > >
> > > This method uses the pause instruction to avoid busy polling.
> > >
> > > Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
> >
> >
> > Hi Siva,
> >
> > It does not look it is aligned with previous discussion.
> >
> > I spend a couple of minutes to draft semantics. Please treat as reference.
> >
> > # IMO, only following public SLOW PATH eventdev API required.(Just share the
> > concept)
> >
> > enum rte_event_pmgmt_modes {
> > /** Default power management scheme */
> > RTE_EVENT_POWER_MGMT_TYPE_DEFAULT;
> > /** Use power-optimized monitoring to wait for incoming traffic */
> > RTE_EVENT_POWER_MGMT_TYPE_F_CPU_MONITOR = RTE_BIT(0),
> > /** Use power-optimized sleep to avoid busy polling */
> > RTE_EVENT_POWER_MGMT_TYPE_F_CPU_PAUSE = RTE_BIT(1),
> > /** HW based power management scheme found in ARM64 machines, where
> > core goes to sleep state till event available on dequeue */
> > RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE = RTE_BIT(2),
> >
> > };
> >
> > int rte_event_port_pmgmt_type_supported_get(uint8_t dev_id, enum
> > rte_event_pmgmt_modes *mode_flags)
> > /** Device must be in stop state */
> > int rte_event_port_pmgmt_enable(uint8_t dev_id, uint8_t port_id, enum
> > rte_event_pmgmt_modes mode); int rte_event_port_pmgmt_disable(uint8_t
> > dev_id, uint8_t port_id);
> >
> > # It should be self-contained, No need to add to rte_power as it is CPU only power
> > mgmt.(See RTE_EVENT_POWER_MGMT_TYPE_F_HW_WFE_ON_DEQUEUE
> > above)
> >
> > # Add: lib/eventdev/eventdev_pmd_pmgmt.c or so and have CPU based on power
> > management helper functions so that all SW PMD can be reused.
> > example:
> > eventdev_pmd_pmgmt_handle_monitor(uint8_t dev_id, uint8_t port_id, struct
> > rte_event ev[], uint16_t nb_events);
> > eventdev_pmd_pmgmt_handle_pause(uint8_t dev_id, uint8_t port_id, struct
> > rte_event ev[], uint16_t nb_events);
> >
> >
> > # In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based power
> > management is applicable,and it is selected.
> > ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst +
> > eventdev_pmd_pmgmt_handle_.. (based on power management mode selected)
>
> Thanks for the clarification. Will incorporate the changes in next version of the patch (to support power management on event port).
> With the time constraints, I will defer the power management support on event port to next release. However to avoid ABI breakage,
> I will split the Patchset and push the patches to support callbacks in this release, so we don't have to wait for next stable release to
> get these changes integrated.
if you follow this scheme, public callback API is not needed.
# In rte_event_dev_start(), Fixup dev->dequeue_burst if CPU based power
management is applicable,and it is selected.
ie. new dev->dequeue_burst is existing PMD's dev->dequeue_burst +
eventdev_pmd_pmgmt_handle_.. (based on power management mode selected)
>
> Please let me know your thoughts.
>
> Thanks & Regards,
> Sivaprasad
^ permalink raw reply [relevance 0%]
* Re: [PATCH v6 18/34] ml/cnxk: support config and close of tvmdp library
@ 2023-10-18 18:34 5% ` Jerin Jacob
2023-10-19 6:44 0% ` [EXT] " Srikanth Yalavarthi
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-10-18 18:34 UTC (permalink / raw)
To: Srikanth Yalavarthi; +Cc: dev, sshankarnara, aprabhu, ptakkar
On Wed, Oct 18, 2023 at 7:52 PM Srikanth Yalavarthi
<syalavarthi@marvell.com> wrote:
>
> Added support to configure and close TVMDP library based
> on ML device configuration options.
>
> Updated meson build to enable Jansson, TVM runtime, TVMDP
> library as build dependencies.
>
> Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
> ---
>
> +Compilation Prerequisites
> +-------------------------
> +
> +This driver requires external libraries to optionally enable support for
> +models compiled using Apache TVM framework. The following dependencies are
> +not part of DPDK and must be installed separately:
> +
> +- **Jansson**
> +
> + This library enables support to parse and read JSON files.
> +
> +- **DLPack**
> +
> + This library provides headers for open in-memory tensor structures.
> +
> +.. note::
> +
> + DPDK CNXK ML driver requires DLPack version 0.7
> +
> +.. code-block:: console
Please add sections for cross and native.
> + git clone https://github.com/dmlc/dlpack.git
> + cd dlpack
> + git checkout v0.7 -b v0.7
> + cmake -S ./ -B build \
> + -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
> + -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \
> + -DBUILD_MOCK=OFF
> + make -C build
> + make -C build install
> +
> +- **TVM**
> +
> + Apache TVM provides a runtime library (libtvm_runtime) used to execute
> + models on CPU cores or hardware accelerators.
> +
> +.. note::
> +
> + DPDK CNXK ML driver requires TVM version 0.10.0
> +
> +.. code-block:: console
> +
> + git clone https://github.com/apache/tvm.git
I need to use --recursive to avoid
CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:3176 (message):
No download info given for 'project_libbacktrace' and its source directory:
> + cd tvm
> + git checkout v0.10.0 -b v0.10.0
> + cmake -S ./ -B build \
> + -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
> + -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \
> + -DMACHINE_NAME=aarch64-linux-gnu \
> + -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \
> + -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
> + make -C build
> + make -C build install
> +
> +- **TVMDP**
> +
> + Marvell's `TVM Dataplane Library <https://github.com/MarvellEmbeddedProcessors/tvmdp>`_
> + works as an interface between TVM runtime and DPDK drivers. TVMDP library
> + provides a simplified C interface for TVM's runtime based on C++.
> +
> +.. code-block:: console
> +
> + git clone https://github.com/MarvellEmbeddedProcessors/tvmdp.git
> + cd tvmdp
> + git checkout main
> + cmake -S ./ -B build \
> + -DCMAKE_TOOLCHAIN_FILE=config/toolchains/arm64_linux_gcc.cmake \
> + -DBUILD_SHARED_LIBS=ON \
> + -DBUILD_TESTING=OFF
[main]dell[tvmdp] $ cmake -S ./ -B build
-DCMAKE_INSTALL_PREFIX=/export/cross_prefix/prefix
-DCMAKE_TOOLCHAIN_FILE=config/toolchains/arm64_linux_gcc.cmake
-DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=OFF
-- The CXX compiler identification is GNU 13.2.0
-- The C compiler identification is GNU 13.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at CMakeLists.txt:53 (find_package):
By not providing "Finddmlc.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "dmlc", but
CMake did not find one.
Could not find a package configuration file provided by "dmlc" with any of
the following names:
dmlcConfig.cmake
dmlc-config.cmake
Add the installation prefix of "dmlc" to CMAKE_PREFIX_PATH or set
"dmlc_DIR" to a directory containing one of the above files. If "dmlc"
provides a separate development package or SDK, be sure it has been
installed.
-- Configuring incomplete, errors occurred!
> +enable_mvtvm = true
> +
> +if not jansson_dep.found()
> + message('drivers/ml/cnxk: jansson not found')
> + enable_mvtvm = false
> +endif
> +
> +if not cc.check_header('dlpack/dlpack.h')
> + message('drivers/ml/cnxk: dlpack.h not found')
> + enable_mvtvm = false
> +endif
> +
> +tvmrt_lib = cc.find_library('tvm_runtime', required: false)
> +if tvmrt_lib.found()
> + tvmrt_dep = declare_dependency(dependencies: tvmrt_lib)
> +else
> + message('drivers/ml/cnxk: tvm_runtime not found')
> + enable_mvtvm = false
> +endif
> +
> +tvmdp_dep = dependency('tvmdp', required: false)
> +if not tvmdp_dep.found()
> + message('drivers/ml/cnxk: tvmdp not found')
> + enable_mvtvm = false
> +endif
> +
> sources = files(
> 'cn10k_ml_dev.c',
> 'cn10k_ml_ops.c',
> @@ -21,6 +47,39 @@ sources = files(
>
> deps += ['mldev', 'common_cnxk', 'kvargs', 'hash']
>
> +if enable_mvtvm
> +
> +dpdk_conf.set('RTE_MLDEV_CNXK_ENABLE_MVTVM', 1)
> +
> +driver_sdk_headers += files(
> + 'mvtvm_ml_ops.h',
> +)
Remove this
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 00/29] promote many API's to stable
@ 2023-10-18 19:14 0% ` David Marchand
2023-10-18 19:41 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-10-18 19:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Tyler Retzlaff, Thomas Monjalon
Hello Stephen,
On Wed, Aug 9, 2023 at 2:10 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Since 23.11 is an LTS release it is time to remove the experimental
> bandaid off many API's. There are about 850 API's marked with experimental
> on current main branch. This addresses the easy to remove ones and
> gets it down to about 690 places.
>
> The rule is any API that has been in since 22.11 needs to have
> experimental removed (or deleted). The experimental flag is
> intended to be temporary not a "get out of ABI stability for free" card.
>
> v2 - add more libraries to the mix
> - remove EXPERIMENTAL where tagged in MAINTAINERS
There were some API updates merged in -rc1.
Could you please rebase this series?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 00/29] promote many API's to stable
2023-10-18 19:14 0% ` David Marchand
@ 2023-10-18 19:41 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-10-18 19:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Tyler Retzlaff, Thomas Monjalon
On Wed, Oct 18, 2023 at 9:14 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Hello Stephen,
>
> On Wed, Aug 9, 2023 at 2:10 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > Since 23.11 is an LTS release it is time to remove the experimental
> > bandaid off many API's. There are about 850 API's marked with experimental
> > on current main branch. This addresses the easy to remove ones and
> > gets it down to about 690 places.
> >
> > The rule is any API that has been in since 22.11 needs to have
> > experimental removed (or deleted). The experimental flag is
> > intended to be temporary not a "get out of ABI stability for free" card.
> >
> > v2 - add more libraries to the mix
> > - remove EXPERIMENTAL where tagged in MAINTAINERS
>
> There were some API updates merged in -rc1.
> Could you please rebase this series?
Some additional comments to this request.
rte_compat.h is only needed for __rte_experimental and __rte_internal tags.
There is probably some unnecessary #include <rte_compat.h> left behind
after this series.
About version.map content, I recommend using ./devtools/update-abi.sh
$(cat ABI_VERSION) as it sorts the stable symbols for you (but leave
experimental and internal sections untouched).
--
David Marchand
^ permalink raw reply [relevance 3%]
* RE: [EXT] Re: [PATCH v6 18/34] ml/cnxk: support config and close of tvmdp library
2023-10-18 18:34 5% ` Jerin Jacob
@ 2023-10-19 6:44 0% ` Srikanth Yalavarthi
0 siblings, 0 replies; 200+ results
From: Srikanth Yalavarthi @ 2023-10-19 6:44 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, Shivah Shankar Shankar Narayan Rao, Anup Prabhu,
Prince Takkar, Srikanth Yalavarthi
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: 19 October 2023 00:04
> To: Srikanth Yalavarthi <syalavarthi@marvell.com>
> Cc: dev@dpdk.org; Shivah Shankar Shankar Narayan Rao
> <sshankarnara@marvell.com>; Anup Prabhu <aprabhu@marvell.com>;
> Prince Takkar <ptakkar@marvell.com>; Srikanth Yalavarthi
> <syalavarthi@marvell.com>
> Subject: [EXT] Re: [PATCH v6 18/34] ml/cnxk: support config and close of
> tvmdp library
>
> External Email
>
> ----------------------------------------------------------------------
> On Wed, Oct 18, 2023 at 7:52 PM Srikanth Yalavarthi
> <syalavarthi@marvell.com> wrote:
> >
> > Added support to configure and close TVMDP library based on ML device
> > configuration options.
> >
> > Updated meson build to enable Jansson, TVM runtime, TVMDP library as
> > build dependencies.
> >
> > Signed-off-by: Srikanth Yalavarthi <syalavarthi@marvell.com>
> > ---
>
> >
> > +Compilation Prerequisites
> > +-------------------------
> > +
> > +This driver requires external libraries to optionally enable support
> > +for models compiled using Apache TVM framework. The following
> > +dependencies are not part of DPDK and must be installed separately:
> > +
> > +- **Jansson**
> > +
> > + This library enables support to parse and read JSON files.
> > +
> > +- **DLPack**
> > +
> > + This library provides headers for open in-memory tensor structures.
> > +
> > +.. note::
> > +
> > + DPDK CNXK ML driver requires DLPack version 0.7
> > +
> > +.. code-block:: console
>
>
> Please add sections for cross and native.
>
> > + git clone https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_dmlc_dlpack.git&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ
> &r=SNPqUkGl0n_Ms1iJa_6wD6LBwX8efL_NOyXvAX-
> iCMI&m=Af3Vz7Jwj42zg2TmQe6-
> BpsSzCWoeRVDxlAtzIB9e_Rtv6KG1mT0_Lq0_HnJyz1E&s=d5Yn2kMNnw-
> GyGXVRyExfsC8-Uy9S3TKnW0boz8mlsI&e=
> > + cd dlpack
> > + git checkout v0.7 -b v0.7
> > + cmake -S ./ -B build \
> > + -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
> > + -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \
> > + -DBUILD_MOCK=OFF
> > + make -C build
> > + make -C build install
> > +
> > +- **TVM**
> > +
> > + Apache TVM provides a runtime library (libtvm_runtime) used to
> > + execute models on CPU cores or hardware accelerators.
> > +
> > +.. note::
> > +
> > + DPDK CNXK ML driver requires TVM version 0.10.0
> > +
> > +.. code-block:: console
> > +
> > + git clone
> > + https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_apac
> > +
> he_tvm.git&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=SNPqUkGl0n_Ms1
> iJa_6wD
> > + 6LBwX8efL_NOyXvAX-iCMI&m=Af3Vz7Jwj42zg2TmQe6-
> BpsSzCWoeRVDxlAtzIB9e_R
> > + tv6KG1mT0_Lq0_HnJyz1E&s=pj_HUWALTg49rW1wRTyzB-yWSyuHzWr-
> XzPycb8UtlI&
> > + e=
>
> I need to use --recursive to avoid
> CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:3176
> (message):
> No download info given for 'project_libbacktrace' and its source directory:
Updated build steps in version 7. Added steps to initialize submodules.
>
>
> > + cd tvm
> > + git checkout v0.10.0 -b v0.10.0
> > + cmake -S ./ -B build \
> > + -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc \
> > + -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ \
> > + -DMACHINE_NAME=aarch64-linux-gnu \
> > + -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER \
> > + -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY
> > + make -C build
> > + make -C build install
> > +
> > +- **TVMDP**
> > +
> > + Marvell's `TVM Dataplane Library
> > + <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_Mar
> > +
> vellEmbeddedProcessors_tvmdp&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ
> &r=SNPqUkGl0n_Ms1iJa_6wD6LBwX8efL_NOyXvAX-
> iCMI&m=Af3Vz7Jwj42zg2TmQe6-
> BpsSzCWoeRVDxlAtzIB9e_Rtv6KG1mT0_Lq0_HnJyz1E&s=kqu82cbMqOdusys
> dSYmp2cCwH9VTwcVvmMK0wqy04w0&e= >`_ works as an interface
> between TVM runtime and DPDK drivers. TVMDP library provides a
> simplified C interface for TVM's runtime based on C++.
> > +
> > +.. code-block:: console
> > +
> > + git clone https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_MarvellEmbeddedProcessors_tvmdp.git&d=DwIFaQ&c=nK
> jWec2b6R0mOyPaz7xtfQ&r=SNPqUkGl0n_Ms1iJa_6wD6LBwX8efL_NOyXvAX
> -iCMI&m=Af3Vz7Jwj42zg2TmQe6-
> BpsSzCWoeRVDxlAtzIB9e_Rtv6KG1mT0_Lq0_HnJyz1E&s=pR-
> 2iG1huVG6g7jrnjHx-nhJVQHnJWu-UJxrd6ziFx4&e=
> > + cd tvmdp
> > + git checkout main
> > + cmake -S ./ -B build \
> > + -
> DCMAKE_TOOLCHAIN_FILE=config/toolchains/arm64_linux_gcc.cmake \
> > + -DBUILD_SHARED_LIBS=ON \
> > + -DBUILD_TESTING=OFF
>
> [main]dell[tvmdp] $ cmake -S ./ -B build -
> DCMAKE_INSTALL_PREFIX=/export/cross_prefix/prefix
> -DCMAKE_TOOLCHAIN_FILE=config/toolchains/arm64_linux_gcc.cmake
> -DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=OFF
> -- The CXX compiler identification is GNU 13.2.0
> -- The C compiler identification is GNU 13.2.0
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> CMake Error at CMakeLists.txt:53 (find_package):
> By not providing "Finddmlc.cmake" in CMAKE_MODULE_PATH this project
> has
> asked CMake to find a package configuration file provided by "dmlc", but
> CMake did not find one.
>
> Could not find a package configuration file provided by "dmlc" with any of
> the following names:
>
> dmlcConfig.cmake
> dmlc-config.cmake
>
> Add the installation prefix of "dmlc" to CMAKE_PREFIX_PATH or set
> "dmlc_DIR" to a directory containing one of the above files. If "dmlc"
> provides a separate development package or SDK, be sure it has been
> installed.
>
>
> -- Configuring incomplete, errors occurred!
This is bug in TVMDP CMakeLists.txt. This issue is fixed now and change is pushed to TVMDP's github repo.
>
>
> > +enable_mvtvm = true
> > +
> > +if not jansson_dep.found()
> > + message('drivers/ml/cnxk: jansson not found')
> > + enable_mvtvm = false
> > +endif
> > +
> > +if not cc.check_header('dlpack/dlpack.h')
> > + message('drivers/ml/cnxk: dlpack.h not found')
> > + enable_mvtvm = false
> > +endif
> > +
> > +tvmrt_lib = cc.find_library('tvm_runtime', required: false) if
> > +tvmrt_lib.found()
> > + tvmrt_dep = declare_dependency(dependencies: tvmrt_lib) else
> > + message('drivers/ml/cnxk: tvm_runtime not found')
> > + enable_mvtvm = false
> > +endif
> > +
> > +tvmdp_dep = dependency('tvmdp', required: false) if not
> > +tvmdp_dep.found()
> > + message('drivers/ml/cnxk: tvmdp not found')
> > + enable_mvtvm = false
> > +endif
> > +
> > sources = files(
> > 'cn10k_ml_dev.c',
> > 'cn10k_ml_ops.c',
> > @@ -21,6 +47,39 @@ sources = files(
> >
> > deps += ['mldev', 'common_cnxk', 'kvargs', 'hash']
> >
> > +if enable_mvtvm
> > +
> > +dpdk_conf.set('RTE_MLDEV_CNXK_ENABLE_MVTVM', 1)
> > +
> > +driver_sdk_headers += files(
> > + 'mvtvm_ml_ops.h',
> > +)
>
> Remove this
Done. Change part of version 7.
^ permalink raw reply [relevance 0%]
* [PATCH v3 00/29] Promote experimental API's to stable.
@ 2023-10-19 16:55 3% ` Stephen Hemminger
2023-10-19 16:55 2% ` [PATCH v3 25/29] compressdev: remove experimental flag Stephen Hemminger
2023-10-19 19:09 3% ` [PATCH v4 00/28] Promote many experimental API's to stable Stephen Hemminger
` (4 subsequent siblings)
6 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-10-19 16:55 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Since 23.11 is an LTS release it is time to remove the experimental
bandaid off many API's. There are about 890 API's marked with experimental
on current main branch. This addresses the easy to remove ones and
gets it down to about 510 places.
The rule is any API that has been in since 22.11 needs to have
experimental removed (or have API deleted). The experimental flag is not a
"get out of ABI stability for free" card.
In a couple places experimental was being used where internal
would have been more appropriate.
v3 - rebase and skip cryptodev
Stephen Hemminger (29):
bpf: make rte_bpf_dump and rte_bpf_convert stable API's
cmdline: make experimental API's stable
ethdev: mark rte_mtr API's as stable
ethdev: mark rte_tm API's as stable
pdump: make API's stable
pcapng: mark API's as stable
net: remove experimental from functions
rcu: remove experimental from rte_rcu_qbsr
lpm: remove experimental
mbuf: remove experimental from create_extbuf
hash: remove experimental from toeplitz hash
timer: remove experimental from rte_timer_next_ticks
sched: remove experimental
dmadev: mark API's as not experimental
meter: remove experimental warning from comments
power: remove experimental from API's
kvargs: remove experimental flag
ip_frag: mark a couple of functions stable
member: remove experimental tag
power fix
security: remove experimental flag from macsec
vhost: remove experimental from some API's
bbdev: remove experimental tag
ipsec: remove experimental from SA API
compressdev: remove experimental flag
regexdev: remove experimental tag
node: remove some of the experimental tags
table: remove experimental from API
port: make API's stable
MAINTAINERS | 10 +-
doc/guides/rel_notes/deprecation.rst | 6 --
lib/bbdev/rte_bbdev.h | 4 -
lib/bbdev/rte_bbdev_op.h | 2 -
lib/bbdev/version.map | 15 ++-
lib/bpf/rte_bpf.h | 2 -
lib/bpf/version.map | 9 +-
lib/cmdline/cmdline.h | 1 -
lib/cmdline/cmdline_parse.h | 4 -
lib/cmdline/cmdline_rdline.h | 4 -
lib/cmdline/version.map | 26 ++---
lib/compressdev/rte_comp.h | 6 --
lib/compressdev/rte_compressdev.h | 26 -----
lib/compressdev/rte_compressdev_pmd.h | 6 --
lib/compressdev/version.map | 2 +-
lib/dmadev/rte_dmadev.h | 85 ----------------
lib/dmadev/version.map | 2 +-
lib/ethdev/rte_mtr.h | 25 +----
lib/ethdev/rte_tm.h | 34 -------
lib/ethdev/version.map | 88 ++++++++--------
lib/hash/rte_thash.h | 44 --------
lib/hash/rte_thash_gfni.h | 8 --
lib/hash/rte_thash_x86_gfni.h | 8 --
lib/hash/version.map | 16 +--
lib/ip_frag/rte_ip_frag.h | 2 -
lib/ip_frag/version.map | 9 +-
lib/ipsec/rte_ipsec.h | 2 -
lib/ipsec/version.map | 9 +-
lib/kvargs/rte_kvargs.h | 4 -
lib/kvargs/version.map | 8 +-
lib/lpm/rte_lpm.h | 4 -
lib/lpm/version.map | 7 +-
lib/mbuf/rte_mbuf.h | 1 -
lib/mbuf/version.map | 8 +-
lib/member/rte_member.h | 54 ----------
lib/member/version.map | 12 +--
lib/meter/rte_meter.h | 12 ---
lib/net/rte_ip.h | 19 ----
lib/node/rte_node_eth_api.h | 1 -
lib/node/rte_node_ip4_api.h | 2 -
lib/node/version.map | 16 ++-
lib/pcapng/rte_pcapng.h | 11 --
lib/pcapng/version.map | 6 +-
lib/pdump/rte_pdump.h | 12 ---
lib/pdump/version.map | 11 +-
lib/pipeline/rte_port_in_action.h | 8 --
lib/pipeline/rte_swx_ctl.h | 57 -----------
lib/pipeline/rte_swx_pipeline.h | 29 ------
lib/pipeline/rte_table_action.h | 16 ---
lib/pipeline/version.map | 140 ++++++++++++--------------
lib/port/version.map | 24 ++---
lib/power/rte_power.h | 4 -
lib/power/rte_power_guest_channel.h | 4 -
lib/power/rte_power_pmd_mgmt.h | 40 --------
lib/power/rte_power_uncore.h | 5 -
lib/power/version.map | 40 +++-----
lib/rcu/rte_rcu_qsbr.h | 20 ----
lib/rcu/version.map | 15 +--
lib/regexdev/rte_regexdev.h | 92 -----------------
lib/regexdev/version.map | 2 +-
lib/sched/rte_pie.h | 8 --
lib/sched/rte_sched.h | 5 -
lib/sched/version.map | 18 +---
lib/security/rte_security.h | 28 +-----
lib/security/version.map | 18 ++--
lib/table/rte_swx_table_learner.h | 10 --
lib/table/rte_swx_table_selector.h | 6 --
lib/table/rte_table_hash_func.h | 9 --
lib/table/version.map | 18 +---
lib/timer/rte_timer.h | 4 -
lib/timer/version.map | 7 +-
lib/vhost/rte_vhost.h | 5 -
lib/vhost/rte_vhost_async.h | 19 ----
lib/vhost/rte_vhost_crypto.h | 1 -
lib/vhost/version.map | 51 ++++------
75 files changed, 220 insertions(+), 1126 deletions(-)
--
2.39.2
^ permalink raw reply [relevance 3%]
* [PATCH v3 25/29] compressdev: remove experimental flag
2023-10-19 16:55 3% ` [PATCH v3 00/29] Promote experimental " Stephen Hemminger
@ 2023-10-19 16:55 2% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-19 16:55 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Thomas Monjalon, Fan Zhang, Ashish Gupta
The compressdev can not hide under the experimental flag.
Remove the experimental flag and require ABI to be stable.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
MAINTAINERS | 2 +-
lib/compressdev/rte_comp.h | 6 ------
lib/compressdev/rte_compressdev.h | 26 --------------------------
lib/compressdev/rte_compressdev_pmd.h | 6 ------
lib/compressdev/version.map | 2 +-
5 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1534a414f754..a1d4d57107a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -459,7 +459,7 @@ F: lib/security/
F: doc/guides/prog_guide/rte_security.rst
F: app/test/test_security*
-Compression API - EXPERIMENTAL
+Compression API
M: Fan Zhang <fanzhang.oss@gmail.com>
M: Ashish Gupta <ashish.gupta@marvell.com>
T: git://dpdk.org/next/dpdk-next-crypto
diff --git a/lib/compressdev/rte_comp.h b/lib/compressdev/rte_comp.h
index bf896d07223c..232564cf5e9a 100644
--- a/lib/compressdev/rte_comp.h
+++ b/lib/compressdev/rte_comp.h
@@ -499,7 +499,6 @@ struct rte_comp_op {
* - On success pointer to mempool
* - On failure NULL
*/
-__rte_experimental
struct rte_mempool *
rte_comp_op_pool_create(const char *name,
unsigned int nb_elts, unsigned int cache_size,
@@ -515,7 +514,6 @@ rte_comp_op_pool_create(const char *name,
* - On success returns a valid rte_comp_op structure
* - On failure returns NULL
*/
-__rte_experimental
struct rte_comp_op *
rte_comp_op_alloc(struct rte_mempool *mempool);
@@ -532,7 +530,6 @@ rte_comp_op_alloc(struct rte_mempool *mempool);
* - nb_ops: Success, the nb_ops requested was allocated
* - 0: Not enough entries in the mempool; no ops are retrieved.
*/
-__rte_experimental
int
rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -546,7 +543,6 @@ rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
* Compress operation pointer allocated from rte_comp_op_alloc()
* If op is NULL, no operation is performed.
*/
-__rte_experimental
void
rte_comp_op_free(struct rte_comp_op *op);
@@ -561,7 +557,6 @@ rte_comp_op_free(struct rte_comp_op *op);
* @param nb_ops
* Number of operations to free
*/
-__rte_experimental
void
rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
@@ -574,7 +569,6 @@ rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_comp_get_feature_name(uint64_t flag);
diff --git a/lib/compressdev/rte_compressdev.h b/lib/compressdev/rte_compressdev.h
index 13a418631893..8cb5db0e3f7d 100644
--- a/lib/compressdev/rte_compressdev.h
+++ b/lib/compressdev/rte_compressdev.h
@@ -10,10 +10,6 @@
*
* RTE Compression Device APIs.
*
- * @warning
- * @b EXPERIMENTAL:
- * All functions in this file may be changed or removed without prior notice.
- *
* Defines comp device APIs for the provisioning of compression operations.
*/
@@ -54,7 +50,6 @@ struct rte_compressdev_capabilities {
#define RTE_COMP_END_OF_CAPABILITIES_LIST() \
{ RTE_COMP_ALGO_UNSPECIFIED }
-__rte_experimental
const struct rte_compressdev_capabilities *
rte_compressdev_capability_get(uint8_t dev_id,
enum rte_comp_algorithm algo);
@@ -94,7 +89,6 @@ rte_compressdev_capability_get(uint8_t dev_id,
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_compressdev_get_feature_name(uint64_t flag);
@@ -133,7 +127,6 @@ struct rte_compressdev_stats {
* - Returns compress device identifier on success.
* - Return -1 on failure to find named compress device.
*/
-__rte_experimental
int
rte_compressdev_get_dev_id(const char *name);
@@ -146,7 +139,6 @@ rte_compressdev_get_dev_id(const char *name);
* - Returns compress device name.
* - Returns NULL if compress device is not present.
*/
-__rte_experimental
const char *
rte_compressdev_name_get(uint8_t dev_id);
@@ -157,7 +149,6 @@ rte_compressdev_name_get(uint8_t dev_id);
* @return
* - The total number of usable compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_count(void);
@@ -175,7 +166,6 @@ rte_compressdev_count(void);
* @return
* Returns number of attached compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
uint8_t nb_devices);
@@ -190,7 +180,6 @@ rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
* a default of zero if the socket could not be determined.
* -1 if returned is the dev_id value is out of range.
*/
-__rte_experimental
int
rte_compressdev_socket_id(uint8_t dev_id);
@@ -221,7 +210,6 @@ struct rte_compressdev_config {
* - 0: Success, device configured.
* - <0: Error code returned by the driver configuration function.
*/
-__rte_experimental
int
rte_compressdev_configure(uint8_t dev_id,
struct rte_compressdev_config *config);
@@ -240,7 +228,6 @@ rte_compressdev_configure(uint8_t dev_id,
* - 0: Success, device started.
* - <0: Error code of the driver device start function.
*/
-__rte_experimental
int
rte_compressdev_start(uint8_t dev_id);
@@ -251,7 +238,6 @@ rte_compressdev_start(uint8_t dev_id);
* @param dev_id
* Compress device identifier
*/
-__rte_experimental
void
rte_compressdev_stop(uint8_t dev_id);
@@ -269,7 +255,6 @@ rte_compressdev_stop(uint8_t dev_id);
* - 0 on successfully closing device
* - <0 on failure to close device
*/
-__rte_experimental
int
rte_compressdev_close(uint8_t dev_id);
@@ -296,7 +281,6 @@ rte_compressdev_close(uint8_t dev_id);
* - 0: Success, queue pair correctly set up.
* - <0: Queue pair configuration failed
*/
-__rte_experimental
int
rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
uint32_t max_inflight_ops, int socket_id);
@@ -309,7 +293,6 @@ rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
* @return
* - The number of configured queue pairs.
*/
-__rte_experimental
uint16_t
rte_compressdev_queue_pair_count(uint8_t dev_id);
@@ -327,7 +310,6 @@ rte_compressdev_queue_pair_count(uint8_t dev_id);
* - Zero if successful.
* - Non-zero otherwise.
*/
-__rte_experimental
int
rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
@@ -337,7 +319,6 @@ rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
* @param dev_id
* The identifier of the device.
*/
-__rte_experimental
void
rte_compressdev_stats_reset(uint8_t dev_id);
@@ -355,7 +336,6 @@ rte_compressdev_stats_reset(uint8_t dev_id);
* The element after the last valid element has it's op field set to
* RTE_COMP_ALGO_UNSPECIFIED.
*/
-__rte_experimental
void
rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
@@ -413,7 +393,6 @@ rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
* of pointers to *rte_comp_op* structures effectively supplied to the
* *ops* array.
*/
-__rte_experimental
uint16_t
rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -468,7 +447,6 @@ rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
* comp devices queue is full or if invalid parameters are specified in
* a *rte_comp_op*.
*/
-__rte_experimental
uint16_t
rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -496,7 +474,6 @@ rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private stream could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_stream_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -518,7 +495,6 @@ rte_compressdev_stream_create(uint8_t dev_id,
* - Returns -ENOTSUP if comp device does not support STATEFUL operations.
* - Returns -EBUSY if can't free stream as there are inflight operations
*/
-__rte_experimental
int
rte_compressdev_stream_free(uint8_t dev_id, void *stream);
@@ -545,7 +521,6 @@ rte_compressdev_stream_free(uint8_t dev_id, void *stream);
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private_xform could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_private_xform_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -567,7 +542,6 @@ rte_compressdev_private_xform_create(uint8_t dev_id,
* - <0 in error cases
* - Returns -EINVAL if input parameters are invalid.
*/
-__rte_experimental
int
rte_compressdev_private_xform_free(uint8_t dev_id, void *private_xform);
diff --git a/lib/compressdev/rte_compressdev_pmd.h b/lib/compressdev/rte_compressdev_pmd.h
index ea012908b783..fa233492fe1f 100644
--- a/lib/compressdev/rte_compressdev_pmd.h
+++ b/lib/compressdev/rte_compressdev_pmd.h
@@ -59,7 +59,6 @@ struct rte_compressdev_global {
* @return
* - The rte_compressdev structure pointer for the given device identifier.
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_get_named_dev(const char *name);
@@ -292,7 +291,6 @@ struct rte_compressdev_ops {
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_allocate(const char *name, int socket_id);
@@ -308,7 +306,6 @@ rte_compressdev_pmd_allocate(const char *name, int socket_id);
* @return
* - 0 on success, negative on error
*/
-__rte_experimental
int
rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
@@ -331,7 +328,6 @@ rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_parse_input_args(
struct rte_compressdev_pmd_init_params *params,
@@ -353,7 +349,6 @@ rte_compressdev_pmd_parse_input_args(
* - comp device instance on success
* - NULL on creation failure
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_create(const char *name,
struct rte_device *device,
@@ -372,7 +367,6 @@ rte_compressdev_pmd_create(const char *name,
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_destroy(struct rte_compressdev *dev);
diff --git a/lib/compressdev/version.map b/lib/compressdev/version.map
index e2a108b6509f..fa891f669b5d 100644
--- a/lib/compressdev/version.map
+++ b/lib/compressdev/version.map
@@ -1,4 +1,4 @@
-EXPERIMENTAL {
+DPDK_24 {
global:
rte_compressdev_capability_get;
--
2.39.2
^ permalink raw reply [relevance 2%]
* [PATCH v4 00/28] Promote many experimental API's to stable
2023-10-19 16:55 3% ` [PATCH v3 00/29] Promote experimental " Stephen Hemminger
@ 2023-10-19 19:09 3% ` Stephen Hemminger
2023-10-19 19:10 2% ` [PATCH v4 24/28] compressdev: remove experimental flag Stephen Hemminger
2023-10-20 20:57 3% ` [PATCH v5 00/26] Promote many experimental API's to stable Stephen Hemminger
` (3 subsequent siblings)
6 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-10-19 19:09 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Since 23.11 is an LTS release it is time to remove the experimental
bandaid off many API's. There are about 890 API's marked with experimental
on current main branch. This addresses the easy to remove ones and
gets it down to about 510 places.
The rule is any API that has been in since 22.11 needs to have
experimental removed (or have API deleted). The experimental flag is not a
"get out of ABI stability for free" card
v4 - fix build in security and squash one fixup
v3 - rebase and skip cryptodev
Stephen Hemminger (28):
bpf: make rte_bpf_dump and rte_bpf_convert stable API's
cmdline: make experimental API's stable
ethdev: mark rte_mtr API's as stable
ethdev: mark rte_tm API's as stable
pdump: make API's stable
pcapng: mark API's as stable
net: remove experimental from functions
rcu: remove experimental from rte_rcu_qbsr
lpm: remove experimental
mbuf: remove experimental from create_extbuf
hash: remove experimental from toeplitz hash
timer: remove experimental from rte_timer_next_ticks
sched: remove experimental
dmadev: mark API's as not experimental
meter: remove experimental warning from comments
power: remove experimental from API's
kvargs: remove experimental flag
ip_frag: mark a couple of functions stable
member: remove experimental tag
security: remove experimental flag from macsec
vhost: remove experimental from some API's
bbdev: remove experimental tag
ipsec: remove experimental from SA API
compressdev: remove experimental flag
regexdev: remove experimental tag
node: remove some of the experimental tags
table: remove experimental from API
port: make API's stable
MAINTAINERS | 10 +-
doc/guides/rel_notes/deprecation.rst | 6 --
lib/bbdev/rte_bbdev.h | 4 -
lib/bbdev/rte_bbdev_op.h | 2 -
lib/bbdev/version.map | 15 ++-
lib/bpf/rte_bpf.h | 2 -
lib/bpf/version.map | 9 +-
lib/cmdline/cmdline.h | 1 -
lib/cmdline/cmdline_parse.h | 4 -
lib/cmdline/cmdline_rdline.h | 4 -
lib/cmdline/version.map | 26 ++---
lib/compressdev/rte_comp.h | 6 --
lib/compressdev/rte_compressdev.h | 26 -----
lib/compressdev/rte_compressdev_pmd.h | 6 --
lib/compressdev/version.map | 2 +-
lib/dmadev/rte_dmadev.h | 85 ----------------
lib/dmadev/version.map | 2 +-
lib/ethdev/rte_mtr.h | 25 +----
lib/ethdev/rte_tm.h | 34 -------
lib/ethdev/version.map | 88 ++++++++--------
lib/hash/rte_thash.h | 44 --------
lib/hash/rte_thash_gfni.h | 8 --
lib/hash/rte_thash_x86_gfni.h | 8 --
lib/hash/version.map | 16 +--
lib/ip_frag/rte_ip_frag.h | 2 -
lib/ip_frag/version.map | 9 +-
lib/ipsec/rte_ipsec.h | 2 -
lib/ipsec/version.map | 9 +-
lib/kvargs/rte_kvargs.h | 4 -
lib/kvargs/version.map | 8 +-
lib/lpm/rte_lpm.h | 4 -
lib/lpm/version.map | 7 +-
lib/mbuf/rte_mbuf.h | 1 -
lib/mbuf/version.map | 8 +-
lib/member/rte_member.h | 54 ----------
lib/member/version.map | 12 +--
lib/meter/rte_meter.h | 12 ---
lib/net/rte_ip.h | 19 ----
lib/node/rte_node_eth_api.h | 1 -
lib/node/rte_node_ip4_api.h | 2 -
lib/node/version.map | 16 ++-
lib/pcapng/rte_pcapng.h | 11 --
lib/pcapng/version.map | 6 +-
lib/pdump/rte_pdump.h | 12 ---
lib/pdump/version.map | 11 +-
lib/pipeline/rte_port_in_action.h | 8 --
lib/pipeline/rte_swx_ctl.h | 57 -----------
lib/pipeline/rte_swx_pipeline.h | 29 ------
lib/pipeline/rte_table_action.h | 16 ---
lib/pipeline/version.map | 140 ++++++++++++--------------
lib/port/version.map | 24 ++---
lib/power/rte_power.h | 4 -
lib/power/rte_power_guest_channel.h | 4 -
lib/power/rte_power_pmd_mgmt.h | 40 --------
lib/power/rte_power_uncore.h | 5 -
lib/power/version.map | 40 +++-----
lib/rcu/rte_rcu_qsbr.h | 20 ----
lib/rcu/version.map | 15 +--
lib/regexdev/rte_regexdev.h | 92 -----------------
lib/regexdev/version.map | 2 +-
lib/sched/rte_pie.h | 8 --
lib/sched/rte_sched.h | 5 -
lib/sched/version.map | 18 +---
lib/security/rte_security.h | 27 -----
lib/security/version.map | 18 ++--
lib/table/rte_swx_table_learner.h | 10 --
lib/table/rte_swx_table_selector.h | 6 --
lib/table/rte_table_hash_func.h | 9 --
lib/table/version.map | 18 +---
lib/timer/rte_timer.h | 4 -
lib/timer/version.map | 7 +-
lib/vhost/rte_vhost.h | 5 -
lib/vhost/rte_vhost_async.h | 19 ----
lib/vhost/rte_vhost_crypto.h | 1 -
lib/vhost/version.map | 51 ++++------
75 files changed, 219 insertions(+), 1126 deletions(-)
--
2.39.2
^ permalink raw reply [relevance 3%]
* [PATCH v4 24/28] compressdev: remove experimental flag
2023-10-19 19:09 3% ` [PATCH v4 00/28] Promote many experimental API's to stable Stephen Hemminger
@ 2023-10-19 19:10 2% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-19 19:10 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Thomas Monjalon, Fan Zhang, Ashish Gupta
The compressdev can not hide under the experimental flag.
Remove the experimental flag and require ABI to be stable.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
MAINTAINERS | 2 +-
lib/compressdev/rte_comp.h | 6 ------
lib/compressdev/rte_compressdev.h | 26 --------------------------
lib/compressdev/rte_compressdev_pmd.h | 6 ------
lib/compressdev/version.map | 2 +-
5 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1534a414f754..a1d4d57107a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -459,7 +459,7 @@ F: lib/security/
F: doc/guides/prog_guide/rte_security.rst
F: app/test/test_security*
-Compression API - EXPERIMENTAL
+Compression API
M: Fan Zhang <fanzhang.oss@gmail.com>
M: Ashish Gupta <ashish.gupta@marvell.com>
T: git://dpdk.org/next/dpdk-next-crypto
diff --git a/lib/compressdev/rte_comp.h b/lib/compressdev/rte_comp.h
index bf896d07223c..232564cf5e9a 100644
--- a/lib/compressdev/rte_comp.h
+++ b/lib/compressdev/rte_comp.h
@@ -499,7 +499,6 @@ struct rte_comp_op {
* - On success pointer to mempool
* - On failure NULL
*/
-__rte_experimental
struct rte_mempool *
rte_comp_op_pool_create(const char *name,
unsigned int nb_elts, unsigned int cache_size,
@@ -515,7 +514,6 @@ rte_comp_op_pool_create(const char *name,
* - On success returns a valid rte_comp_op structure
* - On failure returns NULL
*/
-__rte_experimental
struct rte_comp_op *
rte_comp_op_alloc(struct rte_mempool *mempool);
@@ -532,7 +530,6 @@ rte_comp_op_alloc(struct rte_mempool *mempool);
* - nb_ops: Success, the nb_ops requested was allocated
* - 0: Not enough entries in the mempool; no ops are retrieved.
*/
-__rte_experimental
int
rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -546,7 +543,6 @@ rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
* Compress operation pointer allocated from rte_comp_op_alloc()
* If op is NULL, no operation is performed.
*/
-__rte_experimental
void
rte_comp_op_free(struct rte_comp_op *op);
@@ -561,7 +557,6 @@ rte_comp_op_free(struct rte_comp_op *op);
* @param nb_ops
* Number of operations to free
*/
-__rte_experimental
void
rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
@@ -574,7 +569,6 @@ rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_comp_get_feature_name(uint64_t flag);
diff --git a/lib/compressdev/rte_compressdev.h b/lib/compressdev/rte_compressdev.h
index 13a418631893..8cb5db0e3f7d 100644
--- a/lib/compressdev/rte_compressdev.h
+++ b/lib/compressdev/rte_compressdev.h
@@ -10,10 +10,6 @@
*
* RTE Compression Device APIs.
*
- * @warning
- * @b EXPERIMENTAL:
- * All functions in this file may be changed or removed without prior notice.
- *
* Defines comp device APIs for the provisioning of compression operations.
*/
@@ -54,7 +50,6 @@ struct rte_compressdev_capabilities {
#define RTE_COMP_END_OF_CAPABILITIES_LIST() \
{ RTE_COMP_ALGO_UNSPECIFIED }
-__rte_experimental
const struct rte_compressdev_capabilities *
rte_compressdev_capability_get(uint8_t dev_id,
enum rte_comp_algorithm algo);
@@ -94,7 +89,6 @@ rte_compressdev_capability_get(uint8_t dev_id,
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_compressdev_get_feature_name(uint64_t flag);
@@ -133,7 +127,6 @@ struct rte_compressdev_stats {
* - Returns compress device identifier on success.
* - Return -1 on failure to find named compress device.
*/
-__rte_experimental
int
rte_compressdev_get_dev_id(const char *name);
@@ -146,7 +139,6 @@ rte_compressdev_get_dev_id(const char *name);
* - Returns compress device name.
* - Returns NULL if compress device is not present.
*/
-__rte_experimental
const char *
rte_compressdev_name_get(uint8_t dev_id);
@@ -157,7 +149,6 @@ rte_compressdev_name_get(uint8_t dev_id);
* @return
* - The total number of usable compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_count(void);
@@ -175,7 +166,6 @@ rte_compressdev_count(void);
* @return
* Returns number of attached compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
uint8_t nb_devices);
@@ -190,7 +180,6 @@ rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
* a default of zero if the socket could not be determined.
* -1 if returned is the dev_id value is out of range.
*/
-__rte_experimental
int
rte_compressdev_socket_id(uint8_t dev_id);
@@ -221,7 +210,6 @@ struct rte_compressdev_config {
* - 0: Success, device configured.
* - <0: Error code returned by the driver configuration function.
*/
-__rte_experimental
int
rte_compressdev_configure(uint8_t dev_id,
struct rte_compressdev_config *config);
@@ -240,7 +228,6 @@ rte_compressdev_configure(uint8_t dev_id,
* - 0: Success, device started.
* - <0: Error code of the driver device start function.
*/
-__rte_experimental
int
rte_compressdev_start(uint8_t dev_id);
@@ -251,7 +238,6 @@ rte_compressdev_start(uint8_t dev_id);
* @param dev_id
* Compress device identifier
*/
-__rte_experimental
void
rte_compressdev_stop(uint8_t dev_id);
@@ -269,7 +255,6 @@ rte_compressdev_stop(uint8_t dev_id);
* - 0 on successfully closing device
* - <0 on failure to close device
*/
-__rte_experimental
int
rte_compressdev_close(uint8_t dev_id);
@@ -296,7 +281,6 @@ rte_compressdev_close(uint8_t dev_id);
* - 0: Success, queue pair correctly set up.
* - <0: Queue pair configuration failed
*/
-__rte_experimental
int
rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
uint32_t max_inflight_ops, int socket_id);
@@ -309,7 +293,6 @@ rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
* @return
* - The number of configured queue pairs.
*/
-__rte_experimental
uint16_t
rte_compressdev_queue_pair_count(uint8_t dev_id);
@@ -327,7 +310,6 @@ rte_compressdev_queue_pair_count(uint8_t dev_id);
* - Zero if successful.
* - Non-zero otherwise.
*/
-__rte_experimental
int
rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
@@ -337,7 +319,6 @@ rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
* @param dev_id
* The identifier of the device.
*/
-__rte_experimental
void
rte_compressdev_stats_reset(uint8_t dev_id);
@@ -355,7 +336,6 @@ rte_compressdev_stats_reset(uint8_t dev_id);
* The element after the last valid element has it's op field set to
* RTE_COMP_ALGO_UNSPECIFIED.
*/
-__rte_experimental
void
rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
@@ -413,7 +393,6 @@ rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
* of pointers to *rte_comp_op* structures effectively supplied to the
* *ops* array.
*/
-__rte_experimental
uint16_t
rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -468,7 +447,6 @@ rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
* comp devices queue is full or if invalid parameters are specified in
* a *rte_comp_op*.
*/
-__rte_experimental
uint16_t
rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -496,7 +474,6 @@ rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private stream could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_stream_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -518,7 +495,6 @@ rte_compressdev_stream_create(uint8_t dev_id,
* - Returns -ENOTSUP if comp device does not support STATEFUL operations.
* - Returns -EBUSY if can't free stream as there are inflight operations
*/
-__rte_experimental
int
rte_compressdev_stream_free(uint8_t dev_id, void *stream);
@@ -545,7 +521,6 @@ rte_compressdev_stream_free(uint8_t dev_id, void *stream);
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private_xform could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_private_xform_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -567,7 +542,6 @@ rte_compressdev_private_xform_create(uint8_t dev_id,
* - <0 in error cases
* - Returns -EINVAL if input parameters are invalid.
*/
-__rte_experimental
int
rte_compressdev_private_xform_free(uint8_t dev_id, void *private_xform);
diff --git a/lib/compressdev/rte_compressdev_pmd.h b/lib/compressdev/rte_compressdev_pmd.h
index ea012908b783..fa233492fe1f 100644
--- a/lib/compressdev/rte_compressdev_pmd.h
+++ b/lib/compressdev/rte_compressdev_pmd.h
@@ -59,7 +59,6 @@ struct rte_compressdev_global {
* @return
* - The rte_compressdev structure pointer for the given device identifier.
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_get_named_dev(const char *name);
@@ -292,7 +291,6 @@ struct rte_compressdev_ops {
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_allocate(const char *name, int socket_id);
@@ -308,7 +306,6 @@ rte_compressdev_pmd_allocate(const char *name, int socket_id);
* @return
* - 0 on success, negative on error
*/
-__rte_experimental
int
rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
@@ -331,7 +328,6 @@ rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_parse_input_args(
struct rte_compressdev_pmd_init_params *params,
@@ -353,7 +349,6 @@ rte_compressdev_pmd_parse_input_args(
* - comp device instance on success
* - NULL on creation failure
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_create(const char *name,
struct rte_device *device,
@@ -372,7 +367,6 @@ rte_compressdev_pmd_create(const char *name,
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_destroy(struct rte_compressdev *dev);
diff --git a/lib/compressdev/version.map b/lib/compressdev/version.map
index e2a108b6509f..fa891f669b5d 100644
--- a/lib/compressdev/version.map
+++ b/lib/compressdev/version.map
@@ -1,4 +1,4 @@
-EXPERIMENTAL {
+DPDK_24 {
global:
rte_compressdev_capability_get;
--
2.39.2
^ permalink raw reply [relevance 2%]
* [PATCH] docs: add note about experimental API in LTS
@ 2023-10-20 14:19 7% Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2023-10-20 14:19 UTC (permalink / raw)
To: dev; +Cc: Kevin Traynor, David Marchand
The justification and impact for changing experimental API on LTS
branches is different from the main branch. So the policy that is
being used for allowing experimental APIs to change is stricter on
the LTS branches.
This was not documented anywhere, so add some documentation.
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
---
doc/guides/contributing/stable.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 9ee7b4b7cc..8156b72b20 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -127,4 +127,12 @@ but may be considered in some cases where:
* An existing feature in LTS is not usable as intended without it.
+APIs marked as ``experimental`` are not considered part of the ABI version
+and can be changed without prior notice. This is necessary for the API to be
+improved and stabilized and become part of the ABI version in the future.
+
+However, in LTS releases ``experimental`` API should not be changed as there
+will not be a future ABI version on the branch and compatibility with previous
+release of an LTS version is of the highest importance.
+
The Stable Mailing List
-----------------------
--
2.41.0
^ permalink raw reply [relevance 7%]
* Re: [PATCH v4] app/test: add support for skipping tests
@ 2023-10-20 15:08 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-10-20 15:08 UTC (permalink / raw)
To: Patrick Robb
Cc: Aaron Conole, David Marchand, dev, Thomas Monjalon,
Kevin Traynor, Lincoln Lavoie, stable
+stable on CC, to allow it be considered for possible backport. It's a
change to the unit test app, so not affecting any ABI or any end-user app.
On Fri, Oct 20, 2023 at 11:02:07AM -0400, Patrick Robb wrote:
> On Mon, Oct 9, 2023 at 4:03 PM Patrick Robb <[1]probb@iol.unh.edu>
> wrote:
>
> Hello,
> Yes, backporting would be ideal from a CI perspective because without
> it we can't run arm64 testing on LTS tests. But I know there are other
> considerations which also have to be weighed.
> David also has a patch[1] which should resolve the underlying issue
> which introduces the failures on the unit test we want to skip. If that
> patch is accepted, and backported, fixing our original problem with
> unit testing on our arm testbeds, that's another solution, at least for
> this specific unit test issue.
> It would still be nice to have this feature in case we need it
> otherwise.
> [1] [2]https://patches.dpdk.org/project/dpdk/patch/20230821085806.30626
> 13-4-david.marchand@redhat.com/
>
> Hi. just to close the loops on this, yes David's aforementioned patch
> did resolve the unit test failure which was preventing us from running
> fast-tests on our arm64 test beds. But, it is not (yet, at least)
> backported for LTS releases.
> Even if it were, having Bruce's patch here backported would mean the CI
> testing approach could be common across releases in situations where
> testcases have to be skipped.
> Anyways, whether it's possible or "worth it" is ultimately down to the
> community's bandwidth, but I didn't want to let the conversation lapse
> without an update, and raising what the benefits would be.
> In any case, thanks again Bruce for the rework, it's a great addition.
>
> References
>
> 1. mailto:probb@iol.unh.edu
> 2. https://patches.dpdk.org/project/dpdk/patch/20230821085806.3062613-4-david.marchand@redhat.com/
^ permalink raw reply [relevance 3%]
* [PATCH v5 00/26] Promote many experimental API's to stable
` (2 preceding siblings ...)
2023-10-19 19:09 3% ` [PATCH v4 00/28] Promote many experimental API's to stable Stephen Hemminger
@ 2023-10-20 20:57 3% ` Stephen Hemminger
2023-10-20 20:57 2% ` [PATCH v5 22/26] compressdev: remove experimental flag Stephen Hemminger
2023-10-24 2:39 3% ` [PATCH v6 00/25] Promite many experimental API's to stable Stephen Hemminger
` (2 subsequent siblings)
6 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-10-20 20:57 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Since 23.11 is an LTS release it is time to remove the experimental
bandaid off many API's. There are about 890 API's marked with experimental
on current main branch. This addresses the easy to remove ones and
gets it down to about 510 places.
The rule is any API that has been in since 22.11 needs to have
experimental removed (or have API deleted). The experimental flag is not a
"get out of ABI stability for free" card
v5 - fix missing symbol in power version map
drop mtr, vhost, port and table changes
add eventdev and cryptodev
Stephen Hemminger (26):
bpf: make rte_bpf_dump and rte_bpf_convert stable API's
cmdline: make experimental API's stable
ethdev: mark rte_tm API's as stable
pdump: make API's stable
pcapng: mark API's as stable
net: remove experimental from functions
rcu: remove experimental from rte_rcu_qbsr
lpm: remove experimental
mbuf: remove experimental from create_extbuf
hash: remove experimental from toeplitz hash
timer: remove experimental from rte_timer_next_ticks
sched: remove experimental
dmadev: mark API's as not experimental
meter: remove experimental warning from comments
power: remove experimental from API's
kvargs: remove experimental flag
ip_frag: mark a couple of functions stable
member: remove experimental tag
security: remove experimental flag from macsec
bbdev: remove experimental tag
ipsec: remove experimental from SA API
compressdev: remove experimental flag
regexdev: remove experimental tag
node: remove some of the experimental tags
eventdev: make many API's stable
cryptodev: mark older API's stable
MAINTAINERS | 8 +--
lib/bbdev/rte_bbdev.h | 4 --
lib/bbdev/rte_bbdev_op.h | 2 -
lib/bbdev/version.map | 15 ++--
lib/bpf/rte_bpf.h | 2 -
lib/bpf/version.map | 9 +--
lib/cmdline/cmdline.h | 1 -
lib/cmdline/cmdline_parse.h | 4 --
lib/cmdline/cmdline_rdline.h | 4 --
lib/cmdline/version.map | 26 +++----
lib/compressdev/rte_comp.h | 6 --
lib/compressdev/rte_compressdev.h | 26 -------
lib/compressdev/rte_compressdev_pmd.h | 6 --
lib/compressdev/version.map | 2 +-
lib/cryptodev/rte_cryptodev.h | 31 ---------
lib/cryptodev/version.map | 77 +++++++++------------
lib/dmadev/rte_dmadev.h | 85 -----------------------
lib/dmadev/version.map | 2 +-
lib/ethdev/rte_tm.h | 34 ---------
lib/ethdev/version.map | 62 ++++++++---------
lib/eventdev/rte_event_crypto_adapter.h | 4 --
lib/eventdev/rte_event_eth_rx_adapter.h | 6 --
lib/eventdev/rte_event_eth_tx_adapter.h | 3 -
lib/eventdev/rte_event_timer_adapter.h | 3 -
lib/eventdev/rte_eventdev.h | 4 --
lib/eventdev/version.map | 34 ++++-----
lib/hash/rte_thash.h | 44 ------------
lib/hash/rte_thash_gfni.h | 8 ---
lib/hash/rte_thash_x86_gfni.h | 8 ---
lib/hash/version.map | 16 ++---
lib/ip_frag/rte_ip_frag.h | 2 -
lib/ip_frag/version.map | 9 +--
lib/ipsec/rte_ipsec.h | 2 -
lib/ipsec/version.map | 9 +--
lib/kvargs/rte_kvargs.h | 4 --
lib/kvargs/version.map | 8 +--
lib/lpm/rte_lpm.h | 4 --
lib/lpm/version.map | 7 +-
lib/mbuf/rte_mbuf.h | 1 -
lib/mbuf/version.map | 8 +--
lib/member/rte_member.h | 54 ---------------
lib/member/version.map | 12 +---
lib/meter/rte_meter.h | 12 ----
lib/net/rte_ip.h | 19 -----
lib/node/rte_node_eth_api.h | 1 -
lib/node/rte_node_ip4_api.h | 2 -
lib/node/version.map | 16 +++--
lib/pcapng/rte_pcapng.h | 11 ---
lib/pcapng/version.map | 6 +-
lib/pdump/rte_pdump.h | 12 ----
lib/pdump/version.map | 11 +--
lib/power/rte_power.h | 4 --
lib/power/rte_power_guest_channel.h | 4 --
lib/power/rte_power_pmd_mgmt.h | 40 -----------
lib/power/rte_power_uncore.h | 5 --
lib/power/version.map | 41 ++++-------
lib/rcu/rte_rcu_qsbr.h | 20 ------
lib/rcu/version.map | 15 ++--
lib/regexdev/rte_regexdev.h | 92 -------------------------
lib/regexdev/version.map | 2 +-
lib/sched/rte_pie.h | 8 ---
lib/sched/rte_sched.h | 5 --
lib/sched/version.map | 18 ++---
lib/security/rte_security.h | 27 --------
lib/security/version.map | 18 ++---
lib/timer/rte_timer.h | 4 --
lib/timer/version.map | 7 +-
67 files changed, 161 insertions(+), 895 deletions(-)
--
2.39.2
^ permalink raw reply [relevance 3%]
* [PATCH v5 22/26] compressdev: remove experimental flag
2023-10-20 20:57 3% ` [PATCH v5 00/26] Promote many experimental API's to stable Stephen Hemminger
@ 2023-10-20 20:57 2% ` Stephen Hemminger
2023-10-23 9:12 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-10-20 20:57 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Thomas Monjalon, Fan Zhang, Ashish Gupta
The compressdev can not hide under the experimental flag.
Remove the experimental flag and require ABI to be stable.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
MAINTAINERS | 2 +-
lib/compressdev/rte_comp.h | 6 ------
lib/compressdev/rte_compressdev.h | 26 --------------------------
lib/compressdev/rte_compressdev_pmd.h | 6 ------
lib/compressdev/version.map | 2 +-
5 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f1ab5a0f328..789507ddccb7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -459,7 +459,7 @@ F: lib/security/
F: doc/guides/prog_guide/rte_security.rst
F: app/test/test_security*
-Compression API - EXPERIMENTAL
+Compression API
M: Fan Zhang <fanzhang.oss@gmail.com>
M: Ashish Gupta <ashish.gupta@marvell.com>
T: git://dpdk.org/next/dpdk-next-crypto
diff --git a/lib/compressdev/rte_comp.h b/lib/compressdev/rte_comp.h
index bf896d07223c..232564cf5e9a 100644
--- a/lib/compressdev/rte_comp.h
+++ b/lib/compressdev/rte_comp.h
@@ -499,7 +499,6 @@ struct rte_comp_op {
* - On success pointer to mempool
* - On failure NULL
*/
-__rte_experimental
struct rte_mempool *
rte_comp_op_pool_create(const char *name,
unsigned int nb_elts, unsigned int cache_size,
@@ -515,7 +514,6 @@ rte_comp_op_pool_create(const char *name,
* - On success returns a valid rte_comp_op structure
* - On failure returns NULL
*/
-__rte_experimental
struct rte_comp_op *
rte_comp_op_alloc(struct rte_mempool *mempool);
@@ -532,7 +530,6 @@ rte_comp_op_alloc(struct rte_mempool *mempool);
* - nb_ops: Success, the nb_ops requested was allocated
* - 0: Not enough entries in the mempool; no ops are retrieved.
*/
-__rte_experimental
int
rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -546,7 +543,6 @@ rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
* Compress operation pointer allocated from rte_comp_op_alloc()
* If op is NULL, no operation is performed.
*/
-__rte_experimental
void
rte_comp_op_free(struct rte_comp_op *op);
@@ -561,7 +557,6 @@ rte_comp_op_free(struct rte_comp_op *op);
* @param nb_ops
* Number of operations to free
*/
-__rte_experimental
void
rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
@@ -574,7 +569,6 @@ rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_comp_get_feature_name(uint64_t flag);
diff --git a/lib/compressdev/rte_compressdev.h b/lib/compressdev/rte_compressdev.h
index 13a418631893..8cb5db0e3f7d 100644
--- a/lib/compressdev/rte_compressdev.h
+++ b/lib/compressdev/rte_compressdev.h
@@ -10,10 +10,6 @@
*
* RTE Compression Device APIs.
*
- * @warning
- * @b EXPERIMENTAL:
- * All functions in this file may be changed or removed without prior notice.
- *
* Defines comp device APIs for the provisioning of compression operations.
*/
@@ -54,7 +50,6 @@ struct rte_compressdev_capabilities {
#define RTE_COMP_END_OF_CAPABILITIES_LIST() \
{ RTE_COMP_ALGO_UNSPECIFIED }
-__rte_experimental
const struct rte_compressdev_capabilities *
rte_compressdev_capability_get(uint8_t dev_id,
enum rte_comp_algorithm algo);
@@ -94,7 +89,6 @@ rte_compressdev_capability_get(uint8_t dev_id,
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_compressdev_get_feature_name(uint64_t flag);
@@ -133,7 +127,6 @@ struct rte_compressdev_stats {
* - Returns compress device identifier on success.
* - Return -1 on failure to find named compress device.
*/
-__rte_experimental
int
rte_compressdev_get_dev_id(const char *name);
@@ -146,7 +139,6 @@ rte_compressdev_get_dev_id(const char *name);
* - Returns compress device name.
* - Returns NULL if compress device is not present.
*/
-__rte_experimental
const char *
rte_compressdev_name_get(uint8_t dev_id);
@@ -157,7 +149,6 @@ rte_compressdev_name_get(uint8_t dev_id);
* @return
* - The total number of usable compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_count(void);
@@ -175,7 +166,6 @@ rte_compressdev_count(void);
* @return
* Returns number of attached compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
uint8_t nb_devices);
@@ -190,7 +180,6 @@ rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
* a default of zero if the socket could not be determined.
* -1 if returned is the dev_id value is out of range.
*/
-__rte_experimental
int
rte_compressdev_socket_id(uint8_t dev_id);
@@ -221,7 +210,6 @@ struct rte_compressdev_config {
* - 0: Success, device configured.
* - <0: Error code returned by the driver configuration function.
*/
-__rte_experimental
int
rte_compressdev_configure(uint8_t dev_id,
struct rte_compressdev_config *config);
@@ -240,7 +228,6 @@ rte_compressdev_configure(uint8_t dev_id,
* - 0: Success, device started.
* - <0: Error code of the driver device start function.
*/
-__rte_experimental
int
rte_compressdev_start(uint8_t dev_id);
@@ -251,7 +238,6 @@ rte_compressdev_start(uint8_t dev_id);
* @param dev_id
* Compress device identifier
*/
-__rte_experimental
void
rte_compressdev_stop(uint8_t dev_id);
@@ -269,7 +255,6 @@ rte_compressdev_stop(uint8_t dev_id);
* - 0 on successfully closing device
* - <0 on failure to close device
*/
-__rte_experimental
int
rte_compressdev_close(uint8_t dev_id);
@@ -296,7 +281,6 @@ rte_compressdev_close(uint8_t dev_id);
* - 0: Success, queue pair correctly set up.
* - <0: Queue pair configuration failed
*/
-__rte_experimental
int
rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
uint32_t max_inflight_ops, int socket_id);
@@ -309,7 +293,6 @@ rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
* @return
* - The number of configured queue pairs.
*/
-__rte_experimental
uint16_t
rte_compressdev_queue_pair_count(uint8_t dev_id);
@@ -327,7 +310,6 @@ rte_compressdev_queue_pair_count(uint8_t dev_id);
* - Zero if successful.
* - Non-zero otherwise.
*/
-__rte_experimental
int
rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
@@ -337,7 +319,6 @@ rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
* @param dev_id
* The identifier of the device.
*/
-__rte_experimental
void
rte_compressdev_stats_reset(uint8_t dev_id);
@@ -355,7 +336,6 @@ rte_compressdev_stats_reset(uint8_t dev_id);
* The element after the last valid element has it's op field set to
* RTE_COMP_ALGO_UNSPECIFIED.
*/
-__rte_experimental
void
rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
@@ -413,7 +393,6 @@ rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
* of pointers to *rte_comp_op* structures effectively supplied to the
* *ops* array.
*/
-__rte_experimental
uint16_t
rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -468,7 +447,6 @@ rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
* comp devices queue is full or if invalid parameters are specified in
* a *rte_comp_op*.
*/
-__rte_experimental
uint16_t
rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -496,7 +474,6 @@ rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private stream could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_stream_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -518,7 +495,6 @@ rte_compressdev_stream_create(uint8_t dev_id,
* - Returns -ENOTSUP if comp device does not support STATEFUL operations.
* - Returns -EBUSY if can't free stream as there are inflight operations
*/
-__rte_experimental
int
rte_compressdev_stream_free(uint8_t dev_id, void *stream);
@@ -545,7 +521,6 @@ rte_compressdev_stream_free(uint8_t dev_id, void *stream);
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private_xform could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_private_xform_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -567,7 +542,6 @@ rte_compressdev_private_xform_create(uint8_t dev_id,
* - <0 in error cases
* - Returns -EINVAL if input parameters are invalid.
*/
-__rte_experimental
int
rte_compressdev_private_xform_free(uint8_t dev_id, void *private_xform);
diff --git a/lib/compressdev/rte_compressdev_pmd.h b/lib/compressdev/rte_compressdev_pmd.h
index ea012908b783..fa233492fe1f 100644
--- a/lib/compressdev/rte_compressdev_pmd.h
+++ b/lib/compressdev/rte_compressdev_pmd.h
@@ -59,7 +59,6 @@ struct rte_compressdev_global {
* @return
* - The rte_compressdev structure pointer for the given device identifier.
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_get_named_dev(const char *name);
@@ -292,7 +291,6 @@ struct rte_compressdev_ops {
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_allocate(const char *name, int socket_id);
@@ -308,7 +306,6 @@ rte_compressdev_pmd_allocate(const char *name, int socket_id);
* @return
* - 0 on success, negative on error
*/
-__rte_experimental
int
rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
@@ -331,7 +328,6 @@ rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_parse_input_args(
struct rte_compressdev_pmd_init_params *params,
@@ -353,7 +349,6 @@ rte_compressdev_pmd_parse_input_args(
* - comp device instance on success
* - NULL on creation failure
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_create(const char *name,
struct rte_device *device,
@@ -372,7 +367,6 @@ rte_compressdev_pmd_create(const char *name,
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_destroy(struct rte_compressdev *dev);
diff --git a/lib/compressdev/version.map b/lib/compressdev/version.map
index e2a108b6509f..fa891f669b5d 100644
--- a/lib/compressdev/version.map
+++ b/lib/compressdev/version.map
@@ -1,4 +1,4 @@
-EXPERIMENTAL {
+DPDK_24 {
global:
rte_compressdev_capability_get;
--
2.39.2
^ permalink raw reply [relevance 2%]
* Re: [PATCH v8 0/3] Split logging functionality out of EAL
@ 2023-10-23 7:37 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-10-23 7:37 UTC (permalink / raw)
To: Bruce Richardson, Thomas Monjalon; +Cc: dev, Morten Brørup
On Fri, Aug 11, 2023 at 2:46 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Wed, Aug 9, 2023 at 3:36 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > There is a general desire to reduce the size and scope of EAL. To this
> > end, this patchset makes a (very) small step in that direction by taking
> > the logging functionality out of EAL and putting it into its own library
> > that can be built and maintained separately.
> >
> > As with the first RFC for this, the main obstacle is the "fnmatch"
> > function which is needed by both EAL and the new log function when
> > building on windows. While the function cannot stay in EAL - or we would
> > have a circular dependency, moving it to a new library or just putting
> > it in the log library have the disadvantages that it then "leaks" into
> > the public namespace without an rte_prefix, which could cause issues.
> > Since only a single function is involved, subsequent versions take a
> > different approach to v1, and just moves the offending function to be a
> > static function in a header file. This allows use by multiple libs
> > without conflicting names or making it public.
> >
> > The other complication, as explained in v1 RFC was that of multiple
> > implementations for different OS's. This is solved here in the same
> > way as v1, by including the OS in the name and having meson pick the
> > correct file for each build. Since only one file is involved, there
> > seemed little need for replicating EAL's separate subdirectories
> > per-OS.
>
> Series applied, thanks Bruce for this first step.
>
> As mentionned during the maintainers weekly call yesterday, this is
> only a first "easy" step but, thinking of next steps, more splitting
> may not be that easy.
>
> At least, on the libabigail topic, as we need the ABI check to handle
> libraries splits, a new feature has been cooked in (not yet released)
> 2.4 libabigail.
> https://sourceware.org/git/?p=libabigail.git;a=commitdiff;h=0b338dfaf690993e123b6433201b3a8b8204d662
> Hopefully, we will have a libabigail release available by the time we
> start the v24.03 release (and re-enable ABI checks).
For the record, libabigail 2.4 got released last Friday.
I had already prepared a patch to use this new feature, I can send it
when needed.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 22/26] compressdev: remove experimental flag
2023-10-20 20:57 2% ` [PATCH v5 22/26] compressdev: remove experimental flag Stephen Hemminger
@ 2023-10-23 9:12 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-10-23 9:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Thomas Monjalon, Fan Zhang, Ashish Gupta
On Fri, Oct 20, 2023 at 01:57:55PM -0700, Stephen Hemminger wrote:
> The compressdev can not hide under the experimental flag.
> Remove the experimental flag and require ABI to be stable.
>
Not sure about the wording of the commit log. Better to just point out that
compressdev was added back in 2018, and, as such, should now be a stable
API.
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 0%]
* [PATCH v6 00/25] Promite many experimental API's to stable
` (3 preceding siblings ...)
2023-10-20 20:57 3% ` [PATCH v5 00/26] Promote many experimental API's to stable Stephen Hemminger
@ 2023-10-24 2:39 3% ` Stephen Hemminger
2023-10-24 2:53 3% ` [PATCH v7 00/25] Promote 22.11 and older " Stephen Hemminger
2023-10-24 7:20 0% ` [PATCH 00/20] remove experimental flag from some API's Maxime Coquelin
6 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-24 2:39 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Since 23.11 is an LTS release it is time to remove the experimental
bandaid off many API's. There are about 890 API's marked with experimental
on current main branch. This addresses the easy to remove ones and
gets it down to about 510 places.
The rule is any API that has been in since 22.11 needs to have
experimental removed (or have API deleted). The experimental flag is not a
"get out of ABI stability for free" card
v6 - incorporate review comments
drop regexdev
Stephen Hemminger (25):
bpf: make rte_bpf_dump and rte_bpf_convert stable API's
cmdline: make experimental API's stable
ethdev: mark rte_tm API's as stable
pdump: make API's stable
pcapng: mark API's as stable
net: remove experimental from functions
rcu: remove experimental from rte_rcu_qbsr
lpm: remove experimental
mbuf: remove experimental from create_extbuf
hash: remove experimental from toeplitz hash
timer: remove experimental from rte_timer_next_ticks
sched: remove experimental
dmadev: mark API's as not experimental
meter: remove experimental warning from comments
power: remove experimental from API's
kvargs: remove experimental flag
ip_frag: mark a couple of functions stable
member: remove experimental tag
security: remove experimental flag
bbdev: remove experimental tag
ipsec: remove experimental from SA API
compressdev: remove experimental flag
node: remove some of the experimental tags
eventdev: make many API's stable
cryptodev: mark older API's stable
MAINTAINERS | 8 +--
lib/bbdev/rte_bbdev.h | 4 --
lib/bbdev/rte_bbdev_op.h | 2 -
lib/bbdev/version.map | 15 ++---
lib/bpf/rte_bpf.h | 2 -
lib/bpf/version.map | 9 +--
lib/cmdline/cmdline.h | 1 -
lib/cmdline/cmdline_parse.h | 4 --
lib/cmdline/cmdline_rdline.h | 4 --
lib/cmdline/version.map | 26 +++-----
lib/compressdev/rte_comp.h | 6 --
lib/compressdev/rte_compressdev.h | 26 --------
lib/compressdev/rte_compressdev_pmd.h | 6 --
lib/compressdev/version.map | 2 +-
lib/cryptodev/rte_cryptodev.h | 31 ---------
lib/cryptodev/version.map | 77 ++++++++++------------
lib/dmadev/rte_dmadev.h | 85 -------------------------
lib/dmadev/version.map | 2 +-
lib/ethdev/rte_tm.h | 34 ----------
lib/ethdev/version.map | 62 +++++++++---------
lib/eventdev/rte_event_crypto_adapter.h | 4 --
lib/eventdev/rte_event_eth_rx_adapter.h | 6 --
lib/eventdev/rte_event_eth_tx_adapter.h | 3 -
lib/eventdev/rte_event_timer_adapter.h | 3 -
lib/eventdev/rte_eventdev.h | 4 --
lib/eventdev/version.map | 34 ++++------
lib/hash/rte_thash.h | 44 -------------
lib/hash/rte_thash_gfni.h | 8 ---
lib/hash/rte_thash_x86_gfni.h | 8 ---
lib/hash/version.map | 16 ++---
lib/ip_frag/rte_ip_frag.h | 2 -
lib/ip_frag/version.map | 9 +--
lib/ipsec/rte_ipsec.h | 2 -
lib/ipsec/version.map | 9 +--
lib/kvargs/rte_kvargs.h | 4 --
lib/kvargs/version.map | 8 +--
lib/lpm/rte_lpm.h | 4 --
lib/lpm/version.map | 7 +-
lib/mbuf/rte_mbuf.h | 1 -
lib/mbuf/version.map | 8 +--
lib/member/rte_member.h | 54 ----------------
lib/member/version.map | 12 +---
lib/meter/rte_meter.h | 12 ----
lib/net/rte_ip.h | 19 ------
lib/node/rte_node_eth_api.h | 1 -
lib/node/rte_node_ip4_api.h | 2 -
lib/node/version.map | 16 +++--
lib/pcapng/rte_pcapng.h | 11 ----
lib/pcapng/version.map | 6 +-
lib/pdump/rte_pdump.h | 12 ----
lib/pdump/version.map | 11 +---
lib/power/rte_power.h | 4 --
lib/power/rte_power_guest_channel.h | 4 --
lib/power/rte_power_pmd_mgmt.h | 40 ------------
lib/power/rte_power_uncore.h | 3 -
lib/power/version.map | 37 +++++------
lib/rcu/rte_rcu_qsbr.h | 20 ------
lib/rcu/version.map | 15 ++---
lib/sched/rte_pie.h | 8 ---
lib/sched/rte_sched.h | 5 --
lib/sched/version.map | 18 ++----
lib/security/rte_security.h | 35 ----------
lib/security/version.map | 18 +++---
lib/timer/rte_timer.h | 4 --
lib/timer/version.map | 7 +-
65 files changed, 161 insertions(+), 803 deletions(-)
--
2.39.2
^ permalink raw reply [relevance 3%]
* [PATCH v7 00/25] Promote 22.11 and older API's to stable
` (4 preceding siblings ...)
2023-10-24 2:39 3% ` [PATCH v6 00/25] Promite many experimental API's to stable Stephen Hemminger
@ 2023-10-24 2:53 3% ` Stephen Hemminger
2023-10-24 2:54 2% ` [PATCH v7 22/25] compressdev: remove experimental flag Stephen Hemminger
2023-11-13 15:45 0% ` [PATCH v7 00/25] Promote 22.11 and older API's to stable David Marchand
2023-10-24 7:20 0% ` [PATCH 00/20] remove experimental flag from some API's Maxime Coquelin
6 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2023-10-24 2:53 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Since 23.11 is an LTS release it is time to remove the experimental
bandaid off many API's. There are about 890 API's marked with experimental
on current main branch. This addresses the easy to remove ones and
gets it down to about 510 places.
The rule is any API that has been in since 22.11 needs to have
experimental removed (or have API deleted). The experimental flag is not a
"get out of ABI stability for free" card
v7 - fix missing rte_experimental dropped in lib/power
v6 - incorporate review comments
drop regexdev
Stephen Hemminger (25):
bpf: make rte_bpf_dump and rte_bpf_convert stable API's
cmdline: make experimental API's stable
ethdev: mark rte_tm API's as stable
pdump: make API's stable
pcapng: mark API's as stable
net: remove experimental from functions
rcu: remove experimental from rte_rcu_qbsr
lpm: remove experimental
mbuf: remove experimental from create_extbuf
hash: remove experimental from toeplitz hash
timer: remove experimental from rte_timer_next_ticks
sched: remove experimental
dmadev: mark API's as not experimental
meter: remove experimental warning from comments
power: remove experimental from API's
kvargs: remove experimental flag
ip_frag: mark a couple of functions stable
member: remove experimental tag
security: remove experimental flag
bbdev: remove experimental tag
ipsec: remove experimental from SA API
compressdev: remove experimental flag
node: remove some of the experimental tags
eventdev: make many API's stable
cryptodev: mark older API's stable
MAINTAINERS | 8 +--
lib/bbdev/rte_bbdev.h | 4 --
lib/bbdev/rte_bbdev_op.h | 2 -
lib/bbdev/version.map | 15 ++---
lib/bpf/rte_bpf.h | 2 -
lib/bpf/version.map | 9 +--
lib/cmdline/cmdline.h | 1 -
lib/cmdline/cmdline_parse.h | 4 --
lib/cmdline/cmdline_rdline.h | 4 --
lib/cmdline/version.map | 26 +++-----
lib/compressdev/rte_comp.h | 6 --
lib/compressdev/rte_compressdev.h | 26 --------
lib/compressdev/rte_compressdev_pmd.h | 6 --
lib/compressdev/version.map | 2 +-
lib/cryptodev/rte_cryptodev.h | 31 ---------
lib/cryptodev/version.map | 77 ++++++++++------------
lib/dmadev/rte_dmadev.h | 85 -------------------------
lib/dmadev/version.map | 2 +-
lib/ethdev/rte_tm.h | 34 ----------
lib/ethdev/version.map | 62 +++++++++---------
lib/eventdev/rte_event_crypto_adapter.h | 4 --
lib/eventdev/rte_event_eth_rx_adapter.h | 6 --
lib/eventdev/rte_event_eth_tx_adapter.h | 3 -
lib/eventdev/rte_event_timer_adapter.h | 3 -
lib/eventdev/rte_eventdev.h | 4 --
lib/eventdev/version.map | 34 ++++------
lib/hash/rte_thash.h | 44 -------------
lib/hash/rte_thash_gfni.h | 8 ---
lib/hash/rte_thash_x86_gfni.h | 8 ---
lib/hash/version.map | 16 ++---
lib/ip_frag/rte_ip_frag.h | 2 -
lib/ip_frag/version.map | 9 +--
lib/ipsec/rte_ipsec.h | 2 -
lib/ipsec/version.map | 9 +--
lib/kvargs/rte_kvargs.h | 4 --
lib/kvargs/version.map | 8 +--
lib/lpm/rte_lpm.h | 4 --
lib/lpm/version.map | 7 +-
lib/mbuf/rte_mbuf.h | 1 -
lib/mbuf/version.map | 8 +--
lib/member/rte_member.h | 54 ----------------
lib/member/version.map | 12 +---
lib/meter/rte_meter.h | 12 ----
lib/net/rte_ip.h | 19 ------
lib/node/rte_node_eth_api.h | 1 -
lib/node/rte_node_ip4_api.h | 2 -
lib/node/version.map | 16 +++--
lib/pcapng/rte_pcapng.h | 11 ----
lib/pcapng/version.map | 6 +-
lib/pdump/rte_pdump.h | 12 ----
lib/pdump/version.map | 11 +---
lib/power/rte_power.h | 4 --
lib/power/rte_power_guest_channel.h | 4 --
lib/power/rte_power_pmd_mgmt.h | 40 ------------
lib/power/rte_power_uncore.h | 2 -
lib/power/version.map | 37 +++++------
lib/rcu/rte_rcu_qsbr.h | 20 ------
lib/rcu/version.map | 15 ++---
lib/sched/rte_pie.h | 8 ---
lib/sched/rte_sched.h | 5 --
lib/sched/version.map | 18 ++----
lib/security/rte_security.h | 35 ----------
lib/security/version.map | 18 +++---
lib/timer/rte_timer.h | 4 --
lib/timer/version.map | 7 +-
65 files changed, 161 insertions(+), 802 deletions(-)
--
2.39.2
^ permalink raw reply [relevance 3%]
* [PATCH v7 22/25] compressdev: remove experimental flag
2023-10-24 2:53 3% ` [PATCH v7 00/25] Promote 22.11 and older " Stephen Hemminger
@ 2023-10-24 2:54 2% ` Stephen Hemminger
2023-11-13 15:45 0% ` [PATCH v7 00/25] Promote 22.11 and older API's to stable David Marchand
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-24 2:54 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Bruce Richardson, Thomas Monjalon, Fan Zhang,
Ashish Gupta
The compressdev was added back in 2018.
Remove the experimental flag and make ABI stable.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
MAINTAINERS | 2 +-
lib/compressdev/rte_comp.h | 6 ------
lib/compressdev/rte_compressdev.h | 26 --------------------------
lib/compressdev/rte_compressdev_pmd.h | 6 ------
lib/compressdev/version.map | 2 +-
5 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f1ab5a0f328..789507ddccb7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -459,7 +459,7 @@ F: lib/security/
F: doc/guides/prog_guide/rte_security.rst
F: app/test/test_security*
-Compression API - EXPERIMENTAL
+Compression API
M: Fan Zhang <fanzhang.oss@gmail.com>
M: Ashish Gupta <ashish.gupta@marvell.com>
T: git://dpdk.org/next/dpdk-next-crypto
diff --git a/lib/compressdev/rte_comp.h b/lib/compressdev/rte_comp.h
index bf896d07223c..232564cf5e9a 100644
--- a/lib/compressdev/rte_comp.h
+++ b/lib/compressdev/rte_comp.h
@@ -499,7 +499,6 @@ struct rte_comp_op {
* - On success pointer to mempool
* - On failure NULL
*/
-__rte_experimental
struct rte_mempool *
rte_comp_op_pool_create(const char *name,
unsigned int nb_elts, unsigned int cache_size,
@@ -515,7 +514,6 @@ rte_comp_op_pool_create(const char *name,
* - On success returns a valid rte_comp_op structure
* - On failure returns NULL
*/
-__rte_experimental
struct rte_comp_op *
rte_comp_op_alloc(struct rte_mempool *mempool);
@@ -532,7 +530,6 @@ rte_comp_op_alloc(struct rte_mempool *mempool);
* - nb_ops: Success, the nb_ops requested was allocated
* - 0: Not enough entries in the mempool; no ops are retrieved.
*/
-__rte_experimental
int
rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -546,7 +543,6 @@ rte_comp_op_bulk_alloc(struct rte_mempool *mempool,
* Compress operation pointer allocated from rte_comp_op_alloc()
* If op is NULL, no operation is performed.
*/
-__rte_experimental
void
rte_comp_op_free(struct rte_comp_op *op);
@@ -561,7 +557,6 @@ rte_comp_op_free(struct rte_comp_op *op);
* @param nb_ops
* Number of operations to free
*/
-__rte_experimental
void
rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
@@ -574,7 +569,6 @@ rte_comp_op_bulk_free(struct rte_comp_op **ops, uint16_t nb_ops);
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_comp_get_feature_name(uint64_t flag);
diff --git a/lib/compressdev/rte_compressdev.h b/lib/compressdev/rte_compressdev.h
index 13a418631893..8cb5db0e3f7d 100644
--- a/lib/compressdev/rte_compressdev.h
+++ b/lib/compressdev/rte_compressdev.h
@@ -10,10 +10,6 @@
*
* RTE Compression Device APIs.
*
- * @warning
- * @b EXPERIMENTAL:
- * All functions in this file may be changed or removed without prior notice.
- *
* Defines comp device APIs for the provisioning of compression operations.
*/
@@ -54,7 +50,6 @@ struct rte_compressdev_capabilities {
#define RTE_COMP_END_OF_CAPABILITIES_LIST() \
{ RTE_COMP_ALGO_UNSPECIFIED }
-__rte_experimental
const struct rte_compressdev_capabilities *
rte_compressdev_capability_get(uint8_t dev_id,
enum rte_comp_algorithm algo);
@@ -94,7 +89,6 @@ rte_compressdev_capability_get(uint8_t dev_id,
* @return
* The name of this flag, or NULL if it's not a valid feature flag.
*/
-__rte_experimental
const char *
rte_compressdev_get_feature_name(uint64_t flag);
@@ -133,7 +127,6 @@ struct rte_compressdev_stats {
* - Returns compress device identifier on success.
* - Return -1 on failure to find named compress device.
*/
-__rte_experimental
int
rte_compressdev_get_dev_id(const char *name);
@@ -146,7 +139,6 @@ rte_compressdev_get_dev_id(const char *name);
* - Returns compress device name.
* - Returns NULL if compress device is not present.
*/
-__rte_experimental
const char *
rte_compressdev_name_get(uint8_t dev_id);
@@ -157,7 +149,6 @@ rte_compressdev_name_get(uint8_t dev_id);
* @return
* - The total number of usable compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_count(void);
@@ -175,7 +166,6 @@ rte_compressdev_count(void);
* @return
* Returns number of attached compress devices.
*/
-__rte_experimental
uint8_t
rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
uint8_t nb_devices);
@@ -190,7 +180,6 @@ rte_compressdev_devices_get(const char *driver_name, uint8_t *devices,
* a default of zero if the socket could not be determined.
* -1 if returned is the dev_id value is out of range.
*/
-__rte_experimental
int
rte_compressdev_socket_id(uint8_t dev_id);
@@ -221,7 +210,6 @@ struct rte_compressdev_config {
* - 0: Success, device configured.
* - <0: Error code returned by the driver configuration function.
*/
-__rte_experimental
int
rte_compressdev_configure(uint8_t dev_id,
struct rte_compressdev_config *config);
@@ -240,7 +228,6 @@ rte_compressdev_configure(uint8_t dev_id,
* - 0: Success, device started.
* - <0: Error code of the driver device start function.
*/
-__rte_experimental
int
rte_compressdev_start(uint8_t dev_id);
@@ -251,7 +238,6 @@ rte_compressdev_start(uint8_t dev_id);
* @param dev_id
* Compress device identifier
*/
-__rte_experimental
void
rte_compressdev_stop(uint8_t dev_id);
@@ -269,7 +255,6 @@ rte_compressdev_stop(uint8_t dev_id);
* - 0 on successfully closing device
* - <0 on failure to close device
*/
-__rte_experimental
int
rte_compressdev_close(uint8_t dev_id);
@@ -296,7 +281,6 @@ rte_compressdev_close(uint8_t dev_id);
* - 0: Success, queue pair correctly set up.
* - <0: Queue pair configuration failed
*/
-__rte_experimental
int
rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
uint32_t max_inflight_ops, int socket_id);
@@ -309,7 +293,6 @@ rte_compressdev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
* @return
* - The number of configured queue pairs.
*/
-__rte_experimental
uint16_t
rte_compressdev_queue_pair_count(uint8_t dev_id);
@@ -327,7 +310,6 @@ rte_compressdev_queue_pair_count(uint8_t dev_id);
* - Zero if successful.
* - Non-zero otherwise.
*/
-__rte_experimental
int
rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
@@ -337,7 +319,6 @@ rte_compressdev_stats_get(uint8_t dev_id, struct rte_compressdev_stats *stats);
* @param dev_id
* The identifier of the device.
*/
-__rte_experimental
void
rte_compressdev_stats_reset(uint8_t dev_id);
@@ -355,7 +336,6 @@ rte_compressdev_stats_reset(uint8_t dev_id);
* The element after the last valid element has it's op field set to
* RTE_COMP_ALGO_UNSPECIFIED.
*/
-__rte_experimental
void
rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
@@ -413,7 +393,6 @@ rte_compressdev_info_get(uint8_t dev_id, struct rte_compressdev_info *dev_info);
* of pointers to *rte_comp_op* structures effectively supplied to the
* *ops* array.
*/
-__rte_experimental
uint16_t
rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -468,7 +447,6 @@ rte_compressdev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
* comp devices queue is full or if invalid parameters are specified in
* a *rte_comp_op*.
*/
-__rte_experimental
uint16_t
rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_comp_op **ops, uint16_t nb_ops);
@@ -496,7 +474,6 @@ rte_compressdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private stream could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_stream_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -518,7 +495,6 @@ rte_compressdev_stream_create(uint8_t dev_id,
* - Returns -ENOTSUP if comp device does not support STATEFUL operations.
* - Returns -EBUSY if can't free stream as there are inflight operations
*/
-__rte_experimental
int
rte_compressdev_stream_free(uint8_t dev_id, void *stream);
@@ -545,7 +521,6 @@ rte_compressdev_stream_free(uint8_t dev_id, void *stream);
* - Returns -ENOTSUP if comp device does not support the comp transform.
* - Returns -ENOMEM if the private_xform could not be allocated.
*/
-__rte_experimental
int
rte_compressdev_private_xform_create(uint8_t dev_id,
const struct rte_comp_xform *xform,
@@ -567,7 +542,6 @@ rte_compressdev_private_xform_create(uint8_t dev_id,
* - <0 in error cases
* - Returns -EINVAL if input parameters are invalid.
*/
-__rte_experimental
int
rte_compressdev_private_xform_free(uint8_t dev_id, void *private_xform);
diff --git a/lib/compressdev/rte_compressdev_pmd.h b/lib/compressdev/rte_compressdev_pmd.h
index ea012908b783..fa233492fe1f 100644
--- a/lib/compressdev/rte_compressdev_pmd.h
+++ b/lib/compressdev/rte_compressdev_pmd.h
@@ -59,7 +59,6 @@ struct rte_compressdev_global {
* @return
* - The rte_compressdev structure pointer for the given device identifier.
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_get_named_dev(const char *name);
@@ -292,7 +291,6 @@ struct rte_compressdev_ops {
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_allocate(const char *name, int socket_id);
@@ -308,7 +306,6 @@ rte_compressdev_pmd_allocate(const char *name, int socket_id);
* @return
* - 0 on success, negative on error
*/
-__rte_experimental
int
rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
@@ -331,7 +328,6 @@ rte_compressdev_pmd_release_device(struct rte_compressdev *dev);
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_parse_input_args(
struct rte_compressdev_pmd_init_params *params,
@@ -353,7 +349,6 @@ rte_compressdev_pmd_parse_input_args(
* - comp device instance on success
* - NULL on creation failure
*/
-__rte_experimental
struct rte_compressdev *
rte_compressdev_pmd_create(const char *name,
struct rte_device *device,
@@ -372,7 +367,6 @@ rte_compressdev_pmd_create(const char *name,
* - 0 on success
* - errno on failure
*/
-__rte_experimental
int
rte_compressdev_pmd_destroy(struct rte_compressdev *dev);
diff --git a/lib/compressdev/version.map b/lib/compressdev/version.map
index e2a108b6509f..fa891f669b5d 100644
--- a/lib/compressdev/version.map
+++ b/lib/compressdev/version.map
@@ -1,4 +1,4 @@
-EXPERIMENTAL {
+DPDK_24 {
global:
rte_compressdev_capability_get;
--
2.39.2
^ permalink raw reply [relevance 2%]
* Re: [PATCH 00/20] remove experimental flag from some API's
` (5 preceding siblings ...)
2023-10-24 2:53 3% ` [PATCH v7 00/25] Promote 22.11 and older " Stephen Hemminger
@ 2023-10-24 7:20 0% ` Maxime Coquelin
6 siblings, 0 replies; 200+ results
From: Maxime Coquelin @ 2023-10-24 7:20 UTC (permalink / raw)
To: Stephen Hemminger, dev
On 8/8/23 19:35, Stephen Hemminger wrote:
> Since 23.11 is an LTS release it is time to remove the experimental
> bandaid off many API's. There are about 850 API's marked with experimental
> on current main branch. This addresses the easy to remove ones and
> gets it down to about 690 places.
>
> The rule is any API that has been in since 22.11 needs to have
> experimental removed (or deleted). The experimental flag is not a
> "get out of ABI stability for free" card.
>
> Stephen Hemminger (20):
> bpf: make rte_bpf_dump and rte_bpf_convert stable API's
> cmdline: make experimental API's stable
> ethdev: mark rte_mtr API's as stable
> ethdev: mark rte_tm API's as stable
> pdump: make API's stable
> pcapng: mark API's as stable
> net: remove experimental from functions
> rcu: remove experimental from rte_rcu_qbsr
> lpm: remove experimental
> mbuf: remove experimental from create_extbuf
> hash: remove experimental from toeplitz hash
> timer: remove experimental from rte_timer_next_ticks
> sched: remove experimental
> dmadev: mark API's as not experimental
> meter: remove experimental warning from comments
> power: remove experimental from API's
> kvargs: remove experimental flag
> ip_frag: mark a couple of functions stable
> member: remove experimental tag
> security: remove experimental flag
>
> lib/bpf/rte_bpf.h | 2 -
> lib/bpf/version.map | 9 +--
> lib/cmdline/cmdline.h | 1 -
> lib/cmdline/cmdline_parse.h | 4 --
> lib/cmdline/cmdline_rdline.h | 4 --
> lib/cmdline/version.map | 26 +++------
> lib/dmadev/rte_dmadev.h | 85 ----------------------------
> lib/dmadev/version.map | 2 +-
> lib/ethdev/rte_mtr.h | 25 +-------
> lib/ethdev/rte_tm.h | 34 -----------
> lib/ethdev/version.map | 88 ++++++++++++++---------------
> lib/hash/rte_thash.h | 44 ---------------
> lib/hash/rte_thash_gfni.h | 8 ---
> lib/hash/rte_thash_x86_gfni.h | 8 ---
> lib/hash/version.map | 16 ++----
> lib/ip_frag/rte_ip_frag.h | 2 -
> lib/ip_frag/version.map | 9 +--
> lib/kvargs/rte_kvargs.h | 4 --
> lib/kvargs/version.map | 8 +--
> lib/lpm/rte_lpm.h | 4 --
> lib/lpm/version.map | 7 +--
> lib/mbuf/rte_mbuf.h | 1 -
> lib/mbuf/version.map | 8 +--
> lib/member/rte_member.h | 54 ------------------
> lib/member/version.map | 12 +---
> lib/meter/rte_meter.h | 12 ----
> lib/net/rte_ip.h | 19 -------
> lib/pcapng/rte_pcapng.h | 11 ----
> lib/pcapng/version.map | 6 +-
> lib/pdump/rte_pdump.h | 12 ----
> lib/pdump/version.map | 11 +---
> lib/power/rte_power.h | 4 --
> lib/power/rte_power_guest_channel.h | 4 --
> lib/power/rte_power_intel_uncore.h | 9 ---
> lib/power/rte_power_pmd_mgmt.h | 40 -------------
> lib/power/version.map | 33 ++++-------
> lib/rcu/rte_rcu_qsbr.h | 20 -------
> lib/rcu/version.map | 15 ++---
> lib/sched/rte_pie.h | 8 ---
> lib/sched/rte_sched.h | 5 --
> lib/sched/version.map | 18 ++----
> lib/security/rte_security.h | 35 ------------
> lib/security/version.map | 17 ++----
> lib/timer/rte_timer.h | 4 --
> lib/timer/version.map | 7 +--
> 45 files changed, 97 insertions(+), 658 deletions(-)
>
You removed Vhost changes altogether, but I only asked for the Vhost
Async API changes to be removed, i.e. the APIs in rte_vhost_async.h.
Maxime
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm
2023-10-12 2:21 0% ` fengchengwen
2023-10-12 15:23 0% ` Stephen Hemminger
@ 2023-10-24 12:54 0% ` Jie Hai
1 sibling, 0 replies; 200+ results
From: Jie Hai @ 2023-10-24 12:54 UTC (permalink / raw)
To: fengchengwen, Stephen Hemminger
Cc: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam,
lihuisong, liudongdong3
On 2023/10/12 10:21, fengchengwen wrote:
>
>
> On 2023/10/12 1:39, Stephen Hemminger wrote:
>> On Wed, 11 Oct 2023 17:27:27 +0800
>> Jie Hai <haijie1@huawei.com> wrote:
>>
>>> Currently, rte_eth_rss_conf supports configuring and querying
>>> RSS hash functions, rss key and it's length, but not RSS hash
>>> algorithm.
>>>
>>> The structure ``rte_eth_rss_conf`` is extended by adding a new
>>> field "algorithm". This represents the RSS algorithms to apply.
>>> The following API will be affected:
>>> - rte_eth_dev_configure
>>> - rte_eth_dev_rss_hash_update
>>> - rte_eth_dev_rss_hash_conf_get
>>>
>>> If the value of "algorithm" used for configuration is a gibberish
>>> value, report the error and return. Do the same for
>>> rte_eth_dev_rss_hash_update and rte_eth_dev_configure.
>>>
>>> To check whether the drivers report valid "algorithm", it is set
>>> to default value before querying.
>>>
>>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>>> ---
>>> doc/guides/rel_notes/release_23_11.rst | 2 ++
>>> lib/ethdev/rte_ethdev.c | 17 ++++++++++++++++
>>> lib/ethdev/rte_ethdev.h | 27 +++++++++++++++++++++++++
>>> lib/ethdev/rte_flow.c | 1 -
>>> lib/ethdev/rte_flow.h | 28 ++------------------------
>>> 5 files changed, 48 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
>>> index e13d57728071..92a445ab2ed3 100644
>>> --- a/doc/guides/rel_notes/release_23_11.rst
>>> +++ b/doc/guides/rel_notes/release_23_11.rst
>>> @@ -197,6 +197,8 @@ ABI Changes
>>> fields, to move ``rxq`` and ``txq`` fields, to change the size of
>>> ``reserved1`` and ``reserved2`` fields.
>>>
>>> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
>>> + hash algorithm.
>>>
>>> Known Issues
>>> ------------
>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>> index 18a4b950b184..2eda1b8072e5 100644
>>> --- a/lib/ethdev/rte_ethdev.c
>>> +++ b/lib/ethdev/rte_ethdev.c
>>> @@ -1464,6 +1464,14 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>>> goto rollback;
>>> }
>>>
>>> + if (dev_conf->rx_adv_conf.rss_conf.algorithm >= RTE_ETH_HASH_FUNCTION_MAX) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Ethdev port_id=%u invalid RSS algorithm: 0x%"PRIx64"\n",
>>> + port_id, dev_conf->rx_adv_conf.rss_conf.algorithm);
>>> + ret = -EINVAL;
>>> + goto rollback;
>>> + }
>>> +
>>
>> Rather than having every driver check the algorithm, why not handle this like
>> other features in DPDK (which may mean API/ABI changes).
>>
>> Add a field rss_algo_capa which is bit field of available RSS functions.
>> Then the check for algorithm can be done in generic code. There a couple
>> of reserved fields that could be used.
>
> +1 for add a field
>
> But there are two ways to config rss: ethdev-ops, ethdev-rteflow-ops, should distinguish them ? or just define for ethdev-ops ?
>
The rte_flow API does not distinguish RSS rule and FDIR rule,
the actual implementation of rss configuration depends on drivers.
I think if we had this "rss_algo_capa ", it can be just for ethdev-ops
for ethdev API level use.
>>
>> It would mean updating all the drivers once with the capa field but
>> would provide way for application to know what fields are possible.
>>
>> It has proved to be a problem in later ABI changes if a maximum value
>> is exposed. I.e don't expose RTE_ETH_HASH_FUNCTION_MAX.
>
> +1
>
>>
>> .
>>
> .
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 00/40] support setting and querying RSS algorithms
@ 2023-10-24 12:57 3% ` lihuisong (C)
2023-10-26 8:53 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-10-24 12:57 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, Jie Hai
Cc: dev, fengchengwen, liudongdong3, stephen
在 2023/10/17 22:26, Ferruh Yigit 写道:
> On 10/17/2023 3:06 PM, Thomas Monjalon wrote:
>> Hello,
>>
>> 11/10/2023 11:27, Jie Hai:
>>> app/proc-info/main.c | 32 ++++++++++-----
>>> app/test-pmd/cmdline.c | 29 ++++++++++---
>>> app/test-pmd/config.c | 38 ++++++++---------
>>> app/test-pmd/testpmd.h | 2 +-
>>> doc/guides/rel_notes/release_23_11.rst | 2 +
>>> drivers/net/atlantic/atl_ethdev.c | 2 +
>>> drivers/net/axgbe/axgbe_ethdev.c | 9 +++++
>>> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++
>>> drivers/net/bnxt/bnxt_ethdev.c | 6 +++
>>> drivers/net/bonding/rte_eth_bond_pmd.c | 6 +++
>>> drivers/net/cnxk/cnxk_ethdev.c | 5 +++
>>> drivers/net/cnxk/cnxk_ethdev_ops.c | 3 ++
>>> drivers/net/cpfl/cpfl_ethdev.c | 6 +++
>>> drivers/net/cxgbe/cxgbe_ethdev.c | 9 ++++-
>>> drivers/net/dpaa/dpaa_ethdev.c | 7 ++++
>>> drivers/net/dpaa2/dpaa2_ethdev.c | 7 ++++
>>> drivers/net/ena/ena_rss.c | 3 ++
>>> drivers/net/enic/enic_ethdev.c | 1 +
>>> drivers/net/enic/enic_main.c | 3 ++
>>> drivers/net/fm10k/fm10k_ethdev.c | 9 ++++-
>>> drivers/net/hinic/hinic_pmd_ethdev.c | 3 ++
>>> drivers/net/hinic/hinic_pmd_rx.c | 3 ++
>>> drivers/net/hns3/hns3_rss.c | 47 ++++++++++++---------
>>> drivers/net/i40e/i40e_ethdev.c | 7 ++++
>>> drivers/net/iavf/iavf_ethdev.c | 6 +++
>>> drivers/net/ice/ice_dcf.c | 3 ++
>>> drivers/net/ice/ice_dcf_ethdev.c | 3 ++
>>> drivers/net/ice/ice_ethdev.c | 7 ++++
>>> drivers/net/idpf/idpf_ethdev.c | 6 +++
>>> drivers/net/igc/igc_ethdev.c | 4 ++
>>> drivers/net/igc/igc_txrx.c | 5 +++
>>> drivers/net/ionic/ionic_ethdev.c | 6 +++
>>> drivers/net/ixgbe/ixgbe_ethdev.c | 12 +++++-
>>> drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++
>>> drivers/net/mana/mana.c | 11 ++++-
>>> drivers/net/mlx5/mlx5_ethdev.c | 4 ++
>>> drivers/net/mlx5/mlx5_rss.c | 3 +-
>>> drivers/net/mvpp2/mrvl_ethdev.c | 3 ++
>>> drivers/net/netvsc/hn_ethdev.c | 6 +++
>>> drivers/net/nfp/nfp_common.c | 9 ++++-
>>> drivers/net/ngbe/ngbe_ethdev.c | 6 ++-
>>> drivers/net/ngbe/ngbe_rxtx.c | 3 ++
>>> drivers/net/null/rte_eth_null.c | 8 ++++
>>> drivers/net/qede/qede_ethdev.c | 9 ++++-
>>> drivers/net/sfc/sfc_ethdev.c | 3 ++
>>> drivers/net/sfc/sfc_rx.c | 3 ++
>>> drivers/net/tap/rte_eth_tap.c | 8 ++++
>>> drivers/net/thunderx/nicvf_ethdev.c | 10 ++++-
>>> drivers/net/txgbe/txgbe_ethdev.c | 7 +++-
>>> drivers/net/txgbe/txgbe_ethdev_vf.c | 7 +++-
>>> drivers/net/txgbe/txgbe_rxtx.c | 3 ++
>>> lib/ethdev/rte_ethdev.c | 17 ++++++++
>>> lib/ethdev/rte_ethdev.h | 56 +++++++++++++++++++-------
>>> lib/ethdev/rte_flow.c | 1 -
>>> lib/ethdev/rte_flow.h | 25 +-----------
>>> 55 files changed, 395 insertions(+), 106 deletions(-)
>> Changing all drivers is suspicious.
>> It shows that something is missing in ethdev.
>> Please can you add the checks in ethdev only?
>>
> That is kind of request from me, let me try to summarize what is going on,
>
> there is a new config item added to "struct rte_eth_rss_conf" introduced
> in this set, which is RSS hashing algorithm to use.
>
> Problem is none of the existing drivers are taking account this new
> config item, so application will request it but drivers silently ignore it.
>
> This is a generic problem when adding a new config item to existing
> config struct.
>
> So my request was if drivers not supporting it, and it is requested by
> the application, driver should return an error to let application know
> that it is not supported, that is why bunch of drivers updated.
>
>
> One option can be adding a new, specific API and dev_ops for this, for
> this case new config item is related to the existing RSS API, so I think
> it can be part of the existing API.
>
> Other can be to have some kind of capability reporting by drivers, and
> application will detect it and won't request this new config item, I
> think Stephen already suggested something like this. This capability
> flag is again a generic requirement, and `rte_eth_dev_info_get()`
> partially used for this purpose. I think it will be odd from application
> perspective to have a capability for just one config item of a feature set.
>
>
> Anyway, I think updating drivers to report they are not supporting new
> config item is best option to me, but also I think we should discuss
> this capability reporting in ethdev in a wider context.
IMO, it is more better to report RSS algorithm capability.
It can avoid the later ABI break successfully as Stephen said.
>
>
>
> .
^ permalink raw reply [relevance 3%]
* Re: [PATCH v7 0/3] add telemetry cmds for ring
2023-10-10 2:25 0% ` Jie Hai
@ 2023-10-25 1:22 0% ` Jie Hai
2023-10-28 9:50 0% ` Jie Hai
2023-11-08 2:55 0% ` lihuisong (C)
3 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-10-25 1:22 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, liudongdong3
Hi, Thomas,
Kindly ping for review.
Thanks,
Jie Hai
On 2023/7/4 17:04, Jie Hai wrote:
> This patch set supports telemetry cmd to list rings and dump information
> of a ring by its name.
>
> v1->v2:
> 1. Add space after "switch".
> 2. Fix wrong strlen parameter.
>
> v2->v3:
> 1. Remove prefix "rte_" for static function.
> 2. Add Acked-by Konstantin Ananyev for PATCH 1.
> 3. Introduce functions to return strings instead copy strings.
> 4. Check pointer to memzone of ring.
> 5. Remove redundant variable.
> 6. Hold lock when access ring data.
>
> v3->v4:
> 1. Update changelog according to reviews of Honnappa Nagarahalli.
> 2. Add Reviewed-by Honnappa Nagarahalli.
> 3. Correct grammar in help information.
> 4. Correct spell warning on "te" reported by checkpatch.pl.
> 5. Use ring_walk() to query ring info instead of rte_ring_lookup().
> 6. Fix that type definition the flag field of rte_ring does not match the usage.
> 7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
> for mask and flags.
>
> v4->v5:
> 1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
> 2. Add ABI change explanation for commit message of patch 1/3.
>
> v5->v6:
> 1. Add Acked-by Morten Brørup.
> 2. Fix incorrect reference of commit.
>
> v6->v7:
> 1. Remove prod/consumer head/tail info.
>
> Jie Hai (3):
> ring: fix unmatched type definition and usage
> ring: add telemetry cmd to list rings
> ring: add telemetry cmd for ring info
>
> lib/ring/meson.build | 1 +
> lib/ring/rte_ring.c | 135 +++++++++++++++++++++++++++++++++++++++
> lib/ring/rte_ring_core.h | 2 +-
> 3 files changed, 137 insertions(+), 1 deletion(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 00/40] support setting and querying RSS algorithms
2023-10-24 12:57 3% ` lihuisong (C)
@ 2023-10-26 8:53 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-10-26 8:53 UTC (permalink / raw)
To: Ferruh Yigit, Jie Hai, lihuisong (C)
Cc: dev, fengchengwen, liudongdong3, stephen
24/10/2023 14:57, lihuisong (C):
> 在 2023/10/17 22:26, Ferruh Yigit 写道:
> > On 10/17/2023 3:06 PM, Thomas Monjalon wrote:
> >> 11/10/2023 11:27, Jie Hai:
> >>> 55 files changed, 395 insertions(+), 106 deletions(-)
> >>
> >> Changing all drivers is suspicious.
> >> It shows that something is missing in ethdev.
> >> Please can you add the checks in ethdev only?
> >>
> > That is kind of request from me, let me try to summarize what is going on,
> >
> > there is a new config item added to "struct rte_eth_rss_conf" introduced
> > in this set, which is RSS hashing algorithm to use.
> >
> > Problem is none of the existing drivers are taking account this new
> > config item, so application will request it but drivers silently ignore it.
> >
> > This is a generic problem when adding a new config item to existing
> > config struct.
> >
> > So my request was if drivers not supporting it, and it is requested by
> > the application, driver should return an error to let application know
> > that it is not supported, that is why bunch of drivers updated.
> >
> >
> > One option can be adding a new, specific API and dev_ops for this, for
> > this case new config item is related to the existing RSS API, so I think
> > it can be part of the existing API.
> >
> > Other can be to have some kind of capability reporting by drivers, and
> > application will detect it and won't request this new config item, I
> > think Stephen already suggested something like this. This capability
> > flag is again a generic requirement, and `rte_eth_dev_info_get()`
> > partially used for this purpose. I think it will be odd from application
> > perspective to have a capability for just one config item of a feature set.
> >
> >
> > Anyway, I think updating drivers to report they are not supporting new
> > config item is best option to me, but also I think we should discuss
> > this capability reporting in ethdev in a wider context.
> IMO, it is more better to report RSS algorithm capability.
> It can avoid the later ABI break successfully as Stephen said.
Yes we should add a capability for RSS algorithm.
^ permalink raw reply [relevance 0%]
* RE: release candidate 23.11-rc1
[not found] ` <MW4PR11MB5912D298978501DAC2092EA49FD4A@MW4PR11MB5912.namprd11.prod.outlook.com>
@ 2023-10-27 9:19 0% ` Xu, HailinX
0 siblings, 0 replies; 200+ results
From: Xu, HailinX @ 2023-10-27 9:19 UTC (permalink / raw)
To: Thomas Monjalon, dev
Cc: Kovacevic, Marko, Mcnamara, John, Richardson, Bruce, Ferruh Yigit
[-- Attachment #1: Type: text/plain, Size: 7574 bytes --]
> -----Original Message-----
> From: Xu, HailinX
> Sent: Thursday, October 19, 2023 3:58 PM
> To: Thomas Monjalon <thomas@monjalon.net>; announce@dpdk.org
> Cc: Kovacevic, Marko <Marko.Kovacevic@intel.com>; Mcnamara, John
> <john.mcnamara@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Ferruh Yigit <ferruh.yigit@xilinx.com>
> Subject: RE: release candidate 23.11-rc1
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net<mailto:thomas@monjalon.net>>
> > Sent: Wednesday, October 18, 2023 4:37 AM
> > To: announce@dpdk.org<mailto:announce@dpdk.org>
> > Subject: release candidate 23.11-rc1
> >
> > A new DPDK release candidate is ready for testing:
> > https://git.dpdk.org/dpdk/tag/?id=v23.11-rc1
> >
> > There are 617 new patches in this snapshot, including many API/ABI
> > compatibility breakages.
> > This release won't be ABI-compatible with previous ones.
> >
> > Release notes:
> > https://doc.dpdk.org/guides/rel_notes/release_23_11.html
> >
> > Highlights of 23.11-rc1:
> > - build requires C11 compiler
> > - early support of MSVC build
> > - new atomic operations API
> > - power management on AMD CPU
> > - mbuf recycling
> > - flow action type for P4-defined actions
> > - flow group miss action
> > - flow item for packet type matching
> > - TLS record offload
> > - security Rx inject
> > - eventdev link profiles
> > - eventdev adapter for dmadev
> > - event dispatcher library
> >
> > Please test and report issues on bugs.dpdk.org.
> >
> > DPDK 23.11-rc2 is expected in approximately two weeks.
> >
> > Thank you everyone
> >
> Update the test status for Intel part. Till now dpdk23.11-rc1 test execution rate
> is 30%. No new issue is found.
>
> # Basic Intel(R) NIC testing
> * Build or compile:
> *Build: cover the build test combination with latest GCC/Clang version and
> the popular OS revision such as Ubuntu20.04.5, Ubuntu22.04.3, Fedora38,
> RHEL8.7/9.2, Centos7.9, OpenAnolis8.8, CBL-Mariner2.0 etc.
> - All test passed.
> *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as
> Ubuntu22.04.3 and RHEL9.2.
> - All test passed with latest dpdk.
> * Meson test & Asan test:
> known issue:
> - https://bugs.dpdk.org/show_bug.cgi?id=1107 [22.11-rc1][meson
> test] seqlock_autotest test failed
> - https://bugs.dpdk.org/show_bug.cgi?id=1123 [dpdk-22.11][asan]
> the stack-buffer-overflow was found when quit testpmd in Redhat9
> * PF/VF(i40e, ixgbe): test scenarios including PF/VF-
> RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
> - Execution rate is 50%. No new issue is found.
> * PF/VF(ice): test scenarios including Switch features/Package
> Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible
> Descriptor, etc.
> - Execution rate is 30%. No new issue is found.
> * Intel NIC single core/NIC performance: test scenarios including PF/VF single
> core performance test, RFC2544 Zero packet loss performance test, etc.
> - Execution rate is 20%. No new issue is found.
> * Power and IPsec:
> * Power: test scenarios including bi-direction/Telemetry/Empty Poll
> Lib/Priority Base Frequency, etc.
> - on going. No new issue is found.
> * IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test -
> QAT&SW/FIB library, etc.
> - On going. No new issue is found.
> # Basic cryptodev and virtio testing
> * Virtio: both function and performance test are covered. Such as
> PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf
> testing/VMAWARE ESXI 8.0 U1, etc.
> - Execution rate is 50%. No new issue is found.
> * Cryptodev:
> *Function test: test scenarios including Cryptodev API testing/CompressDev
> ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
> - On going. No new issue is found.
> *Performance test: test scenarios including Throughput Performance
> /Cryptodev Latency, etc.
> - On going. No performance drop.
>
> Regards,
> Xu, Hailin
Update the test status for Intel part. dpdk23.11-rc1 all test execution is done. found 8 new issues.
New issues:
1. kernelpf_dcf/dcf_information: port stats cannot be reset in dcf. -> Intel dev is under investigating
2. Fix Tx offloading flags check. -> Has fix patch
3. core dumped occurred when exit testpmd with representor port. -> Has fix patch
4. core dumped occurred after test csum fwd. -> Has fix patch
5. https://bugs.dpdk.org/show_bug.cgi?id=1303 hotplug_mp/attach_detach_dev_primary_cross_loop: re-attach dev failed in multiple processes. -> Has fix patch
6. vm2vm_virtio_user_dsa/test_split_non_mergeable_multi_queues_payload_check_with_kernel_driver: virtio-user1 not receive packet. -> Intel dev is under investigating
7. [mev] Core dumped when starting testpmd with representor port. -> Has fix patch
8. https://bugs.dpdk.org/show_bug.cgi?id=1304: l3fwd-power example fails to run with uncore options, -U -u and -i. -> has fix patch
# Basic Intel(R) NIC testing
* Build or compile:
*Build: cover the build test combination with latest GCC/Clang version and the popular OS revision such as Ubuntu20.04.5, Ubuntu22.04.3, Fedora38, RHEL8.7/9.2, Centos7.9, OpenAnolis8.8, CBL-Mariner2.0 etc.
- All test passed.
*Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu22.04.2 and RHEL9.0.
- All test passed with latest dpdk.
* PF/VF(i40e, ixgbe): test scenarios including PF/VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc.
- Execution rate is done. No new issue is found.
* PF/VF(ice): test scenarios including Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
- Execution rate is done. found 1&3&4&5 issues.
* MEV test: test scenarios including PF/TSO/MTU/Jumboframe/checksum offload, etc
- Execution rate is done. found 7 issue.
* Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, RFC2544 Zero packet loss performance test, etc.
- Execution rate is done. No new issue is found.
* Power and IPsec:
* Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency, etc.
- Execution rate is done. found 8 issue.
* IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc.
- Execution rate is done. found 2 issue.
# Basic cryptodev and virtio testing
* Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 8.0, etc.
- Execution rate is done. found 6 issue.
* Cryptodev:
*Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
- Execution rate is done. No new issue is found.
*Performance test: test scenarios including Throughput Performance /Cryptodev Latency, etc.
- Execution rate is done. No performance drop.
Regards,
Xu, Hailin
[-- Attachment #2: Type: text/html, Size: 17835 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH 2/9] ethdev: support setting and querying RSS algorithm
2023-10-27 9:28 3% ` [PATCH 0/9] " Jie Hai
@ 2023-10-27 9:28 4% ` Jie Hai
2023-10-28 1:46 3% ` [PATCH v7 0/9] support setting and querying RSS algorithms Jie Hai
1 sibling, 0 replies; 200+ results
From: Jie Hai @ 2023-10-27 9:28 UTC (permalink / raw)
To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_dev_info`` is extended by adding a new
field "rss_algo_capa". Drivers are responsible for reporting this
capa and configurations of RSS hash algorithm can be verified based
on the capability. The default value of "rss_algo_capa" is
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
If the value of "algorithm" used for configuration is a gibberish
value, drivers should report the error.
To check whether the drivers report valid "algorithm", it is set
to default value before querying in rte_eth_dev_rss_hash_conf_get().
Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 5 ++++
lib/ethdev/rte_ethdev.c | 26 ++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 26 ++------------------
5 files changed, 65 insertions(+), 26 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 0a6fc76a9d02..a35d729d2cc7 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -360,6 +360,11 @@ ABI Changes
* security: struct ``rte_security_ipsec_sa_options`` was updated
due to inline out-of-place feature addition.
+* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
+* reporting RSS hash algorithm capability.
+
+* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm.
Known Issues
------------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 9dabcb5ae28e..7af163b8a4b3 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1269,6 +1269,7 @@ int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
{
+ enum rte_eth_hash_function algorithm;
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
struct rte_eth_conf orig_conf;
@@ -1500,6 +1501,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
+ if ((dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
+ "with rss_algo_capa: 0x%"PRIx64"\n",
+ algorithm,
+ dev_info.rss_algo_capa);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/*
* Setup new number of Rx/Tx queues and reconfigure device.
*/
@@ -3757,6 +3770,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
RTE_ETHER_CRC_LEN;
dev_info->max_mtu = UINT16_MAX;
+ dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
if (*dev->dev_ops->dev_infos_get == NULL)
return -ENOTSUP;
@@ -4698,6 +4712,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -ENOTSUP;
}
+ if ((dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
+ "with rss_algo_capa: 0x%"PRIx64"\n",
+ rss_conf->algorithm,
+ dev_info.rss_algo_capa);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4725,6 +4749,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 37fd5afef48a..2f639edd8218 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /** DEFAULT means driver decides which hash algorithm to pick. */
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+ * Symmetric Toeplitz: src, dst will be replaced by
+ * xor(src, dst). For the case with src/dst only,
+ * src or dst address will xor with zero pair.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ /**
+ * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
+ * the hash function.
+ * If src_ip > dst_ip, swap src_ip and dst_ip.
+ * If src_port > dst_port, swap src_port and dst_port.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
+#define RTE_ETH_HASH_ALGO_CAPA_MASK(x) RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -469,6 +496,7 @@ struct rte_eth_rss_conf {
* which RSS hashing is to be applied.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
};
/*
@@ -1783,7 +1811,10 @@ struct rte_eth_dev_info {
/** Supported error handling mode. */
enum rte_eth_err_handle_mode err_handle_mode;
- uint64_t reserved_64s[2]; /**< Reserved for future fields */
+ /** RSS hash algorithms capabilities */
+ uint32_t rss_algo_capa;
+
+ uint32_t reserved_32s[3]; /**< Reserved for future fields */
void *reserved_ptrs[2]; /**< Reserved for future fields */
};
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 3a67f1aaba9d..c13a2a391c37 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -13,7 +13,6 @@
#include <rte_branch_prediction.h>
#include <rte_string_fns.h>
#include <rte_mbuf_dyn.h>
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 25f1dffd1f30..c94f553ae06f 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -40,6 +40,8 @@
#include <rte_macsec.h>
#include <rte_ib.h>
+#include "rte_ethdev.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
uint64_t bytes; /**< Number of bytes through this rule [out]. */
};
-/**
- * Hash function types.
- */
-enum rte_eth_hash_function {
- /** DEFAULT means driver decides which hash algorithm to pick. */
- RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
- RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
- RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
- /**
- * Symmetric Toeplitz: src, dst will be replaced by
- * xor(src, dst). For the case with src/dst only,
- * src or dst address will xor with zero pair.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
- /**
- * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
- * the hash function.
- * If src_ip > dst_ip, swap src_ip and dst_ip.
- * If src_port > dst_port, swap src_port and dst_port.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
- RTE_ETH_HASH_FUNCTION_MAX,
-};
-
/**
* RTE_FLOW_ACTION_TYPE_RSS
*
--
2.30.0
^ permalink raw reply [relevance 4%]
* [PATCH 0/9] support setting and querying RSS algorithms
2023-10-11 9:27 2% ` [PATCH v5 00/40] support setting and querying RSS algorithms Jie Hai
` (3 preceding siblings ...)
@ 2023-10-27 9:28 3% ` Jie Hai
2023-10-27 9:28 4% ` [PATCH 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-10-28 1:46 3% ` [PATCH v7 0/9] support setting and querying RSS algorithms Jie Hai
4 siblings, 2 replies; 200+ results
From: Jie Hai @ 2023-10-27 9:28 UTC (permalink / raw)
To: dev; +Cc: lihuisong, fengchengwen, liudongdong3
This patchset is to support setting and querying RSS algorithms.
For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
and field "algorithm" is added to ``rte_eth_rss_conf``.
The drivers should reports their "rss_algo_capa" if they support
updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
by field "algorithm" and the related API should verify "algorithm" with
"rss_algo_capa".
--
v6:
1. rewrite some comments.
2. add "rss_algo_capa" for `rte_eth_dev_info``.
3. add new API to get name of RSS algorithms
v5:
1. rewrite some comments.
2. check RSS algorithm for drivers supporting RSS.
3. change field "func" of rss_conf to "algorithm".
4. fix commit log for [PATCH v4 4/7].
5. add Acked-by Reshma Pattan.
6. add symmetric_toeplitz_sort for showing.
7. change "hf" to "hash function" for showing.
v4:
1. recomment some definitions related to RSS.
2. allocate static memory for rss_key instead of dynamic.
3. use array of strings to get the name of rss algorithm.
4. add display of rss algorithm with testpmd.
v3:
1. fix commit log for PATCH [1/5].
2. make RSS ABI changes description to start the actual text at the margin.
3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
4. fix some comment codes.
v2:
1. return error if "func" is invalid.
2. modify the comments of the "func" field.
3. modify commit log of patch [3/5].
4. use malloc instead of rte_malloc.
5. adjust display format of RSS info.
6. remove the string display of rss_hf.
Huisong Li (1):
net/hns3: support setting and querying RSS hash function
Jie Hai (8):
ethdev: overwrite some comment related to RSS
ethdev: support setting and querying RSS algorithm
net/hns3: report RSS hash algorithms capability
app/proc-info: fix never show RSS info
app/proc-info: adjust the display format of RSS info
lib/ethdev: add API to get RSS algorithm names
app/proc-info: support querying RSS hash algorithm
app/testpmd: add RSS hash algorithms display
app/proc-info/main.c | 24 +++++----
app/test-pmd/cmdline.c | 29 +++++++++--
app/test-pmd/config.c | 29 ++++-------
app/test-pmd/testpmd.h | 2 +-
doc/guides/rel_notes/release_23_11.rst | 8 +++
drivers/net/hns3/hns3_common.c | 4 ++
drivers/net/hns3/hns3_rss.c | 47 +++++++++--------
lib/ethdev/rte_ethdev.c | 51 +++++++++++++++++++
lib/ethdev/rte_ethdev.h | 70 ++++++++++++++++++++------
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 25 +--------
11 files changed, 196 insertions(+), 94 deletions(-)
--
2.30.0
^ permalink raw reply [relevance 3%]
* [PATCH v7 0/9] support setting and querying RSS algorithms
2023-10-27 9:28 3% ` [PATCH 0/9] " Jie Hai
2023-10-27 9:28 4% ` [PATCH 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-10-28 1:46 3% ` Jie Hai
2023-10-28 1:46 4% ` [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-11-01 2:04 0% ` [PATCH v7 0/9] support setting and querying RSS algorithms Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Jie Hai @ 2023-10-28 1:46 UTC (permalink / raw)
To: dev; +Cc: lihuisong, fengchengwen, liudongdong3, haijie1
This patchset is to support setting and querying RSS algorithms.
For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
and field "algorithm" is added to ``rte_eth_rss_conf``.
The drivers should reports their "rss_algo_capa" if they support
updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
by field "algorithm" and the related API should verify "algorithm" with
"rss_algo_capa".
--
v7:
1. fix compile error.
2. add signed-off-by to patch[4/9].
v6:
1. rewrite some comments.
2. add "rss_algo_capa" for `rte_eth_dev_info``.
3. add new API to get name of RSS algorithms
v5:
1. rewrite some comments.
2. check RSS algorithm for drivers supporting RSS.
3. change field "func" of rss_conf to "algorithm".
4. fix commit log for [PATCH v4 4/7].
5. add Acked-by Reshma Pattan.
6. add symmetric_toeplitz_sort for showing.
7. change "hf" to "hash function" for showing.
v4:
1. recomment some definitions related to RSS.
2. allocate static memory for rss_key instead of dynamic.
3. use array of strings to get the name of rss algorithm.
4. add display of rss algorithm with testpmd.
v3:
1. fix commit log for PATCH [1/5].
2. make RSS ABI changes description to start the actual text at the margin.
3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
4. fix some comment codes.
v2:
1. return error if "func" is invalid.
2. modify the comments of the "func" field.
3. modify commit log of patch [3/5].
4. use malloc instead of rte_malloc.
5. adjust display format of RSS info.
6. remove the string display of rss_hf.
Huisong Li (1):
net/hns3: support setting and querying RSS hash function
Jie Hai (8):
ethdev: overwrite some comment related to RSS
ethdev: support setting and querying RSS algorithm
net/hns3: report RSS hash algorithms capability
app/proc-info: fix never show RSS info
app/proc-info: adjust the display format of RSS info
lib/ethdev: add API to get RSS algorithm names
app/proc-info: support querying RSS hash algorithm
app/testpmd: add RSS hash algorithms display
app/proc-info/main.c | 24 +++++----
app/test-pmd/cmdline.c | 29 +++++++++--
app/test-pmd/config.c | 29 ++++-------
app/test-pmd/testpmd.h | 2 +-
doc/guides/rel_notes/release_23_11.rst | 8 +++
drivers/net/hns3/hns3_common.c | 4 ++
drivers/net/hns3/hns3_rss.c | 47 +++++++++--------
lib/ethdev/rte_ethdev.c | 51 +++++++++++++++++++
lib/ethdev/rte_ethdev.h | 70 ++++++++++++++++++++------
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 25 +--------
11 files changed, 196 insertions(+), 94 deletions(-)
--
2.30.0
^ permalink raw reply [relevance 3%]
* [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm
2023-10-28 1:46 3% ` [PATCH v7 0/9] support setting and querying RSS algorithms Jie Hai
@ 2023-10-28 1:46 4% ` Jie Hai
2023-10-28 3:01 3% ` lihuisong (C)
2023-11-01 2:04 0% ` [PATCH v7 0/9] support setting and querying RSS algorithms Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Jie Hai @ 2023-10-28 1:46 UTC (permalink / raw)
To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3, haijie1
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_dev_info`` is extended by adding a new
field "rss_algo_capa". Drivers are responsible for reporting this
capa and configurations of RSS hash algorithm can be verified based
on the capability. The default value of "rss_algo_capa" is
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
If the value of "algorithm" used for configuration is a gibberish
value, drivers should report the error.
To check whether the drivers report valid "algorithm", it is set
to default value before querying in rte_eth_dev_rss_hash_conf_get().
Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 5 ++++
lib/ethdev/rte_ethdev.c | 26 ++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 26 ++------------------
5 files changed, 65 insertions(+), 26 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 0a6fc76a9d02..a35d729d2cc7 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -360,6 +360,11 @@ ABI Changes
* security: struct ``rte_security_ipsec_sa_options`` was updated
due to inline out-of-place feature addition.
+* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
+* reporting RSS hash algorithm capability.
+
+* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm.
Known Issues
------------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 9dabcb5ae28e..90bfbf14d1f7 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1269,6 +1269,7 @@ int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
{
+ enum rte_eth_hash_function algorithm;
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
struct rte_eth_conf orig_conf;
@@ -1500,6 +1501,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
+ if ((dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
+ "with rss_algo_capa: %x\n",
+ port_id, algorithm,
+ dev_info.rss_algo_capa);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/*
* Setup new number of Rx/Tx queues and reconfigure device.
*/
@@ -3757,6 +3770,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
RTE_ETHER_CRC_LEN;
dev_info->max_mtu = UINT16_MAX;
+ dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
if (*dev->dev_ops->dev_infos_get == NULL)
return -ENOTSUP;
@@ -4698,6 +4712,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -ENOTSUP;
}
+ if ((dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
+ "with rss_algo_capa: %x\n",
+ port_id, rss_conf->algorithm,
+ dev_info.rss_algo_capa);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4725,6 +4749,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 37fd5afef48a..2f639edd8218 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /** DEFAULT means driver decides which hash algorithm to pick. */
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+ * Symmetric Toeplitz: src, dst will be replaced by
+ * xor(src, dst). For the case with src/dst only,
+ * src or dst address will xor with zero pair.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ /**
+ * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
+ * the hash function.
+ * If src_ip > dst_ip, swap src_ip and dst_ip.
+ * If src_port > dst_port, swap src_port and dst_port.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
+#define RTE_ETH_HASH_ALGO_CAPA_MASK(x) RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -469,6 +496,7 @@ struct rte_eth_rss_conf {
* which RSS hashing is to be applied.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
};
/*
@@ -1783,7 +1811,10 @@ struct rte_eth_dev_info {
/** Supported error handling mode. */
enum rte_eth_err_handle_mode err_handle_mode;
- uint64_t reserved_64s[2]; /**< Reserved for future fields */
+ /** RSS hash algorithms capabilities */
+ uint32_t rss_algo_capa;
+
+ uint32_t reserved_32s[3]; /**< Reserved for future fields */
void *reserved_ptrs[2]; /**< Reserved for future fields */
};
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 3a67f1aaba9d..c13a2a391c37 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -13,7 +13,6 @@
#include <rte_branch_prediction.h>
#include <rte_string_fns.h>
#include <rte_mbuf_dyn.h>
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 25f1dffd1f30..c94f553ae06f 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -40,6 +40,8 @@
#include <rte_macsec.h>
#include <rte_ib.h>
+#include "rte_ethdev.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
uint64_t bytes; /**< Number of bytes through this rule [out]. */
};
-/**
- * Hash function types.
- */
-enum rte_eth_hash_function {
- /** DEFAULT means driver decides which hash algorithm to pick. */
- RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
- RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
- RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
- /**
- * Symmetric Toeplitz: src, dst will be replaced by
- * xor(src, dst). For the case with src/dst only,
- * src or dst address will xor with zero pair.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
- /**
- * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
- * the hash function.
- * If src_ip > dst_ip, swap src_ip and dst_ip.
- * If src_port > dst_port, swap src_port and dst_port.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
- RTE_ETH_HASH_FUNCTION_MAX,
-};
-
/**
* RTE_FLOW_ACTION_TYPE_RSS
*
--
2.30.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm
2023-10-28 1:46 4% ` [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-10-28 3:01 3% ` lihuisong (C)
2023-11-01 12:55 5% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-10-28 3:01 UTC (permalink / raw)
To: Jie Hai, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: fengchengwen, liudongdong3
With belows to changes,
Acked-by: Huisong Li <lihuisong@huawei.com>
在 2023/10/28 9:46, Jie Hai 写道:
> Currently, rte_eth_rss_conf supports configuring and querying
> RSS hash functions, rss key and it's length, but not RSS hash
> algorithm.
>
> The structure ``rte_eth_dev_info`` is extended by adding a new
> field "rss_algo_capa". Drivers are responsible for reporting this
> capa and configurations of RSS hash algorithm can be verified based
> on the capability. The default value of "rss_algo_capa" is
> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
>
> The structure ``rte_eth_rss_conf`` is extended by adding a new
> field "algorithm". This represents the RSS algorithms to apply.
> If the value of "algorithm" used for configuration is a gibberish
> value, drivers should report the error.
>
> To check whether the drivers report valid "algorithm", it is set
> to default value before querying in rte_eth_dev_rss_hash_conf_get().
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
> doc/guides/rel_notes/release_23_11.rst | 5 ++++
> lib/ethdev/rte_ethdev.c | 26 ++++++++++++++++++++
> lib/ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 26 ++------------------
> 5 files changed, 65 insertions(+), 26 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
> index 0a6fc76a9d02..a35d729d2cc7 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -360,6 +360,11 @@ ABI Changes
> * security: struct ``rte_security_ipsec_sa_options`` was updated
> due to inline out-of-place feature addition.
>
> +* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
> +* reporting RSS hash algorithm capability.
> +
> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
> + hash algorithm.
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 9dabcb5ae28e..90bfbf14d1f7 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1269,6 +1269,7 @@ int
> rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> const struct rte_eth_conf *dev_conf)
> {
> + enum rte_eth_hash_function algorithm;
> struct rte_eth_dev *dev;
> struct rte_eth_dev_info dev_info;
> struct rte_eth_conf orig_conf;
> @@ -1500,6 +1501,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> goto rollback;
> }
>
> + algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
> + if ((dev_info.rss_algo_capa &
> + RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
need to check the algorithm.
its value should be in range of 0 to 31.
> + RTE_ETHDEV_LOG(ERR,
> + "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
> + "with rss_algo_capa: %x\n",
It seems that this log is not friendly to user.
Configured RSS hash algorithm (%u) is not in the algorithm capability ().
Anything ok like that.
%x --> 0x%" PRIx32 "
> + port_id, algorithm,
> + dev_info.rss_algo_capa);
> + ret = -EINVAL;
> + goto rollback;
> + }
> +
> /*
> * Setup new number of Rx/Tx queues and reconfigure device.
> */
> @@ -3757,6 +3770,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
> dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
> RTE_ETHER_CRC_LEN;
> dev_info->max_mtu = UINT16_MAX;
> + dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
>
> if (*dev->dev_ops->dev_infos_get == NULL)
> return -ENOTSUP;
> @@ -4698,6 +4712,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
> return -ENOTSUP;
> }
>
> + if ((dev_info.rss_algo_capa &
> + RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
> + RTE_ETHDEV_LOG(ERR,
> + "Ethdev port_id=%u config unsupported RSS hash algorithm: %u "
> + "with rss_algo_capa: %x\n",
> + port_id, rss_conf->algorithm,
> + dev_info.rss_algo_capa);
> + return -EINVAL;
> + }
> +
> if (*dev->dev_ops->rss_hash_update == NULL)
> return -ENOTSUP;
> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
> @@ -4725,6 +4749,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
> return -EINVAL;
> }
>
> + rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
> +
> if (*dev->dev_ops->rss_hash_conf_get == NULL)
> return -ENOTSUP;
> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 37fd5afef48a..2f639edd8218 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
> uint64_t ids[64];
> };
>
> +/**
> + * Hash function types.
> + */
> +enum rte_eth_hash_function {
> + /** DEFAULT means driver decides which hash algorithm to pick. */
> + RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> + RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> + RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> + /**
> + * Symmetric Toeplitz: src, dst will be replaced by
> + * xor(src, dst). For the case with src/dst only,
> + * src or dst address will xor with zero pair.
> + */
> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
> + /**
> + * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
> + * the hash function.
> + * If src_ip > dst_ip, swap src_ip and dst_ip.
> + * If src_port > dst_port, swap src_port and dst_port.
> + */
> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
> + RTE_ETH_HASH_FUNCTION_MAX,
> +};
> +
> +#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
> +#define RTE_ETH_HASH_ALGO_CAPA_MASK(x) RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
> +
> /**
> * A structure used to configure the Receive Side Scaling (RSS) feature
> * of an Ethernet port.
> @@ -469,6 +496,7 @@ struct rte_eth_rss_conf {
> * which RSS hashing is to be applied.
> */
> uint64_t rss_hf;
> + enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
> };
>
> /*
> @@ -1783,7 +1811,10 @@ struct rte_eth_dev_info {
> /** Supported error handling mode. */
> enum rte_eth_err_handle_mode err_handle_mode;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + /** RSS hash algorithms capabilities */
> + uint32_t rss_algo_capa;
Please move this new field to "hash_key_size" and
"flow_type_rss_offloads" in this struct.
Because this version allows ABI break.
> +
> + uint32_t reserved_32s[3]; /**< Reserved for future fields */
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 3a67f1aaba9d..c13a2a391c37 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -13,7 +13,6 @@
> #include <rte_branch_prediction.h>
> #include <rte_string_fns.h>
> #include <rte_mbuf_dyn.h>
> -#include "rte_ethdev.h"
> #include "rte_flow_driver.h"
> #include "rte_flow.h"
>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 25f1dffd1f30..c94f553ae06f 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -40,6 +40,8 @@
> #include <rte_macsec.h>
> #include <rte_ib.h>
>
> +#include "rte_ethdev.h"
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
> uint64_t bytes; /**< Number of bytes through this rule [out]. */
> };
>
> -/**
> - * Hash function types.
> - */
> -enum rte_eth_hash_function {
> - /** DEFAULT means driver decides which hash algorithm to pick. */
> - RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> - RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> - RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> - /**
> - * Symmetric Toeplitz: src, dst will be replaced by
> - * xor(src, dst). For the case with src/dst only,
> - * src or dst address will xor with zero pair.
> - */
> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
> - /**
> - * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
> - * the hash function.
> - * If src_ip > dst_ip, swap src_ip and dst_ip.
> - * If src_port > dst_port, swap src_port and dst_port.
> - */
> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
> - RTE_ETH_HASH_FUNCTION_MAX,
> -};
> -
> /**
> * RTE_FLOW_ACTION_TYPE_RSS
> *
^ permalink raw reply [relevance 3%]
* Re: [PATCH v7 0/3] add telemetry cmds for ring
2023-10-10 2:25 0% ` Jie Hai
2023-10-25 1:22 0% ` Jie Hai
@ 2023-10-28 9:50 0% ` Jie Hai
2023-11-08 2:55 0% ` lihuisong (C)
3 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-10-28 9:50 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand; +Cc: dev, liudongdong3
Hi, all maintainers,
Is there any other problem with this patchset?
Please let me know if there is any, thank you.
Thanks,
Jie Hai
On 2023/7/4 17:04, Jie Hai wrote:
> This patch set supports telemetry cmd to list rings and dump information
> of a ring by its name.
>
> v1->v2:
> 1. Add space after "switch".
> 2. Fix wrong strlen parameter.
>
> v2->v3:
> 1. Remove prefix "rte_" for static function.
> 2. Add Acked-by Konstantin Ananyev for PATCH 1.
> 3. Introduce functions to return strings instead copy strings.
> 4. Check pointer to memzone of ring.
> 5. Remove redundant variable.
> 6. Hold lock when access ring data.
>
> v3->v4:
> 1. Update changelog according to reviews of Honnappa Nagarahalli.
> 2. Add Reviewed-by Honnappa Nagarahalli.
> 3. Correct grammar in help information.
> 4. Correct spell warning on "te" reported by checkpatch.pl.
> 5. Use ring_walk() to query ring info instead of rte_ring_lookup().
> 6. Fix that type definition the flag field of rte_ring does not match the usage.
> 7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
> for mask and flags.
>
> v4->v5:
> 1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
> 2. Add ABI change explanation for commit message of patch 1/3.
>
> v5->v6:
> 1. Add Acked-by Morten Brørup.
> 2. Fix incorrect reference of commit.
>
> v6->v7:
> 1. Remove prod/consumer head/tail info.
>
> Jie Hai (3):
> ring: fix unmatched type definition and usage
> ring: add telemetry cmd to list rings
> ring: add telemetry cmd for ring info
>
> lib/ring/meson.build | 1 +
> lib/ring/rte_ring.c | 135 +++++++++++++++++++++++++++++++++++++++
> lib/ring/rte_ring_core.h | 2 +-
> 3 files changed, 137 insertions(+), 1 deletion(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH RESEND v6 0/5] app/testpmd: support multiple process attach and detach port
2023-10-09 10:34 0% ` lihuisong (C)
@ 2023-10-30 12:17 0% ` lihuisong (C)
2023-12-08 2:25 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-10-30 12:17 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, fengchengwen,
liudongdong3, liuyonglong
Hi Ferruh and Thomas,
This series have been discussing more than one year.
Kindly ping for reivew.
在 2023/10/9 18:34, lihuisong (C) 写道:
> Hi Ferruh and Thomas,
>
> Can you take a look at this series? They've been over a year on
> disscussion.
>
>
> 在 2023/8/2 11:15, Huisong Li 写道:
>> This patchset fix some bugs and support attaching and detaching port
>> in primary and secondary.
>>
>> ---
>> -v6: adjust rte_eth_dev_is_used position based on alphabetical order
>> in version.map
>> -v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi
>> break.
>> -v4: fix a misspelling.
>> -v3:
>> #1 merge patch 1/6 and patch 2/6 into patch 1/5, and add
>> modification
>> for other bus type.
>> #2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>> the probelm in patch 2/5.
>> -v2: resend due to CI unexplained failure.
>>
>> Huisong Li (5):
>> drivers/bus: restore driver assignment at front of probing
>> ethdev: fix skip valid port in probing callback
>> app/testpmd: check the validity of the port
>> app/testpmd: add attach and detach port for multiple process
>> app/testpmd: stop forwarding in new or destroy event
>>
>> app/test-pmd/testpmd.c | 47 +++++++++++++++---------
>> app/test-pmd/testpmd.h | 1 -
>> drivers/bus/auxiliary/auxiliary_common.c | 9 ++++-
>> drivers/bus/dpaa/dpaa_bus.c | 9 ++++-
>> drivers/bus/fslmc/fslmc_bus.c | 8 +++-
>> drivers/bus/ifpga/ifpga_bus.c | 12 ++++--
>> drivers/bus/pci/pci_common.c | 9 ++++-
>> drivers/bus/vdev/vdev.c | 10 ++++-
>> drivers/bus/vmbus/vmbus_common.c | 9 ++++-
>> drivers/net/bnxt/bnxt_ethdev.c | 3 +-
>> drivers/net/bonding/bonding_testpmd.c | 1 -
>> drivers/net/mlx5/mlx5.c | 2 +-
>> lib/ethdev/ethdev_driver.c | 13 +++++--
>> lib/ethdev/ethdev_driver.h | 12 ++++++
>> lib/ethdev/ethdev_pci.h | 2 +-
>> lib/ethdev/rte_class_eth.c | 2 +-
>> lib/ethdev/rte_ethdev.c | 4 +-
>> lib/ethdev/rte_ethdev.h | 4 +-
>> lib/ethdev/version.map | 1 +
>> 19 files changed, 114 insertions(+), 44 deletions(-)
>>
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH 1/3] net/tap: support infrastructure to build the BPF filter
@ 2023-10-31 22:08 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-31 22:08 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Move the BPF program related code into a subdirectory.
And add a Makefile for building it.
The code depends on include files from iproute2.
But these are not public headers which iproute2 exports
as a package API. Therefore make a local copy here.
The standalone build was also broken because by
commit ef5baf3486e0 ("replace packed attributes")
which introduced __rte_packed into this code.
Add a python program to extract the resulting BPF into
a format that can be consumed by the TAP driver.
Update the documentation.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/nics/tap.rst | 11 +-
drivers/net/tap/bpf/.gitignore | 1 +
drivers/net/tap/bpf/Makefile | 18 ++
drivers/net/tap/bpf/bpf_api.h | 275 ++++++++++++++++++++
drivers/net/tap/bpf/bpf_elf.h | 53 ++++
| 80 ++++++
drivers/net/tap/{ => bpf}/tap_bpf_program.c | 9 +-
| 2 +-
8 files changed, 437 insertions(+), 12 deletions(-)
create mode 100644 drivers/net/tap/bpf/.gitignore
create mode 100644 drivers/net/tap/bpf/Makefile
create mode 100644 drivers/net/tap/bpf/bpf_api.h
create mode 100644 drivers/net/tap/bpf/bpf_elf.h
create mode 100644 drivers/net/tap/bpf/bpf_extract.py
rename drivers/net/tap/{ => bpf}/tap_bpf_program.c (97%)
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 07df0d35a2..449e747994 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -256,15 +256,12 @@ C functions under different ELF sections.
2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
-3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+3. Use make to compile `tap_bpf_program.c`` via ``LLVM`` into an object file
+ and extract the resulting instructions into ``tap_bpf_insn.h``.
- clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
- -filetype=obj -o <tap_bpf_program.o>
+ cd bpf; make
-
-4. Use a tool that receives two parameters: an eBPF object file and a section
-name, and prints out the section as a C array of eBPF instructions.
-Embed the C array in your TAP PMD tree.
+4. Recompile the TAP PMD.
The C arrays are uploaded to the kernel using BPF system calls.
diff --git a/drivers/net/tap/bpf/.gitignore b/drivers/net/tap/bpf/.gitignore
new file mode 100644
index 0000000000..30a258f1af
--- /dev/null
+++ b/drivers/net/tap/bpf/.gitignore
@@ -0,0 +1 @@
+tap_bpf_program.o
diff --git a/drivers/net/tap/bpf/Makefile b/drivers/net/tap/bpf/Makefile
new file mode 100644
index 0000000000..e5ae4e1f5a
--- /dev/null
+++ b/drivers/net/tap/bpf/Makefile
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# This file is not built as part of normal DPDK build.
+# It is used to generate the eBPF code for TAP RSS.
+CLANG=clang
+CLANG_OPTS=-O2
+TARGET=../tap_bpf_insns.h
+
+all: $(TARGET)
+
+clean:
+ rm tap_bpf_program.o $(TARGET)
+
+tap_bpf_program.o: tap_bpf_program.c
+ $(CLANG) $(CLANG_OPTS) -emit-llvm -c $< -o - | \
+ llc -march=bpf -filetype=obj -o $@
+
+$(TARGET): bpf_extract.py tap_bpf_program.o
+ python3 bpf_extract.py tap_bpf_program.o $@
diff --git a/drivers/net/tap/bpf/bpf_api.h b/drivers/net/tap/bpf/bpf_api.h
new file mode 100644
index 0000000000..5887d3a851
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_api.h
@@ -0,0 +1,275 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_API__
+#define __BPF_API__
+
+/* Note:
+ *
+ * This file can be included into eBPF kernel programs. It contains
+ * a couple of useful helper functions, map/section ABI (bpf_elf.h),
+ * misc macros and some eBPF specific LLVM built-ins.
+ */
+
+#include <stdint.h>
+
+#include <linux/pkt_cls.h>
+#include <linux/bpf.h>
+#include <linux/filter.h>
+
+#include <asm/byteorder.h>
+
+#include "bpf_elf.h"
+
+/** libbpf pin type. */
+enum libbpf_pin_type {
+ LIBBPF_PIN_NONE,
+ /* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
+ LIBBPF_PIN_BY_NAME,
+};
+
+/** Type helper macros. */
+
+#define __uint(name, val) int (*name)[val]
+#define __type(name, val) typeof(val) *name
+#define __array(name, val) typeof(val) *name[]
+
+/** Misc macros. */
+
+#ifndef __stringify
+# define __stringify(X) #X
+#endif
+
+#ifndef __maybe_unused
+# define __maybe_unused __attribute__((__unused__))
+#endif
+
+#ifndef offsetof
+# define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
+#endif
+
+#ifndef likely
+# define likely(X) __builtin_expect(!!(X), 1)
+#endif
+
+#ifndef unlikely
+# define unlikely(X) __builtin_expect(!!(X), 0)
+#endif
+
+#ifndef htons
+# define htons(X) __constant_htons((X))
+#endif
+
+#ifndef ntohs
+# define ntohs(X) __constant_ntohs((X))
+#endif
+
+#ifndef htonl
+# define htonl(X) __constant_htonl((X))
+#endif
+
+#ifndef ntohl
+# define ntohl(X) __constant_ntohl((X))
+#endif
+
+#ifndef __inline__
+# define __inline__ __attribute__((always_inline))
+#endif
+
+/** Section helper macros. */
+
+#ifndef __section
+# define __section(NAME) \
+ __attribute__((section(NAME), used))
+#endif
+
+#ifndef __section_tail
+# define __section_tail(ID, KEY) \
+ __section(__stringify(ID) "/" __stringify(KEY))
+#endif
+
+#ifndef __section_xdp_entry
+# define __section_xdp_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_cls_entry
+# define __section_cls_entry \
+ __section(ELF_SECTION_CLASSIFIER)
+#endif
+
+#ifndef __section_act_entry
+# define __section_act_entry \
+ __section(ELF_SECTION_ACTION)
+#endif
+
+#ifndef __section_lwt_entry
+# define __section_lwt_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_license
+# define __section_license \
+ __section(ELF_SECTION_LICENSE)
+#endif
+
+#ifndef __section_maps
+# define __section_maps \
+ __section(ELF_SECTION_MAPS)
+#endif
+
+/** Declaration helper macros. */
+
+#ifndef BPF_LICENSE
+# define BPF_LICENSE(NAME) \
+ char ____license[] __section_license = NAME
+#endif
+
+/** Classifier helper */
+
+#ifndef BPF_H_DEFAULT
+# define BPF_H_DEFAULT -1
+#endif
+
+/** BPF helper functions for tc. Individual flags are in linux/bpf.h */
+
+#ifndef __BPF_FUNC
+# define __BPF_FUNC(NAME, ...) \
+ (* NAME)(__VA_ARGS__) __maybe_unused
+#endif
+
+#ifndef BPF_FUNC
+# define BPF_FUNC(NAME, ...) \
+ __BPF_FUNC(NAME, __VA_ARGS__) = (void *) BPF_FUNC_##NAME
+#endif
+
+/* Map access/manipulation */
+static void *BPF_FUNC(map_lookup_elem, void *map, const void *key);
+static int BPF_FUNC(map_update_elem, void *map, const void *key,
+ const void *value, uint32_t flags);
+static int BPF_FUNC(map_delete_elem, void *map, const void *key);
+
+/* Time access */
+static uint64_t BPF_FUNC(ktime_get_ns);
+
+/* Debugging */
+
+/* FIXME: __attribute__ ((format(printf, 1, 3))) not possible unless
+ * llvm bug https://llvm.org/bugs/show_bug.cgi?id=26243 gets resolved.
+ * It would require ____fmt to be made const, which generates a reloc
+ * entry (non-map).
+ */
+static void BPF_FUNC(trace_printk, const char *fmt, int fmt_size, ...);
+
+#ifndef printt
+# define printt(fmt, ...) \
+ ({ \
+ char ____fmt[] = fmt; \
+ trace_printk(____fmt, sizeof(____fmt), ##__VA_ARGS__); \
+ })
+#endif
+
+/* Random numbers */
+static uint32_t BPF_FUNC(get_prandom_u32);
+
+/* Tail calls */
+static void BPF_FUNC(tail_call, struct __sk_buff *skb, void *map,
+ uint32_t index);
+
+/* System helpers */
+static uint32_t BPF_FUNC(get_smp_processor_id);
+static uint32_t BPF_FUNC(get_numa_node_id);
+
+/* Packet misc meta data */
+static uint32_t BPF_FUNC(get_cgroup_classid, struct __sk_buff *skb);
+static int BPF_FUNC(skb_under_cgroup, void *map, uint32_t index);
+
+static uint32_t BPF_FUNC(get_route_realm, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(get_hash_recalc, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(set_hash_invalid, struct __sk_buff *skb);
+
+/* Packet redirection */
+static int BPF_FUNC(redirect, int ifindex, uint32_t flags);
+static int BPF_FUNC(clone_redirect, struct __sk_buff *skb, int ifindex,
+ uint32_t flags);
+
+/* Packet manipulation */
+static int BPF_FUNC(skb_load_bytes, struct __sk_buff *skb, uint32_t off,
+ void *to, uint32_t len);
+static int BPF_FUNC(skb_store_bytes, struct __sk_buff *skb, uint32_t off,
+ const void *from, uint32_t len, uint32_t flags);
+
+static int BPF_FUNC(l3_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(l4_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(csum_diff, const void *from, uint32_t from_size,
+ const void *to, uint32_t to_size, uint32_t seed);
+static int BPF_FUNC(csum_update, struct __sk_buff *skb, uint32_t wsum);
+
+static int BPF_FUNC(skb_change_type, struct __sk_buff *skb, uint32_t type);
+static int BPF_FUNC(skb_change_proto, struct __sk_buff *skb, uint32_t proto,
+ uint32_t flags);
+static int BPF_FUNC(skb_change_tail, struct __sk_buff *skb, uint32_t nlen,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_pull_data, struct __sk_buff *skb, uint32_t len);
+
+/* Event notification */
+static int __BPF_FUNC(skb_event_output, struct __sk_buff *skb, void *map,
+ uint64_t index, const void *data, uint32_t size) =
+ (void *) BPF_FUNC_perf_event_output;
+
+/* Packet vlan encap/decap */
+static int BPF_FUNC(skb_vlan_push, struct __sk_buff *skb, uint16_t proto,
+ uint16_t vlan_tci);
+static int BPF_FUNC(skb_vlan_pop, struct __sk_buff *skb);
+
+/* Packet tunnel encap/decap */
+static int BPF_FUNC(skb_get_tunnel_key, struct __sk_buff *skb,
+ struct bpf_tunnel_key *to, uint32_t size, uint32_t flags);
+static int BPF_FUNC(skb_set_tunnel_key, struct __sk_buff *skb,
+ const struct bpf_tunnel_key *from, uint32_t size,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_get_tunnel_opt, struct __sk_buff *skb,
+ void *to, uint32_t size);
+static int BPF_FUNC(skb_set_tunnel_opt, struct __sk_buff *skb,
+ const void *from, uint32_t size);
+
+/** LLVM built-ins, mem*() routines work for constant size */
+
+#ifndef lock_xadd
+# define lock_xadd(ptr, val) ((void) __sync_fetch_and_add(ptr, val))
+#endif
+
+#ifndef memset
+# define memset(s, c, n) __builtin_memset((s), (c), (n))
+#endif
+
+#ifndef memcpy
+# define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
+#endif
+
+#ifndef memmove
+# define memmove(d, s, n) __builtin_memmove((d), (s), (n))
+#endif
+
+/* FIXME: __builtin_memcmp() is not yet fully useable unless llvm bug
+ * https://llvm.org/bugs/show_bug.cgi?id=26218 gets resolved. Also
+ * this one would generate a reloc entry (non-map), otherwise.
+ */
+#if 0
+#ifndef memcmp
+# define memcmp(a, b, n) __builtin_memcmp((a), (b), (n))
+#endif
+#endif
+
+unsigned long long load_byte(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.byte");
+
+unsigned long long load_half(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.half");
+
+unsigned long long load_word(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.word");
+
+#endif /* __BPF_API__ */
diff --git a/drivers/net/tap/bpf/bpf_elf.h b/drivers/net/tap/bpf/bpf_elf.h
new file mode 100644
index 0000000000..ea8a11c95c
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_elf.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_ELF__
+#define __BPF_ELF__
+
+#include <asm/types.h>
+
+/* Note:
+ *
+ * Below ELF section names and bpf_elf_map structure definition
+ * are not (!) kernel ABI. It's rather a "contract" between the
+ * application and the BPF loader in tc. For compatibility, the
+ * section names should stay as-is. Introduction of aliases, if
+ * needed, are a possibility, though.
+ */
+
+/* ELF section names, etc */
+#define ELF_SECTION_LICENSE "license"
+#define ELF_SECTION_MAPS "maps"
+#define ELF_SECTION_PROG "prog"
+#define ELF_SECTION_CLASSIFIER "classifier"
+#define ELF_SECTION_ACTION "action"
+
+#define ELF_MAX_MAPS 64
+#define ELF_MAX_LICENSE_LEN 128
+
+/* Object pinning settings */
+#define PIN_NONE 0
+#define PIN_OBJECT_NS 1
+#define PIN_GLOBAL_NS 2
+
+/* ELF map definition */
+struct bpf_elf_map {
+ __u32 type;
+ __u32 size_key;
+ __u32 size_value;
+ __u32 max_elem;
+ __u32 flags;
+ __u32 id;
+ __u32 pinning;
+ __u32 inner_id;
+ __u32 inner_idx;
+};
+
+#define BPF_ANNOTATE_KV_PAIR(name, type_key, type_val) \
+ struct ____btf_map_##name { \
+ type_key key; \
+ type_val value; \
+ }; \
+ struct ____btf_map_##name \
+ __attribute__ ((section(".maps." #name), used)) \
+ ____btf_map_##name = { }
+
+#endif /* __BPF_ELF__ */
--git a/drivers/net/tap/bpf/bpf_extract.py b/drivers/net/tap/bpf/bpf_extract.py
new file mode 100644
index 0000000000..d79fc61020
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_extract.py
@@ -0,0 +1,80 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2023 Stephen Hemminger <stephen@networkplumber.org>
+
+import argparse
+import sys
+import struct
+from tempfile import TemporaryFile
+from elftools.elf.elffile import ELFFile
+
+
+def load_sections(elffile):
+ result = []
+ DATA = [("cls_q", "cls_q_insns"), ("l3_l4", "l3_l4_hash_insns")]
+ for name, tag in DATA:
+ section = elffile.get_section_by_name(name)
+ if section:
+ insns = struct.iter_unpack('<BBhL', section.data())
+ result.append([tag, insns])
+ return result
+
+
+def dump_sections(sections, out):
+ for name, insns in sections:
+ print(f'\nstatic const struct bpf_insn {name} = {{', file=out)
+ for bpf in insns:
+ code = bpf[0]
+ src = bpf[1] >> 4
+ dst = bpf[1] & 0xf
+ off = bpf[2]
+ imm = bpf[3]
+ print('\t{{{:#02x}, {:4d}, {:4d}, {:8d}, {:#010x}}},'.format(
+ code, dst, src, off, imm),
+ file=out)
+ print('};', file=out)
+
+
+def parse_args():
+ parser = argparse.ArgumentParser()
+ parser.add_argument("input",
+ nargs='+',
+ help="input object file path or '-' for stdin")
+ parser.add_argument("output", help="output C file path or '-' for stdout")
+ return parser.parse_args()
+
+
+def open_input(path):
+ if path == "-":
+ temp = TemporaryFile()
+ temp.write(sys.stdin.buffer.read())
+ return temp
+ return open(path, "rb")
+
+
+def open_output(path):
+ if path == "-":
+ return sys.stdout
+ return open(path, "w")
+
+
+def write_header(output):
+ print("/* SPDX-License-Identifier: BSD-3-Clause", file=output)
+ print(" * Compiled BPF instructions do not edit", file=output)
+ print(" */\n", file=output)
+ print("#include <tap_bpf.h>", file=output)
+
+
+def main():
+ args = parse_args()
+
+ output = open_output(args.output)
+ write_header(output)
+ for path in args.input:
+ elffile = ELFFile(open_input(path))
+ sections = load_sections(elffile)
+ dump_sections(sections, output)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/drivers/net/tap/tap_bpf_program.c b/drivers/net/tap/bpf/tap_bpf_program.c
similarity index 97%
rename from drivers/net/tap/tap_bpf_program.c
rename to drivers/net/tap/bpf/tap_bpf_program.c
index 20c310e5e7..ff6f1606fb 100644
--- a/drivers/net/tap/tap_bpf_program.c
+++ b/drivers/net/tap/bpf/tap_bpf_program.c
@@ -14,9 +14,10 @@
#include <linux/ipv6.h>
#include <linux/if_tunnel.h>
#include <linux/filter.h>
-#include <linux/bpf.h>
-#include "tap_rss.h"
+#include "bpf_api.h"
+#include "bpf_elf.h"
+#include "../tap_rss.h"
/** Create IPv4 address */
#define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
@@ -75,14 +76,14 @@ struct ipv4_l3_l4_tuple {
__u32 dst_addr;
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
struct ipv6_l3_l4_tuple {
__u8 src_addr[16];
__u8 dst_addr[16];
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
0xd1, 0x81, 0xc6, 0x2c,
--git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
index 48c151cf6b..dff46a012f 100644
--- a/drivers/net/tap/tap_rss.h
+++ b/drivers/net/tap/tap_rss.h
@@ -35,6 +35,6 @@ struct rss_key {
__u32 key_size;
__u32 queues[TAP_MAX_QUEUES];
__u32 nb_queues;
-} __rte_packed;
+} __attribute__((packed));
#endif /* _TAP_RSS_H_ */
--
2.41.0
^ permalink raw reply [relevance 4%]
* [PATCH v5 1/3] net/tap: support infrastructure to build the BPF filter
@ 2023-10-31 22:42 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-10-31 22:42 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Move the BPF program related code into a subdirectory.
And add a Makefile for building it.
The code depends on include files from iproute2.
But these are not public headers which iproute2 exports
as a package API. Therefore make a local copy here.
The standalone build was also broken because by
commit ef5baf3486e0 ("replace packed attributes")
which introduced __rte_packed into this code.
Add a python program to extract the resulting BPF into
a format that can be consumed by the TAP driver.
Update the documentation.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/nics/tap.rst | 11 +-
drivers/net/tap/bpf/.gitignore | 1 +
drivers/net/tap/bpf/Makefile | 18 ++
drivers/net/tap/bpf/bpf_api.h | 275 ++++++++++++++++++++
drivers/net/tap/bpf/bpf_elf.h | 53 ++++
| 86 ++++++
drivers/net/tap/{ => bpf}/tap_bpf_program.c | 10 +-
| 2 +-
8 files changed, 444 insertions(+), 12 deletions(-)
create mode 100644 drivers/net/tap/bpf/.gitignore
create mode 100644 drivers/net/tap/bpf/Makefile
create mode 100644 drivers/net/tap/bpf/bpf_api.h
create mode 100644 drivers/net/tap/bpf/bpf_elf.h
create mode 100644 drivers/net/tap/bpf/bpf_extract.py
rename drivers/net/tap/{ => bpf}/tap_bpf_program.c (96%)
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 07df0d35a2..449e747994 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -256,15 +256,12 @@ C functions under different ELF sections.
2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
-3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+3. Use make to compile `tap_bpf_program.c`` via ``LLVM`` into an object file
+ and extract the resulting instructions into ``tap_bpf_insn.h``.
- clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
- -filetype=obj -o <tap_bpf_program.o>
+ cd bpf; make
-
-4. Use a tool that receives two parameters: an eBPF object file and a section
-name, and prints out the section as a C array of eBPF instructions.
-Embed the C array in your TAP PMD tree.
+4. Recompile the TAP PMD.
The C arrays are uploaded to the kernel using BPF system calls.
diff --git a/drivers/net/tap/bpf/.gitignore b/drivers/net/tap/bpf/.gitignore
new file mode 100644
index 0000000000..30a258f1af
--- /dev/null
+++ b/drivers/net/tap/bpf/.gitignore
@@ -0,0 +1 @@
+tap_bpf_program.o
diff --git a/drivers/net/tap/bpf/Makefile b/drivers/net/tap/bpf/Makefile
new file mode 100644
index 0000000000..e5ae4e1f5a
--- /dev/null
+++ b/drivers/net/tap/bpf/Makefile
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# This file is not built as part of normal DPDK build.
+# It is used to generate the eBPF code for TAP RSS.
+CLANG=clang
+CLANG_OPTS=-O2
+TARGET=../tap_bpf_insns.h
+
+all: $(TARGET)
+
+clean:
+ rm tap_bpf_program.o $(TARGET)
+
+tap_bpf_program.o: tap_bpf_program.c
+ $(CLANG) $(CLANG_OPTS) -emit-llvm -c $< -o - | \
+ llc -march=bpf -filetype=obj -o $@
+
+$(TARGET): bpf_extract.py tap_bpf_program.o
+ python3 bpf_extract.py tap_bpf_program.o $@
diff --git a/drivers/net/tap/bpf/bpf_api.h b/drivers/net/tap/bpf/bpf_api.h
new file mode 100644
index 0000000000..5887d3a851
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_api.h
@@ -0,0 +1,275 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_API__
+#define __BPF_API__
+
+/* Note:
+ *
+ * This file can be included into eBPF kernel programs. It contains
+ * a couple of useful helper functions, map/section ABI (bpf_elf.h),
+ * misc macros and some eBPF specific LLVM built-ins.
+ */
+
+#include <stdint.h>
+
+#include <linux/pkt_cls.h>
+#include <linux/bpf.h>
+#include <linux/filter.h>
+
+#include <asm/byteorder.h>
+
+#include "bpf_elf.h"
+
+/** libbpf pin type. */
+enum libbpf_pin_type {
+ LIBBPF_PIN_NONE,
+ /* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
+ LIBBPF_PIN_BY_NAME,
+};
+
+/** Type helper macros. */
+
+#define __uint(name, val) int (*name)[val]
+#define __type(name, val) typeof(val) *name
+#define __array(name, val) typeof(val) *name[]
+
+/** Misc macros. */
+
+#ifndef __stringify
+# define __stringify(X) #X
+#endif
+
+#ifndef __maybe_unused
+# define __maybe_unused __attribute__((__unused__))
+#endif
+
+#ifndef offsetof
+# define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
+#endif
+
+#ifndef likely
+# define likely(X) __builtin_expect(!!(X), 1)
+#endif
+
+#ifndef unlikely
+# define unlikely(X) __builtin_expect(!!(X), 0)
+#endif
+
+#ifndef htons
+# define htons(X) __constant_htons((X))
+#endif
+
+#ifndef ntohs
+# define ntohs(X) __constant_ntohs((X))
+#endif
+
+#ifndef htonl
+# define htonl(X) __constant_htonl((X))
+#endif
+
+#ifndef ntohl
+# define ntohl(X) __constant_ntohl((X))
+#endif
+
+#ifndef __inline__
+# define __inline__ __attribute__((always_inline))
+#endif
+
+/** Section helper macros. */
+
+#ifndef __section
+# define __section(NAME) \
+ __attribute__((section(NAME), used))
+#endif
+
+#ifndef __section_tail
+# define __section_tail(ID, KEY) \
+ __section(__stringify(ID) "/" __stringify(KEY))
+#endif
+
+#ifndef __section_xdp_entry
+# define __section_xdp_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_cls_entry
+# define __section_cls_entry \
+ __section(ELF_SECTION_CLASSIFIER)
+#endif
+
+#ifndef __section_act_entry
+# define __section_act_entry \
+ __section(ELF_SECTION_ACTION)
+#endif
+
+#ifndef __section_lwt_entry
+# define __section_lwt_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_license
+# define __section_license \
+ __section(ELF_SECTION_LICENSE)
+#endif
+
+#ifndef __section_maps
+# define __section_maps \
+ __section(ELF_SECTION_MAPS)
+#endif
+
+/** Declaration helper macros. */
+
+#ifndef BPF_LICENSE
+# define BPF_LICENSE(NAME) \
+ char ____license[] __section_license = NAME
+#endif
+
+/** Classifier helper */
+
+#ifndef BPF_H_DEFAULT
+# define BPF_H_DEFAULT -1
+#endif
+
+/** BPF helper functions for tc. Individual flags are in linux/bpf.h */
+
+#ifndef __BPF_FUNC
+# define __BPF_FUNC(NAME, ...) \
+ (* NAME)(__VA_ARGS__) __maybe_unused
+#endif
+
+#ifndef BPF_FUNC
+# define BPF_FUNC(NAME, ...) \
+ __BPF_FUNC(NAME, __VA_ARGS__) = (void *) BPF_FUNC_##NAME
+#endif
+
+/* Map access/manipulation */
+static void *BPF_FUNC(map_lookup_elem, void *map, const void *key);
+static int BPF_FUNC(map_update_elem, void *map, const void *key,
+ const void *value, uint32_t flags);
+static int BPF_FUNC(map_delete_elem, void *map, const void *key);
+
+/* Time access */
+static uint64_t BPF_FUNC(ktime_get_ns);
+
+/* Debugging */
+
+/* FIXME: __attribute__ ((format(printf, 1, 3))) not possible unless
+ * llvm bug https://llvm.org/bugs/show_bug.cgi?id=26243 gets resolved.
+ * It would require ____fmt to be made const, which generates a reloc
+ * entry (non-map).
+ */
+static void BPF_FUNC(trace_printk, const char *fmt, int fmt_size, ...);
+
+#ifndef printt
+# define printt(fmt, ...) \
+ ({ \
+ char ____fmt[] = fmt; \
+ trace_printk(____fmt, sizeof(____fmt), ##__VA_ARGS__); \
+ })
+#endif
+
+/* Random numbers */
+static uint32_t BPF_FUNC(get_prandom_u32);
+
+/* Tail calls */
+static void BPF_FUNC(tail_call, struct __sk_buff *skb, void *map,
+ uint32_t index);
+
+/* System helpers */
+static uint32_t BPF_FUNC(get_smp_processor_id);
+static uint32_t BPF_FUNC(get_numa_node_id);
+
+/* Packet misc meta data */
+static uint32_t BPF_FUNC(get_cgroup_classid, struct __sk_buff *skb);
+static int BPF_FUNC(skb_under_cgroup, void *map, uint32_t index);
+
+static uint32_t BPF_FUNC(get_route_realm, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(get_hash_recalc, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(set_hash_invalid, struct __sk_buff *skb);
+
+/* Packet redirection */
+static int BPF_FUNC(redirect, int ifindex, uint32_t flags);
+static int BPF_FUNC(clone_redirect, struct __sk_buff *skb, int ifindex,
+ uint32_t flags);
+
+/* Packet manipulation */
+static int BPF_FUNC(skb_load_bytes, struct __sk_buff *skb, uint32_t off,
+ void *to, uint32_t len);
+static int BPF_FUNC(skb_store_bytes, struct __sk_buff *skb, uint32_t off,
+ const void *from, uint32_t len, uint32_t flags);
+
+static int BPF_FUNC(l3_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(l4_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(csum_diff, const void *from, uint32_t from_size,
+ const void *to, uint32_t to_size, uint32_t seed);
+static int BPF_FUNC(csum_update, struct __sk_buff *skb, uint32_t wsum);
+
+static int BPF_FUNC(skb_change_type, struct __sk_buff *skb, uint32_t type);
+static int BPF_FUNC(skb_change_proto, struct __sk_buff *skb, uint32_t proto,
+ uint32_t flags);
+static int BPF_FUNC(skb_change_tail, struct __sk_buff *skb, uint32_t nlen,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_pull_data, struct __sk_buff *skb, uint32_t len);
+
+/* Event notification */
+static int __BPF_FUNC(skb_event_output, struct __sk_buff *skb, void *map,
+ uint64_t index, const void *data, uint32_t size) =
+ (void *) BPF_FUNC_perf_event_output;
+
+/* Packet vlan encap/decap */
+static int BPF_FUNC(skb_vlan_push, struct __sk_buff *skb, uint16_t proto,
+ uint16_t vlan_tci);
+static int BPF_FUNC(skb_vlan_pop, struct __sk_buff *skb);
+
+/* Packet tunnel encap/decap */
+static int BPF_FUNC(skb_get_tunnel_key, struct __sk_buff *skb,
+ struct bpf_tunnel_key *to, uint32_t size, uint32_t flags);
+static int BPF_FUNC(skb_set_tunnel_key, struct __sk_buff *skb,
+ const struct bpf_tunnel_key *from, uint32_t size,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_get_tunnel_opt, struct __sk_buff *skb,
+ void *to, uint32_t size);
+static int BPF_FUNC(skb_set_tunnel_opt, struct __sk_buff *skb,
+ const void *from, uint32_t size);
+
+/** LLVM built-ins, mem*() routines work for constant size */
+
+#ifndef lock_xadd
+# define lock_xadd(ptr, val) ((void) __sync_fetch_and_add(ptr, val))
+#endif
+
+#ifndef memset
+# define memset(s, c, n) __builtin_memset((s), (c), (n))
+#endif
+
+#ifndef memcpy
+# define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
+#endif
+
+#ifndef memmove
+# define memmove(d, s, n) __builtin_memmove((d), (s), (n))
+#endif
+
+/* FIXME: __builtin_memcmp() is not yet fully useable unless llvm bug
+ * https://llvm.org/bugs/show_bug.cgi?id=26218 gets resolved. Also
+ * this one would generate a reloc entry (non-map), otherwise.
+ */
+#if 0
+#ifndef memcmp
+# define memcmp(a, b, n) __builtin_memcmp((a), (b), (n))
+#endif
+#endif
+
+unsigned long long load_byte(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.byte");
+
+unsigned long long load_half(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.half");
+
+unsigned long long load_word(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.word");
+
+#endif /* __BPF_API__ */
diff --git a/drivers/net/tap/bpf/bpf_elf.h b/drivers/net/tap/bpf/bpf_elf.h
new file mode 100644
index 0000000000..ea8a11c95c
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_elf.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_ELF__
+#define __BPF_ELF__
+
+#include <asm/types.h>
+
+/* Note:
+ *
+ * Below ELF section names and bpf_elf_map structure definition
+ * are not (!) kernel ABI. It's rather a "contract" between the
+ * application and the BPF loader in tc. For compatibility, the
+ * section names should stay as-is. Introduction of aliases, if
+ * needed, are a possibility, though.
+ */
+
+/* ELF section names, etc */
+#define ELF_SECTION_LICENSE "license"
+#define ELF_SECTION_MAPS "maps"
+#define ELF_SECTION_PROG "prog"
+#define ELF_SECTION_CLASSIFIER "classifier"
+#define ELF_SECTION_ACTION "action"
+
+#define ELF_MAX_MAPS 64
+#define ELF_MAX_LICENSE_LEN 128
+
+/* Object pinning settings */
+#define PIN_NONE 0
+#define PIN_OBJECT_NS 1
+#define PIN_GLOBAL_NS 2
+
+/* ELF map definition */
+struct bpf_elf_map {
+ __u32 type;
+ __u32 size_key;
+ __u32 size_value;
+ __u32 max_elem;
+ __u32 flags;
+ __u32 id;
+ __u32 pinning;
+ __u32 inner_id;
+ __u32 inner_idx;
+};
+
+#define BPF_ANNOTATE_KV_PAIR(name, type_key, type_val) \
+ struct ____btf_map_##name { \
+ type_key key; \
+ type_val value; \
+ }; \
+ struct ____btf_map_##name \
+ __attribute__ ((section(".maps." #name), used)) \
+ ____btf_map_##name = { }
+
+#endif /* __BPF_ELF__ */
--git a/drivers/net/tap/bpf/bpf_extract.py b/drivers/net/tap/bpf/bpf_extract.py
new file mode 100644
index 0000000000..5e1aee38c8
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_extract.py
@@ -0,0 +1,86 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2023 Stephen Hemminger <stephen@networkplumber.org>
+
+import argparse
+import sys
+import struct
+from tempfile import TemporaryFile
+from elftools.elf.elffile import ELFFile
+
+
+def load_sections(elffile):
+ """Get sections of interest from ELF"""
+ result = []
+ DATA = [("cls_q", "cls_q_insns"), ("l3_l4", "l3_l4_hash_insns")]
+ for name, tag in DATA:
+ section = elffile.get_section_by_name(name)
+ if section:
+ insns = struct.iter_unpack('<BBhL', section.data())
+ result.append([tag, insns])
+ return result
+
+
+def dump_section(name, insns, out):
+ """Dump the array of BPF instructructions"""
+ print(f'\nstatic struct bpf_insn {name}[] = {{', file=out)
+ for bpf in insns:
+ code = bpf[0]
+ src = bpf[1] >> 4
+ dst = bpf[1] & 0xf
+ off = bpf[2]
+ imm = bpf[3]
+ print(f'\t{{{code:#02x}, {dst:4d}, {src:4d}, {off:8d}, {imm:#010x}}},',
+ file=out)
+ print('};', file=out)
+
+
+def parse_args():
+ """Parse command line arguments"""
+ parser = argparse.ArgumentParser()
+ parser.add_argument("input",
+ nargs='+',
+ help="input object file path or '-' for stdin")
+ parser.add_argument("output", help="output C file path or '-' for stdout")
+ return parser.parse_args()
+
+
+def open_input(path):
+ """Open the input file or stdin"""
+ if path == "-":
+ temp = TemporaryFile()
+ temp.write(sys.stdin.buffer.read())
+ return temp
+ return open(path, "rb")
+
+
+def open_output(path):
+ """Open the output file or stdout"""
+ if path == "-":
+ return sys.stdout
+ return open(path, "w")
+
+
+def write_header(output):
+ """Write file intro header"""
+ print("/* SPDX-License-Identifier: BSD-3-Clause", file=output)
+ print(" * Compiled BPF instructions do not edit", file=output)
+ print(" */\n", file=output)
+ print("#include <tap_bpf.h>", file=output)
+
+
+def main():
+ '''program main function'''
+ args = parse_args()
+
+ output = open_output(args.output)
+ write_header(output)
+ for path in args.input:
+ elffile = ELFFile(open_input(path))
+ sections = load_sections(elffile)
+ for name, insns in sections:
+ dump_section(name, insns, output)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/drivers/net/tap/tap_bpf_program.c b/drivers/net/tap/bpf/tap_bpf_program.c
similarity index 96%
rename from drivers/net/tap/tap_bpf_program.c
rename to drivers/net/tap/bpf/tap_bpf_program.c
index 20c310e5e7..d65021d8a1 100644
--- a/drivers/net/tap/tap_bpf_program.c
+++ b/drivers/net/tap/bpf/tap_bpf_program.c
@@ -14,9 +14,10 @@
#include <linux/ipv6.h>
#include <linux/if_tunnel.h>
#include <linux/filter.h>
-#include <linux/bpf.h>
-#include "tap_rss.h"
+#include "bpf_api.h"
+#include "bpf_elf.h"
+#include "../tap_rss.h"
/** Create IPv4 address */
#define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
@@ -56,6 +57,7 @@ __section("cls_q") int
match_q(struct __sk_buff *skb)
{
__u32 queue = skb->cb[1];
+ /* queue is set by tap_flow_bpf_cls_q() before load */
volatile __u32 q = 0xdeadbeef;
__u32 match_queue = QUEUE_OFFSET + q;
@@ -75,14 +77,14 @@ struct ipv4_l3_l4_tuple {
__u32 dst_addr;
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
struct ipv6_l3_l4_tuple {
__u8 src_addr[16];
__u8 dst_addr[16];
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
0xd1, 0x81, 0xc6, 0x2c,
--git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
index 48c151cf6b..dff46a012f 100644
--- a/drivers/net/tap/tap_rss.h
+++ b/drivers/net/tap/tap_rss.h
@@ -35,6 +35,6 @@ struct rss_key {
__u32 key_size;
__u32 queues[TAP_MAX_QUEUES];
__u32 nb_queues;
-} __rte_packed;
+} __attribute__((packed));
#endif /* _TAP_RSS_H_ */
--
2.41.0
^ permalink raw reply [relevance 4%]
* Re: release candidate 23.11-rc1
2023-10-17 20:36 4% release candidate 23.11-rc1 Thomas Monjalon
[not found] ` <MW4PR11MB5912D298978501DAC2092EA49FD4A@MW4PR11MB5912.namprd11.prod.outlook.com>
@ 2023-10-31 23:15 0% ` Thinh Tran
1 sibling, 0 replies; 200+ results
From: Thinh Tran @ 2023-10-31 23:15 UTC (permalink / raw)
To: Thomas Monjalon, dpdk-dev
IBM - Power Systems
DPDK v23.11-rc1-29-g32faaf3073
* Build CI on Fedora 30,31,34,36,37,38 for ppc64le
* Basic PF on Mellanox: No issue found
* Performance: not tested.
* OS: RHEL 9.2 kernel: 5.14.0-284.25.1.el9_2.ppc64le
with gcc version 11.3.1 20221121 (Red Hat 11.3.1-4) (GCC)
RHEL 8.6 kernel: 4.18.0-348.el8.ppc64le
with gcc version 8.5.0 20210514 (Red Hat 8.5.0-10) (GCC)
Systems tested:
- LPARs on IBM Power10 CHRP IBM,9105-22A
NICs:
- Mellanox Mellanox Technologies MT2894 Family [ConnectX-6 Lx]
- firmware version: 26.38.1002
- MMLNX_OFED_LINUX-23.07-0.5.0.2
Regards,
Thinh Tran
On 10/17/2023 3:36 PM, Thomas Monjalon wrote:
> A new DPDK release candidate is ready for testing:
> https://git.dpdk.org/dpdk/tag/?id=v23.11-rc1
>
> There are 617 new patches in this snapshot,
> including many API/ABI compatibility breakages.
> This release won't be ABI-compatible with previous ones.
>
> Release notes:
> https://doc.dpdk.org/guides/rel_notes/release_23_11.html
>
> Highlights of 23.11-rc1:
> - build requires C11 compiler
> - early support of MSVC build
> - new atomic operations API
> - power management on AMD CPU
> - mbuf recycling
> - flow action type for P4-defined actions
> - flow group miss action
> - flow item for packet type matching
> - TLS record offload
> - security Rx inject
> - eventdev link profiles
> - eventdev adapter for dmadev
> - event dispatcher library
>
> Please test and report issues on bugs.dpdk.org.
>
> DPDK 23.11-rc2 is expected in approximately two weeks.
>
> Thank you everyone
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7 0/9] support setting and querying RSS algorithms
2023-10-28 1:46 3% ` [PATCH v7 0/9] support setting and querying RSS algorithms Jie Hai
2023-10-28 1:46 4% ` [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-11-01 2:04 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-11-01 2:04 UTC (permalink / raw)
To: Jie Hai, dev; +Cc: lihuisong, fengchengwen, liudongdong3
On 10/28/2023 2:46 AM, Jie Hai wrote:
> This patchset is to support setting and querying RSS algorithms.
> For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
> and field "algorithm" is added to ``rte_eth_rss_conf``.
> The drivers should reports their "rss_algo_capa" if they support
> updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
> by field "algorithm" and the related API should verify "algorithm" with
> "rss_algo_capa".
>
> --
> v7:
> 1. fix compile error.
> 2. add signed-off-by to patch[4/9].
> v6:
> 1. rewrite some comments.
> 2. add "rss_algo_capa" for `rte_eth_dev_info``.
> 3. add new API to get name of RSS algorithms
>
> v5:
> 1. rewrite some comments.
> 2. check RSS algorithm for drivers supporting RSS.
> 3. change field "func" of rss_conf to "algorithm".
> 4. fix commit log for [PATCH v4 4/7].
> 5. add Acked-by Reshma Pattan.
> 6. add symmetric_toeplitz_sort for showing.
> 7. change "hf" to "hash function" for showing.
>
> v4:
> 1. recomment some definitions related to RSS.
> 2. allocate static memory for rss_key instead of dynamic.
> 3. use array of strings to get the name of rss algorithm.
> 4. add display of rss algorithm with testpmd.
>
> v3:
> 1. fix commit log for PATCH [1/5].
> 2. make RSS ABI changes description to start the actual text at the margin.
> 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
> 4. fix some comment codes.
>
> v2:
> 1. return error if "func" is invalid.
> 2. modify the comments of the "func" field.
> 3. modify commit log of patch [3/5].
> 4. use malloc instead of rte_malloc.
> 5. adjust display format of RSS info.
> 6. remove the string display of rss_hf.
>
> Huisong Li (1):
> net/hns3: support setting and querying RSS hash function
>
> Jie Hai (8):
> ethdev: overwrite some comment related to RSS
> ethdev: support setting and querying RSS algorithm
> net/hns3: report RSS hash algorithms capability
> app/proc-info: fix never show RSS info
> app/proc-info: adjust the display format of RSS info
> lib/ethdev: add API to get RSS algorithm names
> app/proc-info: support querying RSS hash algorithm
> app/testpmd: add RSS hash algorithms display
>
Hi Jie,
Patchset mostly looks good to me, new capability in dev_info approach is
better, but only I put some comments in the new API patch, can you
please check it, rest looks good but please send new version as whole
patchset.
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm
2023-11-01 7:40 3% ` [PATCH v8 00/10] " Jie Hai
@ 2023-11-01 7:40 4% ` Jie Hai
2023-11-01 13:36 3% ` Ferruh Yigit
2023-11-01 9:44 0% ` [PATCH v8 00/10] support setting and querying RSS algorithms fengchengwen
1 sibling, 1 reply; 200+ results
From: Jie Hai @ 2023-11-01 7:40 UTC (permalink / raw)
To: haijie1, dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_dev_info`` is extended by adding a new
field "rss_algo_capa". Drivers are responsible for reporting this
capa and configurations of RSS hash algorithm can be verified based
on the capability. The default value of "rss_algo_capa" is
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
If the value of "algorithm" used for configuration is a gibberish
value, drivers should report the error.
To check whether the drivers report valid "algorithm", it is set
to default value before querying in rte_eth_dev_rss_hash_conf_get().
Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 5 +++++
lib/ethdev/rte_ethdev.c | 26 +++++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 29 ++++++++++++++++++++++++++
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 26 ++---------------------
5 files changed, 62 insertions(+), 25 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 95db98d098d8..e207786044f9 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -372,6 +372,11 @@ ABI Changes
* security: struct ``rte_security_ipsec_sa_options`` was updated
due to inline out-of-place feature addition.
+* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
+* reporting RSS hash algorithm capability.
+
+* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm.
Known Issues
------------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 07bb35833ba6..f9bd99d07eb1 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1269,6 +1269,7 @@ int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
{
+ enum rte_eth_hash_function algorithm;
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
struct rte_eth_conf orig_conf;
@@ -1510,6 +1511,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
+ if (RTE_ETH_HASH_ALGO_TO_CAPA(algorithm) == 0 ||
+ (dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u configured RSS hash algorithm (%u)"
+ "is not in the algorithm capability (0x%" PRIx32 ")\n",
+ port_id, algorithm, dev_info.rss_algo_capa);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/*
* Setup new number of Rx/Tx queues and reconfigure device.
*/
@@ -3767,6 +3780,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
RTE_ETHER_CRC_LEN;
dev_info->max_mtu = UINT16_MAX;
+ dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
if (*dev->dev_ops->dev_infos_get == NULL)
return -ENOTSUP;
@@ -4716,6 +4730,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -EINVAL;
}
+ if (RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm) == 0 ||
+ (dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u configured RSS hash algorithm (%u)"
+ "is not in the algorithm capability (0x%" PRIx32 ")\n",
+ port_id, rss_conf->algorithm, dev_info.rss_algo_capa);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4756,6 +4780,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 343a134fdd12..76c45bd759e4 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /** DEFAULT means driver decides which hash algorithm to pick. */
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+ * Symmetric Toeplitz: src, dst will be replaced by
+ * xor(src, dst). For the case with src/dst only,
+ * src or dst address will xor with zero pair.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ /**
+ * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
+ * the hash function.
+ * If src_ip > dst_ip, swap src_ip and dst_ip.
+ * If src_port > dst_port, swap src_port and dst_port.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
+#define RTE_ETH_HASH_ALGO_CAPA_MASK(x) RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -470,6 +497,7 @@ struct rte_eth_rss_conf {
* which RSS hashing is to be applied.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
};
/*
@@ -1750,6 +1778,7 @@ struct rte_eth_dev_info {
/** Device redirection table size, the total number of entries. */
uint16_t reta_size;
uint8_t hash_key_size; /**< Hash key size in bytes */
+ uint32_t rss_algo_capa; /** RSS hash algorithms capabilities */
/** Bit mask of RSS offloads, the bit offset also means flow type */
uint64_t flow_type_rss_offloads;
struct rte_eth_rxconf default_rxconf; /**< Default Rx configuration */
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 4d6c28ee0eb2..e2468cd351ab 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -13,7 +13,6 @@
#include <rte_branch_prediction.h>
#include <rte_string_fns.h>
#include <rte_mbuf_dyn.h>
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 751c29a0f3f3..affdc8121b57 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -40,6 +40,8 @@
#include <rte_macsec.h>
#include <rte_ib.h>
+#include "rte_ethdev.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
uint64_t bytes; /**< Number of bytes through this rule [out]. */
};
-/**
- * Hash function types.
- */
-enum rte_eth_hash_function {
- /** DEFAULT means driver decides which hash algorithm to pick. */
- RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
- RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
- RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
- /**
- * Symmetric Toeplitz: src, dst will be replaced by
- * xor(src, dst). For the case with src/dst only,
- * src or dst address will xor with zero pair.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
- /**
- * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
- * the hash function.
- * If src_ip > dst_ip, swap src_ip and dst_ip.
- * If src_port > dst_port, swap src_port and dst_port.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
- RTE_ETH_HASH_FUNCTION_MAX,
-};
-
/**
* RTE_FLOW_ACTION_TYPE_RSS
*
--
2.30.0
^ permalink raw reply [relevance 4%]
* [PATCH v8 00/10] support setting and querying RSS algorithms
@ 2023-11-01 7:40 3% ` Jie Hai
2023-11-01 7:40 4% ` [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm Jie Hai
2023-11-01 9:44 0% ` [PATCH v8 00/10] support setting and querying RSS algorithms fengchengwen
2023-11-02 8:20 3% ` [PATCH v9 0/9] " Jie Hai
1 sibling, 2 replies; 200+ results
From: Jie Hai @ 2023-11-01 7:40 UTC (permalink / raw)
To: haijie1, dev; +Cc: lihuisong, fengchengwen, liudongdong3
This patchset is to support setting and querying RSS algorithms.
For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
and field "algorithm" is added to ``rte_eth_rss_conf``.
The drivers should reports their "rss_algo_capa" if they support
updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
by field "algorithm" and the related API should verify "algorithm" with
"rss_algo_capa".
--
v8:
1. rewrite some comments.
2. add check for rss_key_len in ethdev level.
3. add Acked-by: Huisong Li <lihuisong@huawei.com>.
4. fix log on RSS hash algorithm.
5. add rte_eth_dev_rss_algo_name to lib/ethdev/version.map.
6. fix RSS algorithm display on testpmd.
v7:
1. fix compile error.
2. add signed-off-by to patch[4/9].
v6:
1. rewrite some comments.
2. add "rss_algo_capa" for `rte_eth_dev_info``.
3. add new API to get name of RSS algorithms
v5:
1. rewrite some comments.
2. check RSS algorithm for drivers supporting RSS.
3. change field "func" of rss_conf to "algorithm".
4. fix commit log for [PATCH v4 4/7].
5. add Acked-by Reshma Pattan.
6. add symmetric_toeplitz_sort for showing.
7. change "hf" to "hash function" for showing.
v4:
1. recomment some definitions related to RSS.
2. allocate static memory for rss_key instead of dynamic.
3. use array of strings to get the name of rss algorithm.
4. add display of rss algorithm with testpmd.
v3:
1. fix commit log for PATCH [1/5].
2. make RSS ABI changes description to start the actual text at the margin.
3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
4. fix some comment codes.
v2:
1. return error if "func" is invalid.
2. modify the comments of the "func" field.
3. modify commit log of patch [3/5].
4. use malloc instead of rte_malloc.
5. adjust display format of RSS info.
6. remove the string display of rss_hf.
Huisong Li (1):
net/hns3: support setting and querying RSS hash function
Jie Hai (9):
ethdev: overwrite some comment related to RSS
lib/ethdev: check RSS key length
ethdev: support setting and querying RSS algorithm
net/hns3: report RSS hash algorithms capability
app/proc-info: fix never show RSS info
app/proc-info: adjust the display format of RSS info
ethdev: add API to get RSS algorithm names
app/proc-info: support querying RSS hash algorithm
app/testpmd: add RSS hash algorithms display
app/proc-info/main.c | 24 +++++---
app/test-pmd/cmdline.c | 29 +++++++--
app/test-pmd/config.c | 29 ++++-----
app/test-pmd/testpmd.h | 2 +-
doc/guides/rel_notes/release_23_11.rst | 9 +++
drivers/net/hns3/hns3_common.c | 4 ++
drivers/net/hns3/hns3_rss.c | 47 ++++++++-------
lib/ethdev/rte_ethdev.c | 82 ++++++++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 79 ++++++++++++++++++++-----
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 25 +-------
lib/ethdev/version.map | 1 +
12 files changed, 239 insertions(+), 93 deletions(-)
--
2.30.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH v8 00/10] support setting and querying RSS algorithms
2023-11-01 7:40 3% ` [PATCH v8 00/10] " Jie Hai
2023-11-01 7:40 4% ` [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-11-01 9:44 0% ` fengchengwen
1 sibling, 0 replies; 200+ results
From: fengchengwen @ 2023-11-01 9:44 UTC (permalink / raw)
To: Jie Hai, dev; +Cc: lihuisong, liudongdong3
LGTM
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
On 2023/11/1 15:40, Jie Hai wrote:
> This patchset is to support setting and querying RSS algorithms.
> For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
> and field "algorithm" is added to ``rte_eth_rss_conf``.
> The drivers should reports their "rss_algo_capa" if they support
> updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
> by field "algorithm" and the related API should verify "algorithm" with
> "rss_algo_capa".
>
> --
> v8:
> 1. rewrite some comments.
> 2. add check for rss_key_len in ethdev level.
> 3. add Acked-by: Huisong Li <lihuisong@huawei.com>.
> 4. fix log on RSS hash algorithm.
> 5. add rte_eth_dev_rss_algo_name to lib/ethdev/version.map.
> 6. fix RSS algorithm display on testpmd.
>
> v7:
> 1. fix compile error.
> 2. add signed-off-by to patch[4/9].
> v6:
> 1. rewrite some comments.
> 2. add "rss_algo_capa" for `rte_eth_dev_info``.
> 3. add new API to get name of RSS algorithms
>
> v5:
> 1. rewrite some comments.
> 2. check RSS algorithm for drivers supporting RSS.
> 3. change field "func" of rss_conf to "algorithm".
> 4. fix commit log for [PATCH v4 4/7].
> 5. add Acked-by Reshma Pattan.
> 6. add symmetric_toeplitz_sort for showing.
> 7. change "hf" to "hash function" for showing.
>
> v4:
> 1. recomment some definitions related to RSS.
> 2. allocate static memory for rss_key instead of dynamic.
> 3. use array of strings to get the name of rss algorithm.
> 4. add display of rss algorithm with testpmd.
>
> v3:
> 1. fix commit log for PATCH [1/5].
> 2. make RSS ABI changes description to start the actual text at the margin.
> 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
> 4. fix some comment codes.
>
> v2:
> 1. return error if "func" is invalid.
> 2. modify the comments of the "func" field.
> 3. modify commit log of patch [3/5].
> 4. use malloc instead of rte_malloc.
> 5. adjust display format of RSS info.
> 6. remove the string display of rss_hf.
>
> Huisong Li (1):
> net/hns3: support setting and querying RSS hash function
>
> Jie Hai (9):
> ethdev: overwrite some comment related to RSS
> lib/ethdev: check RSS key length
> ethdev: support setting and querying RSS algorithm
> net/hns3: report RSS hash algorithms capability
> app/proc-info: fix never show RSS info
> app/proc-info: adjust the display format of RSS info
> ethdev: add API to get RSS algorithm names
> app/proc-info: support querying RSS hash algorithm
> app/testpmd: add RSS hash algorithms display
>
> app/proc-info/main.c | 24 +++++---
> app/test-pmd/cmdline.c | 29 +++++++--
> app/test-pmd/config.c | 29 ++++-----
> app/test-pmd/testpmd.h | 2 +-
> doc/guides/rel_notes/release_23_11.rst | 9 +++
> drivers/net/hns3/hns3_common.c | 4 ++
> drivers/net/hns3/hns3_rss.c | 47 ++++++++-------
> lib/ethdev/rte_ethdev.c | 82 ++++++++++++++++++++++++++
> lib/ethdev/rte_ethdev.h | 79 ++++++++++++++++++++-----
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 25 +-------
> lib/ethdev/version.map | 1 +
> 12 files changed, 239 insertions(+), 93 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm
2023-10-28 3:01 3% ` lihuisong (C)
@ 2023-11-01 12:55 5% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-11-01 12:55 UTC (permalink / raw)
To: lihuisong (C), Jie Hai, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam
Cc: fengchengwen, liudongdong3
On 10/28/2023 4:01 AM, lihuisong (C) wrote:
> With belows to changes,
> Acked-by: Huisong Li <lihuisong@huawei.com>
>
>
> 在 2023/10/28 9:46, Jie Hai 写道:
>> Currently, rte_eth_rss_conf supports configuring and querying
>> RSS hash functions, rss key and it's length, but not RSS hash
>> algorithm.
>>
>> The structure ``rte_eth_dev_info`` is extended by adding a new
>> field "rss_algo_capa". Drivers are responsible for reporting this
>> capa and configurations of RSS hash algorithm can be verified based
>> on the capability. The default value of "rss_algo_capa" is
>> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
>>
>> The structure ``rte_eth_rss_conf`` is extended by adding a new
>> field "algorithm". This represents the RSS algorithms to apply.
>> If the value of "algorithm" used for configuration is a gibberish
>> value, drivers should report the error.
>>
>> To check whether the drivers report valid "algorithm", it is set
>> to default value before querying in rte_eth_dev_rss_hash_conf_get().
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> ---
>> doc/guides/rel_notes/release_23_11.rst | 5 ++++
>> lib/ethdev/rte_ethdev.c | 26 ++++++++++++++++++++
>> lib/ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
>> lib/ethdev/rte_flow.c | 1 -
>> lib/ethdev/rte_flow.h | 26 ++------------------
>> 5 files changed, 65 insertions(+), 26 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_23_11.rst
>> b/doc/guides/rel_notes/release_23_11.rst
>> index 0a6fc76a9d02..a35d729d2cc7 100644
>> --- a/doc/guides/rel_notes/release_23_11.rst
>> +++ b/doc/guides/rel_notes/release_23_11.rst
>> @@ -360,6 +360,11 @@ ABI Changes
>> * security: struct ``rte_security_ipsec_sa_options`` was updated
>> due to inline out-of-place feature addition.
>> +* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info``
>> structure for
>> +* reporting RSS hash algorithm capability.
>> +
>> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure
>> for RSS
>> + hash algorithm.
>> Known Issues
>> ------------
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 9dabcb5ae28e..90bfbf14d1f7 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -1269,6 +1269,7 @@ int
>> rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t
>> nb_tx_q,
>> const struct rte_eth_conf *dev_conf)
>> {
>> + enum rte_eth_hash_function algorithm;
>> struct rte_eth_dev *dev;
>> struct rte_eth_dev_info dev_info;
>> struct rte_eth_conf orig_conf;
>> @@ -1500,6 +1501,18 @@ rte_eth_dev_configure(uint16_t port_id,
>> uint16_t nb_rx_q, uint16_t nb_tx_q,
>> goto rollback;
>> }
>> + algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
>> + if ((dev_info.rss_algo_capa &
>> + RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
> need to check the algorithm.
> its value should be in range of 0 to 31.
>> + RTE_ETHDEV_LOG(ERR,
>> + "Ethdev port_id=%u config unsupported RSS hash algorithm:
>> %u "
>> + "with rss_algo_capa: %x\n",
> It seems that this log is not friendly to user.
> Configured RSS hash algorithm (%u) is not in the algorithm capability ().
> Anything ok like that.
>
> %x --> 0x%" PRIx32 "
>> + port_id, algorithm,
>> + dev_info.rss_algo_capa);
>> + ret = -EINVAL;
>> + goto rollback;
>> + }
>> +
>> /*
>> * Setup new number of Rx/Tx queues and reconfigure device.
>> */
>> @@ -3757,6 +3770,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct
>> rte_eth_dev_info *dev_info)
>> dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
>> RTE_ETHER_CRC_LEN;
>> dev_info->max_mtu = UINT16_MAX;
>> + dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
>> if (*dev->dev_ops->dev_infos_get == NULL)
>> return -ENOTSUP;
>> @@ -4698,6 +4712,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
>> return -ENOTSUP;
>> }
>> + if ((dev_info.rss_algo_capa &
>> + RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
>> + RTE_ETHDEV_LOG(ERR,
>> + "Ethdev port_id=%u config unsupported RSS hash algorithm:
>> %u "
>> + "with rss_algo_capa: %x\n",
>> + port_id, rss_conf->algorithm,
>> + dev_info.rss_algo_capa);
>> + return -EINVAL;
>> + }
>> +
>> if (*dev->dev_ops->rss_hash_update == NULL)
>> return -ENOTSUP;
>> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
>> @@ -4725,6 +4749,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
>> return -EINVAL;
>> }
>> + rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
>> +
>> if (*dev->dev_ops->rss_hash_conf_get == NULL)
>> return -ENOTSUP;
>> ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
>> index 37fd5afef48a..2f639edd8218 100644
>> --- a/lib/ethdev/rte_ethdev.h
>> +++ b/lib/ethdev/rte_ethdev.h
>> @@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
>> uint64_t ids[64];
>> };
>> +/**
>> + * Hash function types.
>> + */
>> +enum rte_eth_hash_function {
>> + /** DEFAULT means driver decides which hash algorithm to pick. */
>> + RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
>> + RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
>> + RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
>> + /**
>> + * Symmetric Toeplitz: src, dst will be replaced by
>> + * xor(src, dst). For the case with src/dst only,
>> + * src or dst address will xor with zero pair.
>> + */
>> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
>> + /**
>> + * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
>> + * the hash function.
>> + * If src_ip > dst_ip, swap src_ip and dst_ip.
>> + * If src_port > dst_port, swap src_port and dst_port.
>> + */
>> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
>> + RTE_ETH_HASH_FUNCTION_MAX,
>> +};
>> +
>> +#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
>> +#define RTE_ETH_HASH_ALGO_CAPA_MASK(x)
>> RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
>> +
>> /**
>> * A structure used to configure the Receive Side Scaling (RSS) feature
>> * of an Ethernet port.
>> @@ -469,6 +496,7 @@ struct rte_eth_rss_conf {
>> * which RSS hashing is to be applied.
>> */
>> uint64_t rss_hf;
>> + enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
>> };
>> /*
>> @@ -1783,7 +1811,10 @@ struct rte_eth_dev_info {
>> /** Supported error handling mode. */
>> enum rte_eth_err_handle_mode err_handle_mode;
>> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
>> + /** RSS hash algorithms capabilities */
>> + uint32_t rss_algo_capa;
>>
> Please move this new field to "hash_key_size" and
> "flow_type_rss_offloads" in this struct.
> Because this version allows ABI break.
>
Technically, even LTS release is an ABI break release, an ABI break
should be discussed, approved and documented in the deprecation.rst in
advance.
For this patch, design evolved to update "struct rte_eth_dev_info" as
discussions go on, so I think we can make an exception,
But I would like to clarify that we shouldn't just break the ABI since
it is an LTS release.
A way to prevent exception happening in the patch is conclude design and
document ABI breakage *before* LTS release cycle start.
>> +
>> + uint32_t reserved_32s[3]; /**< Reserved for future fields */
>> void *reserved_ptrs[2]; /**< Reserved for future fields */
>> };
>> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
>> index 3a67f1aaba9d..c13a2a391c37 100644
>> --- a/lib/ethdev/rte_flow.c
>> +++ b/lib/ethdev/rte_flow.c
>> @@ -13,7 +13,6 @@
>> #include <rte_branch_prediction.h>
>> #include <rte_string_fns.h>
>> #include <rte_mbuf_dyn.h>
>> -#include "rte_ethdev.h"
>> #include "rte_flow_driver.h"
>> #include "rte_flow.h"
>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>> index 25f1dffd1f30..c94f553ae06f 100644
>> --- a/lib/ethdev/rte_flow.h
>> +++ b/lib/ethdev/rte_flow.h
>> @@ -40,6 +40,8 @@
>> #include <rte_macsec.h>
>> #include <rte_ib.h>
>> +#include "rte_ethdev.h"
>> +
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> @@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
>> uint64_t bytes; /**< Number of bytes through this rule [out]. */
>> };
>> -/**
>> - * Hash function types.
>> - */
>> -enum rte_eth_hash_function {
>> - /** DEFAULT means driver decides which hash algorithm to pick. */
>> - RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
>> - RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
>> - RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
>> - /**
>> - * Symmetric Toeplitz: src, dst will be replaced by
>> - * xor(src, dst). For the case with src/dst only,
>> - * src or dst address will xor with zero pair.
>> - */
>> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
>> - /**
>> - * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
>> - * the hash function.
>> - * If src_ip > dst_ip, swap src_ip and dst_ip.
>> - * If src_port > dst_port, swap src_port and dst_port.
>> - */
>> - RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
>> - RTE_ETH_HASH_FUNCTION_MAX,
>> -};
>> -
>> /**
>> * RTE_FLOW_ACTION_TYPE_RSS
>> *
^ permalink raw reply [relevance 5%]
* Re: [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm
2023-11-01 7:40 4% ` [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-11-01 13:36 3% ` Ferruh Yigit
2023-11-02 6:58 0% ` Jie Hai
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-11-01 13:36 UTC (permalink / raw)
To: Jie Hai, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
On 11/1/2023 7:40 AM, Jie Hai wrote:
> Currently, rte_eth_rss_conf supports configuring and querying
> RSS hash functions, rss key and it's length, but not RSS hash
> algorithm.
>
> The structure ``rte_eth_dev_info`` is extended by adding a new
> field "rss_algo_capa". Drivers are responsible for reporting this
> capa and configurations of RSS hash algorithm can be verified based
> on the capability. The default value of "rss_algo_capa" is
> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
>
> The structure ``rte_eth_rss_conf`` is extended by adding a new
> field "algorithm". This represents the RSS algorithms to apply.
> If the value of "algorithm" used for configuration is a gibberish
> value, drivers should report the error.
>
> To check whether the drivers report valid "algorithm", it is set
> to default value before querying in rte_eth_dev_rss_hash_conf_get().
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> Acked-by: Huisong Li <lihuisong@huawei.com>
> ---
> doc/guides/rel_notes/release_23_11.rst | 5 +++++
> lib/ethdev/rte_ethdev.c | 26 +++++++++++++++++++++++
> lib/ethdev/rte_ethdev.h | 29 ++++++++++++++++++++++++++
> lib/ethdev/rte_flow.c | 1 -
> lib/ethdev/rte_flow.h | 26 ++---------------------
> 5 files changed, 62 insertions(+), 25 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
> index 95db98d098d8..e207786044f9 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -372,6 +372,11 @@ ABI Changes
> * security: struct ``rte_security_ipsec_sa_options`` was updated
> due to inline out-of-place feature addition.
>
> +* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
> +* reporting RSS hash algorithm capability.
> +
> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
> + hash algorithm.
>
As well as ABI change, can you also update the "New Features", to
document getting hash algorithm capability and setting hash algorithm
support added?
Also please add an empty line here.
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 07bb35833ba6..f9bd99d07eb1 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1269,6 +1269,7 @@ int
> rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> const struct rte_eth_conf *dev_conf)
> {
> + enum rte_eth_hash_function algorithm;
> struct rte_eth_dev *dev;
> struct rte_eth_dev_info dev_info;
> struct rte_eth_conf orig_conf;
> @@ -1510,6 +1511,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
> goto rollback;
> }
>
> + algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
> + if (RTE_ETH_HASH_ALGO_TO_CAPA(algorithm) == 0 ||
>
"RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)" can't be zero for valid "enum
rte_eth_hash_function" values, I assume above check is for the case
algorith > 31, as it will result zero.
My concern is, this is undefined behaviour (shift left >= 32) and some
compiler can complain about it, instead of relying this can you please
add explicit "0 <= algorithm < 32" check?
^ permalink raw reply [relevance 3%]
* [PATCH v6 1/3] net/tap: support infrastructure to build the BPF filter
@ 2023-11-01 18:02 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-11-01 18:02 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
Move the BPF program related code into a subdirectory.
And add a Makefile for building it.
The code depends on include files from iproute2.
But these are not public headers which iproute2 exports
as a package API. Therefore make a local copy here.
The standalone build was also broken because by
commit ef5baf3486e0 ("replace packed attributes")
which introduced __rte_packed into this code.
Add a python program to extract the resulting BPF into
a format that can be consumed by the TAP driver.
Update the documentation.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/nics/tap.rst | 11 +-
drivers/net/tap/bpf/.gitignore | 1 +
drivers/net/tap/bpf/Makefile | 18 ++
drivers/net/tap/bpf/bpf_api.h | 275 ++++++++++++++++++++
drivers/net/tap/bpf/bpf_elf.h | 53 ++++
| 86 ++++++
drivers/net/tap/{ => bpf}/tap_bpf_program.c | 10 +-
| 2 +-
8 files changed, 444 insertions(+), 12 deletions(-)
create mode 100644 drivers/net/tap/bpf/.gitignore
create mode 100644 drivers/net/tap/bpf/Makefile
create mode 100644 drivers/net/tap/bpf/bpf_api.h
create mode 100644 drivers/net/tap/bpf/bpf_elf.h
create mode 100644 drivers/net/tap/bpf/bpf_extract.py
rename drivers/net/tap/{ => bpf}/tap_bpf_program.c (96%)
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 07df0d35a2..449e747994 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -256,15 +256,12 @@ C functions under different ELF sections.
2. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
-3. Compile ``tap_bpf_program.c`` via ``LLVM`` into an object file::
+3. Use make to compile `tap_bpf_program.c`` via ``LLVM`` into an object file
+ and extract the resulting instructions into ``tap_bpf_insn.h``.
- clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf \
- -filetype=obj -o <tap_bpf_program.o>
+ cd bpf; make
-
-4. Use a tool that receives two parameters: an eBPF object file and a section
-name, and prints out the section as a C array of eBPF instructions.
-Embed the C array in your TAP PMD tree.
+4. Recompile the TAP PMD.
The C arrays are uploaded to the kernel using BPF system calls.
diff --git a/drivers/net/tap/bpf/.gitignore b/drivers/net/tap/bpf/.gitignore
new file mode 100644
index 0000000000..30a258f1af
--- /dev/null
+++ b/drivers/net/tap/bpf/.gitignore
@@ -0,0 +1 @@
+tap_bpf_program.o
diff --git a/drivers/net/tap/bpf/Makefile b/drivers/net/tap/bpf/Makefile
new file mode 100644
index 0000000000..59844c616f
--- /dev/null
+++ b/drivers/net/tap/bpf/Makefile
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# This file is not built as part of normal DPDK build.
+# It is used to generate the eBPF code for TAP RSS.
+CLANG=clang
+CLANG_OPTS=-O2
+TARGET=../tap_bpf_insns.h
+
+all: $(TARGET)
+
+clean:
+ rm tap_bpf_program.o $(TARGET)
+
+tap_bpf_program.o: tap_bpf_program.c
+ $(CLANG) $(CLANG_OPTS) -emit-llvm -c $< -o - | \
+ llc -march=bpf -filetype=obj -o $@
+
+$(TARGET): tap_bpf_program.o
+ python3 bpf_extract.py -stap_bpf_program.c -o $@ $<
diff --git a/drivers/net/tap/bpf/bpf_api.h b/drivers/net/tap/bpf/bpf_api.h
new file mode 100644
index 0000000000..5887d3a851
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_api.h
@@ -0,0 +1,275 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_API__
+#define __BPF_API__
+
+/* Note:
+ *
+ * This file can be included into eBPF kernel programs. It contains
+ * a couple of useful helper functions, map/section ABI (bpf_elf.h),
+ * misc macros and some eBPF specific LLVM built-ins.
+ */
+
+#include <stdint.h>
+
+#include <linux/pkt_cls.h>
+#include <linux/bpf.h>
+#include <linux/filter.h>
+
+#include <asm/byteorder.h>
+
+#include "bpf_elf.h"
+
+/** libbpf pin type. */
+enum libbpf_pin_type {
+ LIBBPF_PIN_NONE,
+ /* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
+ LIBBPF_PIN_BY_NAME,
+};
+
+/** Type helper macros. */
+
+#define __uint(name, val) int (*name)[val]
+#define __type(name, val) typeof(val) *name
+#define __array(name, val) typeof(val) *name[]
+
+/** Misc macros. */
+
+#ifndef __stringify
+# define __stringify(X) #X
+#endif
+
+#ifndef __maybe_unused
+# define __maybe_unused __attribute__((__unused__))
+#endif
+
+#ifndef offsetof
+# define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
+#endif
+
+#ifndef likely
+# define likely(X) __builtin_expect(!!(X), 1)
+#endif
+
+#ifndef unlikely
+# define unlikely(X) __builtin_expect(!!(X), 0)
+#endif
+
+#ifndef htons
+# define htons(X) __constant_htons((X))
+#endif
+
+#ifndef ntohs
+# define ntohs(X) __constant_ntohs((X))
+#endif
+
+#ifndef htonl
+# define htonl(X) __constant_htonl((X))
+#endif
+
+#ifndef ntohl
+# define ntohl(X) __constant_ntohl((X))
+#endif
+
+#ifndef __inline__
+# define __inline__ __attribute__((always_inline))
+#endif
+
+/** Section helper macros. */
+
+#ifndef __section
+# define __section(NAME) \
+ __attribute__((section(NAME), used))
+#endif
+
+#ifndef __section_tail
+# define __section_tail(ID, KEY) \
+ __section(__stringify(ID) "/" __stringify(KEY))
+#endif
+
+#ifndef __section_xdp_entry
+# define __section_xdp_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_cls_entry
+# define __section_cls_entry \
+ __section(ELF_SECTION_CLASSIFIER)
+#endif
+
+#ifndef __section_act_entry
+# define __section_act_entry \
+ __section(ELF_SECTION_ACTION)
+#endif
+
+#ifndef __section_lwt_entry
+# define __section_lwt_entry \
+ __section(ELF_SECTION_PROG)
+#endif
+
+#ifndef __section_license
+# define __section_license \
+ __section(ELF_SECTION_LICENSE)
+#endif
+
+#ifndef __section_maps
+# define __section_maps \
+ __section(ELF_SECTION_MAPS)
+#endif
+
+/** Declaration helper macros. */
+
+#ifndef BPF_LICENSE
+# define BPF_LICENSE(NAME) \
+ char ____license[] __section_license = NAME
+#endif
+
+/** Classifier helper */
+
+#ifndef BPF_H_DEFAULT
+# define BPF_H_DEFAULT -1
+#endif
+
+/** BPF helper functions for tc. Individual flags are in linux/bpf.h */
+
+#ifndef __BPF_FUNC
+# define __BPF_FUNC(NAME, ...) \
+ (* NAME)(__VA_ARGS__) __maybe_unused
+#endif
+
+#ifndef BPF_FUNC
+# define BPF_FUNC(NAME, ...) \
+ __BPF_FUNC(NAME, __VA_ARGS__) = (void *) BPF_FUNC_##NAME
+#endif
+
+/* Map access/manipulation */
+static void *BPF_FUNC(map_lookup_elem, void *map, const void *key);
+static int BPF_FUNC(map_update_elem, void *map, const void *key,
+ const void *value, uint32_t flags);
+static int BPF_FUNC(map_delete_elem, void *map, const void *key);
+
+/* Time access */
+static uint64_t BPF_FUNC(ktime_get_ns);
+
+/* Debugging */
+
+/* FIXME: __attribute__ ((format(printf, 1, 3))) not possible unless
+ * llvm bug https://llvm.org/bugs/show_bug.cgi?id=26243 gets resolved.
+ * It would require ____fmt to be made const, which generates a reloc
+ * entry (non-map).
+ */
+static void BPF_FUNC(trace_printk, const char *fmt, int fmt_size, ...);
+
+#ifndef printt
+# define printt(fmt, ...) \
+ ({ \
+ char ____fmt[] = fmt; \
+ trace_printk(____fmt, sizeof(____fmt), ##__VA_ARGS__); \
+ })
+#endif
+
+/* Random numbers */
+static uint32_t BPF_FUNC(get_prandom_u32);
+
+/* Tail calls */
+static void BPF_FUNC(tail_call, struct __sk_buff *skb, void *map,
+ uint32_t index);
+
+/* System helpers */
+static uint32_t BPF_FUNC(get_smp_processor_id);
+static uint32_t BPF_FUNC(get_numa_node_id);
+
+/* Packet misc meta data */
+static uint32_t BPF_FUNC(get_cgroup_classid, struct __sk_buff *skb);
+static int BPF_FUNC(skb_under_cgroup, void *map, uint32_t index);
+
+static uint32_t BPF_FUNC(get_route_realm, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(get_hash_recalc, struct __sk_buff *skb);
+static uint32_t BPF_FUNC(set_hash_invalid, struct __sk_buff *skb);
+
+/* Packet redirection */
+static int BPF_FUNC(redirect, int ifindex, uint32_t flags);
+static int BPF_FUNC(clone_redirect, struct __sk_buff *skb, int ifindex,
+ uint32_t flags);
+
+/* Packet manipulation */
+static int BPF_FUNC(skb_load_bytes, struct __sk_buff *skb, uint32_t off,
+ void *to, uint32_t len);
+static int BPF_FUNC(skb_store_bytes, struct __sk_buff *skb, uint32_t off,
+ const void *from, uint32_t len, uint32_t flags);
+
+static int BPF_FUNC(l3_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(l4_csum_replace, struct __sk_buff *skb, uint32_t off,
+ uint32_t from, uint32_t to, uint32_t flags);
+static int BPF_FUNC(csum_diff, const void *from, uint32_t from_size,
+ const void *to, uint32_t to_size, uint32_t seed);
+static int BPF_FUNC(csum_update, struct __sk_buff *skb, uint32_t wsum);
+
+static int BPF_FUNC(skb_change_type, struct __sk_buff *skb, uint32_t type);
+static int BPF_FUNC(skb_change_proto, struct __sk_buff *skb, uint32_t proto,
+ uint32_t flags);
+static int BPF_FUNC(skb_change_tail, struct __sk_buff *skb, uint32_t nlen,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_pull_data, struct __sk_buff *skb, uint32_t len);
+
+/* Event notification */
+static int __BPF_FUNC(skb_event_output, struct __sk_buff *skb, void *map,
+ uint64_t index, const void *data, uint32_t size) =
+ (void *) BPF_FUNC_perf_event_output;
+
+/* Packet vlan encap/decap */
+static int BPF_FUNC(skb_vlan_push, struct __sk_buff *skb, uint16_t proto,
+ uint16_t vlan_tci);
+static int BPF_FUNC(skb_vlan_pop, struct __sk_buff *skb);
+
+/* Packet tunnel encap/decap */
+static int BPF_FUNC(skb_get_tunnel_key, struct __sk_buff *skb,
+ struct bpf_tunnel_key *to, uint32_t size, uint32_t flags);
+static int BPF_FUNC(skb_set_tunnel_key, struct __sk_buff *skb,
+ const struct bpf_tunnel_key *from, uint32_t size,
+ uint32_t flags);
+
+static int BPF_FUNC(skb_get_tunnel_opt, struct __sk_buff *skb,
+ void *to, uint32_t size);
+static int BPF_FUNC(skb_set_tunnel_opt, struct __sk_buff *skb,
+ const void *from, uint32_t size);
+
+/** LLVM built-ins, mem*() routines work for constant size */
+
+#ifndef lock_xadd
+# define lock_xadd(ptr, val) ((void) __sync_fetch_and_add(ptr, val))
+#endif
+
+#ifndef memset
+# define memset(s, c, n) __builtin_memset((s), (c), (n))
+#endif
+
+#ifndef memcpy
+# define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
+#endif
+
+#ifndef memmove
+# define memmove(d, s, n) __builtin_memmove((d), (s), (n))
+#endif
+
+/* FIXME: __builtin_memcmp() is not yet fully useable unless llvm bug
+ * https://llvm.org/bugs/show_bug.cgi?id=26218 gets resolved. Also
+ * this one would generate a reloc entry (non-map), otherwise.
+ */
+#if 0
+#ifndef memcmp
+# define memcmp(a, b, n) __builtin_memcmp((a), (b), (n))
+#endif
+#endif
+
+unsigned long long load_byte(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.byte");
+
+unsigned long long load_half(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.half");
+
+unsigned long long load_word(void *skb, unsigned long long off)
+ asm ("llvm.bpf.load.word");
+
+#endif /* __BPF_API__ */
diff --git a/drivers/net/tap/bpf/bpf_elf.h b/drivers/net/tap/bpf/bpf_elf.h
new file mode 100644
index 0000000000..ea8a11c95c
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_elf.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
+#ifndef __BPF_ELF__
+#define __BPF_ELF__
+
+#include <asm/types.h>
+
+/* Note:
+ *
+ * Below ELF section names and bpf_elf_map structure definition
+ * are not (!) kernel ABI. It's rather a "contract" between the
+ * application and the BPF loader in tc. For compatibility, the
+ * section names should stay as-is. Introduction of aliases, if
+ * needed, are a possibility, though.
+ */
+
+/* ELF section names, etc */
+#define ELF_SECTION_LICENSE "license"
+#define ELF_SECTION_MAPS "maps"
+#define ELF_SECTION_PROG "prog"
+#define ELF_SECTION_CLASSIFIER "classifier"
+#define ELF_SECTION_ACTION "action"
+
+#define ELF_MAX_MAPS 64
+#define ELF_MAX_LICENSE_LEN 128
+
+/* Object pinning settings */
+#define PIN_NONE 0
+#define PIN_OBJECT_NS 1
+#define PIN_GLOBAL_NS 2
+
+/* ELF map definition */
+struct bpf_elf_map {
+ __u32 type;
+ __u32 size_key;
+ __u32 size_value;
+ __u32 max_elem;
+ __u32 flags;
+ __u32 id;
+ __u32 pinning;
+ __u32 inner_id;
+ __u32 inner_idx;
+};
+
+#define BPF_ANNOTATE_KV_PAIR(name, type_key, type_val) \
+ struct ____btf_map_##name { \
+ type_key key; \
+ type_val value; \
+ }; \
+ struct ____btf_map_##name \
+ __attribute__ ((section(".maps." #name), used)) \
+ ____btf_map_##name = { }
+
+#endif /* __BPF_ELF__ */
--git a/drivers/net/tap/bpf/bpf_extract.py b/drivers/net/tap/bpf/bpf_extract.py
new file mode 100644
index 0000000000..b630c42b80
--- /dev/null
+++ b/drivers/net/tap/bpf/bpf_extract.py
@@ -0,0 +1,86 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2023 Stephen Hemminger <stephen@networkplumber.org>
+
+import argparse
+import sys
+import struct
+from tempfile import TemporaryFile
+from elftools.elf.elffile import ELFFile
+
+
+def load_sections(elffile):
+ """Get sections of interest from ELF"""
+ result = []
+ parts = [("cls_q", "cls_q_insns"), ("l3_l4", "l3_l4_hash_insns")]
+ for name, tag in parts:
+ section = elffile.get_section_by_name(name)
+ if section:
+ insns = struct.iter_unpack('<BBhL', section.data())
+ result.append([tag, insns])
+ return result
+
+
+def dump_section(name, insns, out):
+ """Dump the array of BPF instructions"""
+ print(f'\nstatic struct bpf_insn {name}[] = {{', file=out)
+ for bpf in insns:
+ code = bpf[0]
+ src = bpf[1] >> 4
+ dst = bpf[1] & 0xf
+ off = bpf[2]
+ imm = bpf[3]
+ print(f'\t{{{code:#04x}, {dst:4d}, {src:4d}, {off:8d}, {imm:#010x}}},',
+ file=out)
+ print('};', file=out)
+
+
+def parse_args():
+ """Parse command line arguments"""
+ parser = argparse.ArgumentParser()
+ parser.add_argument('-s',
+ '--source',
+ type=str,
+ help="original source file")
+ parser.add_argument('-o', '--out', type=str, help="output C file path")
+ parser.add_argument("file",
+ nargs='+',
+ help="object file path or '-' for stdin")
+ return parser.parse_args()
+
+
+def open_input(path):
+ """Open the file or stdin"""
+ if path == "-":
+ temp = TemporaryFile()
+ temp.write(sys.stdin.buffer.read())
+ return temp
+ return open(path, 'rb')
+
+
+def write_header(out, source):
+ """Write file intro header"""
+ print("/* SPDX-License-Identifier: BSD-3-Clause", file=out)
+ if source:
+ print(f' * Auto-generated from {source}', file=out)
+ print(" * This not the original source file. Do NOT edit it.", file=out)
+ print(" */\n", file=out)
+ print("#include <tap_bpf.h>", file=out)
+
+
+def main():
+ '''program main function'''
+ args = parse_args()
+
+ with open(args.out, 'w',
+ encoding="utf-8") if args.out else sys.stdout as out:
+ write_header(out, args.source)
+ for path in args.file:
+ elffile = ELFFile(open_input(path))
+ sections = load_sections(elffile)
+ for name, insns in sections:
+ dump_section(name, insns, out)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/drivers/net/tap/tap_bpf_program.c b/drivers/net/tap/bpf/tap_bpf_program.c
similarity index 96%
rename from drivers/net/tap/tap_bpf_program.c
rename to drivers/net/tap/bpf/tap_bpf_program.c
index 20c310e5e7..d65021d8a1 100644
--- a/drivers/net/tap/tap_bpf_program.c
+++ b/drivers/net/tap/bpf/tap_bpf_program.c
@@ -14,9 +14,10 @@
#include <linux/ipv6.h>
#include <linux/if_tunnel.h>
#include <linux/filter.h>
-#include <linux/bpf.h>
-#include "tap_rss.h"
+#include "bpf_api.h"
+#include "bpf_elf.h"
+#include "../tap_rss.h"
/** Create IPv4 address */
#define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
@@ -56,6 +57,7 @@ __section("cls_q") int
match_q(struct __sk_buff *skb)
{
__u32 queue = skb->cb[1];
+ /* queue is set by tap_flow_bpf_cls_q() before load */
volatile __u32 q = 0xdeadbeef;
__u32 match_queue = QUEUE_OFFSET + q;
@@ -75,14 +77,14 @@ struct ipv4_l3_l4_tuple {
__u32 dst_addr;
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
struct ipv6_l3_l4_tuple {
__u8 src_addr[16];
__u8 dst_addr[16];
__u16 dport;
__u16 sport;
-} __rte_packed;
+} __attribute__((packed));
static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
0xd1, 0x81, 0xc6, 0x2c,
--git a/drivers/net/tap/tap_rss.h b/drivers/net/tap/tap_rss.h
index 48c151cf6b..dff46a012f 100644
--- a/drivers/net/tap/tap_rss.h
+++ b/drivers/net/tap/tap_rss.h
@@ -35,6 +35,6 @@ struct rss_key {
__u32 key_size;
__u32 queues[TAP_MAX_QUEUES];
__u32 nb_queues;
-} __rte_packed;
+} __attribute__((packed));
#endif /* _TAP_RSS_H_ */
--
2.41.0
^ permalink raw reply [relevance 4%]
* [PATCH 04/11] net/nfp: add flag to indicate multiple PFs support
@ 2023-11-02 2:23 9% ` Chaoyong He
0 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-11-02 2:23 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Peng Zhang, Chaoyong He, Long Wu
From: Peng Zhang <peng.zhang@corigine.com>
Support for multiple PFs have been added to the NFP3800 firmware. This
can be detected by reading the NSP major version, which was bumped to 1
when support was added.
Add a flag and detecting method to record if the current device is
cabable to support multiple PFs. This will be used in later patches to
initialize and make use of this new feature.
Noteworthy about the detection method from NSP version information, the
NSP minor version was not touched when increasing the major version.
This makes the first NSP version to support multiple PFs version 1.8,
while the latest version without this supports remains 0.8.
Signed-off-by: Peng Zhang <peng.zhang@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
Reviewed-by: Long Wu <long.wu@corigine.com>
---
drivers/net/nfp/nfp_ethdev.c | 49 +++++++++++++++++++++++--------
drivers/net/nfp/nfp_net_common.h | 8 +++++
drivers/net/nfp/nfpcore/nfp_nsp.c | 14 +++++++--
3 files changed, 56 insertions(+), 15 deletions(-)
diff --git a/drivers/net/nfp/nfp_ethdev.c b/drivers/net/nfp/nfp_ethdev.c
index aa2b59af32..7022ef435f 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -479,7 +479,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
rte_eth_copy_pci_info(eth_dev, pci_dev);
- if (port == 0) {
+ if (port == 0 || pf_dev->multi_pf.enabled) {
uint32_t min_size;
hw->ctrl_bar = pf_dev->ctrl_bar;
@@ -712,6 +712,26 @@ nfp_fw_setup(struct rte_pci_device *dev,
return err;
}
+static inline bool
+nfp_check_multi_pf_from_nsp(struct rte_pci_device *pci_dev,
+ struct nfp_cpp *cpp)
+{
+ bool flag;
+ struct nfp_nsp *nsp;
+
+ nsp = nfp_nsp_open(cpp);
+ if (nsp == NULL) {
+ PMD_DRV_LOG(ERR, "NFP error when obtaining NSP handle");
+ return false;
+ }
+
+ flag = (nfp_nsp_get_abi_ver_major(nsp) > 0) &&
+ (pci_dev->id.device_id == PCI_DEVICE_ID_NFP3800_PF_NIC);
+
+ nfp_nsp_close(nsp);
+ return flag;
+}
+
static int
nfp_init_app_fw_nic(struct nfp_pf_dev *pf_dev,
const struct nfp_dev_info *dev_info)
@@ -874,6 +894,14 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
return -ENODEV;
}
+ /* Allocate memory for the PF "device" */
+ snprintf(name, sizeof(name), "nfp_pf%d", 0);
+ pf_dev = rte_zmalloc(name, sizeof(*pf_dev), 0);
+ if (pf_dev == NULL) {
+ PMD_INIT_LOG(ERR, "Can't allocate memory for the PF device");
+ return -ENOMEM;
+ }
+
/*
* When device bound to UIO, the device could be used, by mistake,
* by two DPDK apps, and the UIO driver does not avoid it. This
@@ -888,7 +916,8 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
if (cpp == NULL) {
PMD_INIT_LOG(ERR, "A CPP handle can not be obtained");
- return -EIO;
+ ret = -EIO;
+ goto pf_cleanup;
}
hwinfo = nfp_hwinfo_read(cpp);
@@ -906,6 +935,8 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
goto hwinfo_cleanup;
}
+ pf_dev->multi_pf.enabled = nfp_check_multi_pf_from_nsp(pci_dev, cpp);
+
/* Force the physical port down to clear the possible DMA error */
for (i = 0; i < nfp_eth_table->count; i++)
nfp_eth_set_configured(cpp, nfp_eth_table->ports[i].index, 0);
@@ -932,14 +963,6 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
goto sym_tbl_cleanup;
}
- /* Allocate memory for the PF "device" */
- snprintf(name, sizeof(name), "nfp_pf%d", 0);
- pf_dev = rte_zmalloc(name, sizeof(*pf_dev), 0);
- if (pf_dev == NULL) {
- ret = -ENOMEM;
- goto sym_tbl_cleanup;
- }
-
/* Populate the newly created PF device */
pf_dev->app_fw_id = app_fw_id;
pf_dev->cpp = cpp;
@@ -957,7 +980,7 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
if (pf_dev->qc_bar == NULL) {
PMD_INIT_LOG(ERR, "nfp_rtsym_map fails for net.qc");
ret = -EIO;
- goto pf_cleanup;
+ goto sym_tbl_cleanup;
}
PMD_INIT_LOG(DEBUG, "qc_bar address: %p", pf_dev->qc_bar);
@@ -998,8 +1021,6 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
hwqueues_cleanup:
nfp_cpp_area_free(pf_dev->qc_area);
-pf_cleanup:
- rte_free(pf_dev);
sym_tbl_cleanup:
free(sym_tbl);
eth_table_cleanup:
@@ -1008,6 +1029,8 @@ nfp_pf_init(struct rte_pci_device *pci_dev)
free(hwinfo);
cpp_cleanup:
nfp_cpp_free(cpp);
+pf_cleanup:
+ rte_free(pf_dev);
return ret;
}
diff --git a/drivers/net/nfp/nfp_net_common.h b/drivers/net/nfp/nfp_net_common.h
index b9df2fe563..bd0ed077c5 100644
--- a/drivers/net/nfp/nfp_net_common.h
+++ b/drivers/net/nfp/nfp_net_common.h
@@ -54,6 +54,11 @@ struct nfp_net_tlv_caps {
uint32_t mbox_cmsg_types; /**< Cmsgs which can be passed through the mailbox */
};
+struct nfp_multi_pf {
+ /** Support multiple PF */
+ bool enabled;
+};
+
struct nfp_pf_dev {
/** Backpointer to associated pci device */
struct rte_pci_device *pci_dev;
@@ -79,6 +84,9 @@ struct nfp_pf_dev {
/** Service id of cpp bridge service */
uint32_t cpp_bridge_id;
+
+ /** Multiple PF configuration */
+ struct nfp_multi_pf multi_pf;
};
struct nfp_app_fw_nic {
diff --git a/drivers/net/nfp/nfpcore/nfp_nsp.c b/drivers/net/nfp/nfpcore/nfp_nsp.c
index a680b972b8..9f88b822f3 100644
--- a/drivers/net/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/nfp/nfpcore/nfp_nsp.c
@@ -40,7 +40,17 @@
#define NSP_DFLT_BUFFER_SIZE_MB GENMASK_ULL(7, 0)
#define NSP_MAGIC 0xab10
-#define NSP_MAJOR 0
+
+/*
+ * ABI major version is bumped separately without resetting minor
+ * version when the change in NSP is not compatible to old driver.
+ */
+#define NSP_MAJOR 1
+
+/*
+ * ABI minor version is bumped when new feature is introduced
+ * while old driver can still work without this new feature.
+ */
#define NSP_MINOR 8
#define NSP_CODE_MAJOR GENMASK_ULL(15, 12)
@@ -203,7 +213,7 @@ nfp_nsp_check(struct nfp_nsp *state)
state->ver.major = FIELD_GET(NSP_STATUS_MAJOR, reg);
state->ver.minor = FIELD_GET(NSP_STATUS_MINOR, reg);
- if (state->ver.major != NSP_MAJOR || state->ver.minor < NSP_MINOR) {
+ if (state->ver.major > NSP_MAJOR || state->ver.minor < NSP_MINOR) {
PMD_DRV_LOG(ERR, "Unsupported ABI %hu.%hu", state->ver.major,
state->ver.minor);
return -EINVAL;
--
2.39.1
^ permalink raw reply [relevance 9%]
* Re: [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm
2023-11-01 13:36 3% ` Ferruh Yigit
@ 2023-11-02 6:58 0% ` Jie Hai
0 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-11-02 6:58 UTC (permalink / raw)
To: Ferruh Yigit, dev, Thomas Monjalon, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
On 2023/11/1 21:36, Ferruh Yigit wrote:
> On 11/1/2023 7:40 AM, Jie Hai wrote:
>> Currently, rte_eth_rss_conf supports configuring and querying
>> RSS hash functions, rss key and it's length, but not RSS hash
>> algorithm.
>>
>> The structure ``rte_eth_dev_info`` is extended by adding a new
>> field "rss_algo_capa". Drivers are responsible for reporting this
>> capa and configurations of RSS hash algorithm can be verified based
>> on the capability. The default value of "rss_algo_capa" is
>> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
>>
>> The structure ``rte_eth_rss_conf`` is extended by adding a new
>> field "algorithm". This represents the RSS algorithms to apply.
>> If the value of "algorithm" used for configuration is a gibberish
>> value, drivers should report the error.
>>
>> To check whether the drivers report valid "algorithm", it is set
>> to default value before querying in rte_eth_dev_rss_hash_conf_get().
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>> Acked-by: Huisong Li <lihuisong@huawei.com>
>> ---
>> doc/guides/rel_notes/release_23_11.rst | 5 +++++
>> lib/ethdev/rte_ethdev.c | 26 +++++++++++++++++++++++
>> lib/ethdev/rte_ethdev.h | 29 ++++++++++++++++++++++++++
>> lib/ethdev/rte_flow.c | 1 -
>> lib/ethdev/rte_flow.h | 26 ++---------------------
>> 5 files changed, 62 insertions(+), 25 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
>> index 95db98d098d8..e207786044f9 100644
>> --- a/doc/guides/rel_notes/release_23_11.rst
>> +++ b/doc/guides/rel_notes/release_23_11.rst
>> @@ -372,6 +372,11 @@ ABI Changes
>> * security: struct ``rte_security_ipsec_sa_options`` was updated
>> due to inline out-of-place feature addition.
>>
>> +* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
>> +* reporting RSS hash algorithm capability.
>> +
>> +* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
>> + hash algorithm.
>>
>
> As well as ABI change, can you also update the "New Features", to
> document getting hash algorithm capability and setting hash algorithm
> support added?
>
> Also please add an empty line here.
thanks，will add.
>
>> Known Issues
>> ------------
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 07bb35833ba6..f9bd99d07eb1 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -1269,6 +1269,7 @@ int
>> rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>> const struct rte_eth_conf *dev_conf)
>> {
>> + enum rte_eth_hash_function algorithm;
>> struct rte_eth_dev *dev;
>> struct rte_eth_dev_info dev_info;
>> struct rte_eth_conf orig_conf;
>> @@ -1510,6 +1511,18 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
>> goto rollback;
>> }
>>
>> + algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
>> + if (RTE_ETH_HASH_ALGO_TO_CAPA(algorithm) == 0 ||
>>
>
> "RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)" can't be zero for valid "enum
> rte_eth_hash_function" values, I assume above check is for the case
> algorith > 31, as it will result zero.
> My concern is, this is undefined behaviour (shift left >= 32) and some
> compiler can complain about it, instead of relying this can you please
> add explicit "0 <= algorithm < 32" check?
yes, how about associate with "rss_algo_capa"?
+ if (algorithm >= CHAR_BIT * sizeof(dev_info.rss_algo_capa) ||
+ (dev_info.rss_algo_capa &
RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
>
>
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH v9 1/9] ethdev: overwrite some comment related to RSS
2023-11-02 8:20 3% ` [PATCH v9 0/9] " Jie Hai
@ 2023-11-02 8:20 3% ` Jie Hai
2023-11-02 8:20 4% ` [PATCH v9 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-11-02 13:11 0% ` [PATCH v9 0/9] support setting and querying RSS algorithms Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-11-02 8:20 UTC (permalink / raw)
To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
In rte_eth_dev_rss_hash_conf_get(), the "rss_key_len" should be
greater than or equal to the "hash_key_size" which get from
rte_eth_dev_info_get() API. And the "rss_key" should contain at
least "hash_key_size" bytes. If these requirements are not met,
the query unreliable.
In rte_eth_dev_rss_hash_update() or rte_eth_dev_configure(), the
"rss_key_len" indicates the length of the "rss_key" in bytes of
the array pointed by "rss_key", it should be equal to the
"hash_key_size" if "rss_key" is not NULL.
This patch overwrites the comments of fields of "rte_eth_rss_conf"
and "RTE_ETH_HASH_FUNCTION_DEFAULT", checks "rss_key_len" in
ethdev level, and documents these changes.
Signed-off-by: Jie Hai <haijie1@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 4 ++++
lib/ethdev/rte_ethdev.c | 31 ++++++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 33 ++++++++++++++------------
lib/ethdev/rte_flow.h | 1 +
4 files changed, 54 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 95db98d098d8..0b67f31dc385 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -345,6 +345,10 @@ API Changes
Updated ``rte_ml_op``, ``rte_ml_io_quantize`` and ``rte_ml_io_dequantize``
to support an array of ``rte_ml_buff_seg``.
+* ethdev: When ``rte_eth_dev_configure`` or ``rte_eth_dev_rss_hash_update`` are
+ called, the ``rss_key_len`` of structure ``rte_eth_rss_conf`` should be provided
+ by user for the case ``rss_key != NULL``, it won't be taken as default 40
+ bytes anymore.
ABI Changes
-----------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index af23ac0ad00f..6727aca12dce 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1500,6 +1500,16 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ if (dev_conf->rx_adv_conf.rss_conf.rss_key != NULL &&
+ dev_conf->rx_adv_conf.rss_conf.rss_key_len != dev_info.hash_key_size) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid RSS key len: %u, valid value: %u\n",
+ port_id, dev_conf->rx_adv_conf.rss_conf.rss_key_len,
+ dev_info.hash_key_size);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/*
* Setup new number of Rx/Tx queues and reconfigure device.
*/
@@ -4698,6 +4708,14 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -ENOTSUP;
}
+ if (rss_conf->rss_key != NULL &&
+ rss_conf->rss_key_len != dev_info.hash_key_size) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid RSS key len: %u, valid value: %u\n",
+ port_id, rss_conf->rss_key_len, dev_info.hash_key_size);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4712,6 +4730,7 @@ int
rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
struct rte_eth_rss_conf *rss_conf)
{
+ struct rte_eth_dev_info dev_info = { 0 };
struct rte_eth_dev *dev;
int ret;
@@ -4725,6 +4744,18 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ ret = rte_eth_dev_info_get(port_id, &dev_info);
+ if (ret != 0)
+ return ret;
+
+ if (rss_conf->rss_key != NULL &&
+ rss_conf->rss_key_len < dev_info.hash_key_size) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u invalid RSS key len: %u, should not be less than: %u\n",
+ port_id, rss_conf->rss_key_len, dev_info.hash_key_size);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index a53dd5a1efec..fb1a1f89c67f 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -448,24 +448,27 @@ struct rte_vlan_filter_conf {
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
- * If not NULL, the *rss_key* pointer of the *rss_conf* structure points
- * to an array holding the RSS key to use for hashing specific header
- * fields of received packets. The length of this array should be indicated
- * by *rss_key_len* below. Otherwise, a default random hash key is used by
- * the device driver.
- *
- * The *rss_key_len* field of the *rss_conf* structure indicates the length
- * in bytes of the array pointed by *rss_key*. To be compatible, this length
- * will be checked in i40e only. Others assume 40 bytes to be used as before.
- *
- * The *rss_hf* field of the *rss_conf* structure indicates the different
- * types of IPv4/IPv6 packets to which the RSS hashing must be applied.
- * Supplying an *rss_hf* equal to zero disables the RSS feature.
*/
struct rte_eth_rss_conf {
- uint8_t *rss_key; /**< If not NULL, 40-byte hash key. */
+ /**
+ * In rte_eth_dev_rss_hash_conf_get(), the *rss_key_len* should be
+ * greater than or equal to the *hash_key_size* which get from
+ * rte_eth_dev_info_get() API. And the *rss_key* should contain at least
+ * *hash_key_size* bytes. If not meet these requirements, the query
+ * result is unreliable even if the operation returns success.
+ *
+ * In rte_eth_dev_rss_hash_update() or rte_eth_dev_configure(), if
+ * *rss_key* is not NULL, the *rss_key_len* indicates the length of the
+ * *rss_key* in bytes and it should be equal to *hash_key_size*.
+ * If *rss_key* is NULL, drivers are free to use a random or a default key.
+ */
+ uint8_t *rss_key;
uint8_t rss_key_len; /**< hash key length in bytes. */
- uint64_t rss_hf; /**< Hash functions to apply - see below. */
+ /**
+ * Indicates the type of packets or the specific part of packets to
+ * which RSS hashing is to be applied.
+ */
+ uint64_t rss_hf;
};
/*
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index c16fe8c21f2f..751c29a0f3f3 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3226,6 +3226,7 @@ struct rte_flow_query_count {
* Hash function types.
*/
enum rte_eth_hash_function {
+ /** DEFAULT means driver decides which hash algorithm to pick. */
RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
--
2.30.0
^ permalink raw reply [relevance 3%]
* [PATCH v9 0/9] support setting and querying RSS algorithms
2023-11-01 7:40 3% ` [PATCH v8 00/10] " Jie Hai
@ 2023-11-02 8:20 3% ` Jie Hai
2023-11-02 8:20 3% ` [PATCH v9 1/9] ethdev: overwrite some comment related to RSS Jie Hai
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Jie Hai @ 2023-11-02 8:20 UTC (permalink / raw)
To: dev; +Cc: lihuisong, fengchengwen, liudongdong3
This patchset is to support setting and querying RSS algorithms.
For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
and field "algorithm" is added to ``rte_eth_rss_conf``.
The drivers should reports their "rss_algo_capa" if they support
updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
by field "algorithm" and the related API should verify "algorithm" with
"rss_algo_capa".
--
v9:
1. rewrite some comments.
2. modify check on rss_key_len and move it to patch 1.
3. add API change for rss_key_len.
4. add NEW Feature for RSS.
5. move modification on rss_config_display to patch 7/9.
6. update testpmd documentation.
7. add acked-bys.
v8:
1. rewrite some comments.
2. add check for rss_key_len in ethdev level.
3. add Acked-by: Huisong Li <lihuisong@huawei.com>.
4. fix log on RSS hash algorithm.
5. add rte_eth_dev_rss_algo_name to lib/ethdev/version.map.
6. fix RSS algorithm display on testpmd.
v7:
1. fix compile error.
2. add signed-off-by to patch[4/9].
v6:
1. rewrite some comments.
2. add "rss_algo_capa" for `rte_eth_dev_info``.
3. add new API to get name of RSS algorithms
v5:
1. rewrite some comments.
2. check RSS algorithm for drivers supporting RSS.
3. change field "func" of rss_conf to "algorithm".
4. fix commit log for [PATCH v4 4/7].
5. add Acked-by Reshma Pattan.
6. add symmetric_toeplitz_sort for showing.
7. change "hf" to "hash function" for showing.
v4:
1. recomment some definitions related to RSS.
2. allocate static memory for rss_key instead of dynamic.
3. use array of strings to get the name of rss algorithm.
4. add display of rss algorithm with testpmd.
v3:
1. fix commit log for PATCH [1/5].
2. make RSS ABI changes description to start the actual text at the margin.
3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
4. fix some comment codes.
v2:
1. return error if "func" is invalid.
2. modify the comments of the "func" field.
3. modify commit log of patch [3/5].
4. use malloc instead of rte_malloc.
5. adjust display format of RSS info.
6. remove the string display of rss_hf.
Huisong Li (1):
net/hns3: support setting and querying RSS hash function
Jie Hai (8):
ethdev: overwrite some comment related to RSS
ethdev: support setting and querying RSS algorithm
net/hns3: report RSS hash algorithms capability
app/proc-info: fix never show RSS info
app/proc-info: adjust the display format of RSS info
ethdev: add API to get RSS algorithm names
app/proc-info: support querying RSS hash algorithm
app/testpmd: add RSS hash algorithms display
app/proc-info/main.c | 24 +++---
app/test-pmd/cmdline.c | 29 ++++++--
app/test-pmd/config.c | 29 +++-----
app/test-pmd/testpmd.h | 2 +-
doc/guides/rel_notes/release_23_11.rst | 22 ++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +-
drivers/net/hns3/hns3_common.c | 4 +
drivers/net/hns3/hns3_rss.c | 47 +++++++-----
lib/ethdev/rte_ethdev.c | 81 +++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 78 ++++++++++++++++----
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 25 +------
lib/ethdev/version.map | 1 +
13 files changed, 252 insertions(+), 95 deletions(-)
--
2.30.0
^ permalink raw reply [relevance 3%]
* [PATCH v9 2/9] ethdev: support setting and querying RSS algorithm
2023-11-02 8:20 3% ` [PATCH v9 0/9] " Jie Hai
2023-11-02 8:20 3% ` [PATCH v9 1/9] ethdev: overwrite some comment related to RSS Jie Hai
@ 2023-11-02 8:20 4% ` Jie Hai
2023-11-02 13:11 0% ` [PATCH v9 0/9] support setting and querying RSS algorithms Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Jie Hai @ 2023-11-02 8:20 UTC (permalink / raw)
To: dev, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam
Cc: lihuisong, fengchengwen, liudongdong3
Currently, rte_eth_rss_conf supports configuring and querying
RSS hash functions, rss key and it's length, but not RSS hash
algorithm.
The structure ``rte_eth_dev_info`` is extended by adding a new
field "rss_algo_capa". Drivers are responsible for reporting this
capa and configurations of RSS hash algorithm can be verified based
on the capability. The default value of "rss_algo_capa" is
RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT) if drivers do not report it.
The structure ``rte_eth_rss_conf`` is extended by adding a new
field "algorithm". This represents the RSS algorithms to apply.
If the value of "algorithm" used for configuration is a gibberish
value, drivers should report the error.
To check whether the drivers report valid "algorithm", it is set
to default value before querying in rte_eth_dev_rss_hash_conf_get().
Signed-off-by: Jie Hai <haijie1@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Acked-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
doc/guides/rel_notes/release_23_11.rst | 13 ++++++++++++
lib/ethdev/rte_ethdev.c | 25 ++++++++++++++++++++++
lib/ethdev/rte_ethdev.h | 29 ++++++++++++++++++++++++++
lib/ethdev/rte_flow.c | 1 -
lib/ethdev/rte_flow.h | 26 ++---------------------
5 files changed, 69 insertions(+), 25 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_11.rst b/doc/guides/rel_notes/release_23_11.rst
index 0b67f31dc385..20556b8a17ce 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -122,6 +122,13 @@ New Features
a group's miss actions, which are the actions to be performed on packets
that didn't match any of the flow rules in the group.
+* **Added support for RSS hash algorithm.**
+
+ * Added new field ``rss_algo_capa`` to ``rte_eth_dev_info`` structure for
+ reporting RSS hash algorithm capability that drivers support.
+ * Added new field ``algorithm`` to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm querying and configuring.
+
* **Updated Amazon ena (Elastic Network Adapter) net driver.**
* Upgraded ENA HAL to latest version.
@@ -376,6 +383,12 @@ ABI Changes
* security: struct ``rte_security_ipsec_sa_options`` was updated
due to inline out-of-place feature addition.
+* ethdev: Added "rss_algo_capa" field to ``rte_eth_dev_info`` structure for
+* reporting RSS hash algorithm capability.
+
+* ethdev: Added "algorithm" field to ``rte_eth_rss_conf`` structure for RSS
+ hash algorithm.
+
Known Issues
------------
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 6727aca12dce..36d8deef90c5 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -1269,6 +1269,7 @@ int
rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
{
+ enum rte_eth_hash_function algorithm;
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
struct rte_eth_conf orig_conf;
@@ -1510,6 +1511,17 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
goto rollback;
}
+ algorithm = dev_conf->rx_adv_conf.rss_conf.algorithm;
+ if (algorithm >= CHAR_BIT * sizeof(dev_info.rss_algo_capa) ||
+ (dev_info.rss_algo_capa & RTE_ETH_HASH_ALGO_TO_CAPA(algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u configured RSS hash algorithm (%u)"
+ "is not in the algorithm capability (0x%" PRIx32 ")\n",
+ port_id, algorithm, dev_info.rss_algo_capa);
+ ret = -EINVAL;
+ goto rollback;
+ }
+
/*
* Setup new number of Rx/Tx queues and reconfigure device.
*/
@@ -3767,6 +3779,7 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->min_mtu = RTE_ETHER_MIN_LEN - RTE_ETHER_HDR_LEN -
RTE_ETHER_CRC_LEN;
dev_info->max_mtu = UINT16_MAX;
+ dev_info->rss_algo_capa = RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT);
if (*dev->dev_ops->dev_infos_get == NULL)
return -ENOTSUP;
@@ -4716,6 +4729,16 @@ rte_eth_dev_rss_hash_update(uint16_t port_id,
return -EINVAL;
}
+ if (rss_conf->algorithm >= CHAR_BIT * sizeof(dev_info.rss_algo_capa) ||
+ (dev_info.rss_algo_capa &
+ RTE_ETH_HASH_ALGO_TO_CAPA(rss_conf->algorithm)) == 0) {
+ RTE_ETHDEV_LOG(ERR,
+ "Ethdev port_id=%u configured RSS hash algorithm (%u)"
+ "is not in the algorithm capability (0x%" PRIx32 ")\n",
+ port_id, rss_conf->algorithm, dev_info.rss_algo_capa);
+ return -EINVAL;
+ }
+
if (*dev->dev_ops->rss_hash_update == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_update)(dev,
@@ -4756,6 +4779,8 @@ rte_eth_dev_rss_hash_conf_get(uint16_t port_id,
return -EINVAL;
}
+ rss_conf->algorithm = RTE_ETH_HASH_FUNCTION_DEFAULT;
+
if (*dev->dev_ops->rss_hash_conf_get == NULL)
return -ENOTSUP;
ret = eth_err(port_id, (*dev->dev_ops->rss_hash_conf_get)(dev,
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index fb1a1f89c67f..37d8ef694523 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -445,6 +445,33 @@ struct rte_vlan_filter_conf {
uint64_t ids[64];
};
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ /** DEFAULT means driver decides which hash algorithm to pick. */
+ RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ /**
+ * Symmetric Toeplitz: src, dst will be replaced by
+ * xor(src, dst). For the case with src/dst only,
+ * src or dst address will xor with zero pair.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
+ /**
+ * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
+ * the hash function.
+ * If src_ip > dst_ip, swap src_ip and dst_ip.
+ * If src_port > dst_port, swap src_port and dst_port.
+ */
+ RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+#define RTE_ETH_HASH_ALGO_TO_CAPA(x) RTE_BIT32(x)
+#define RTE_ETH_HASH_ALGO_CAPA_MASK(x) RTE_BIT32(RTE_ETH_HASH_FUNCTION_ ## x)
+
/**
* A structure used to configure the Receive Side Scaling (RSS) feature
* of an Ethernet port.
@@ -469,6 +496,7 @@ struct rte_eth_rss_conf {
* which RSS hashing is to be applied.
*/
uint64_t rss_hf;
+ enum rte_eth_hash_function algorithm; /**< Hash algorithm. */
};
/*
@@ -1749,6 +1777,7 @@ struct rte_eth_dev_info {
/** Device redirection table size, the total number of entries. */
uint16_t reta_size;
uint8_t hash_key_size; /**< Hash key size in bytes */
+ uint32_t rss_algo_capa; /** RSS hash algorithms capabilities */
/** Bit mask of RSS offloads, the bit offset also means flow type */
uint64_t flow_type_rss_offloads;
struct rte_eth_rxconf default_rxconf; /**< Default Rx configuration */
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 20ee8430eaec..549e3295584c 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -13,7 +13,6 @@
#include <rte_branch_prediction.h>
#include <rte_string_fns.h>
#include <rte_mbuf_dyn.h>
-#include "rte_ethdev.h"
#include "rte_flow_driver.h"
#include "rte_flow.h"
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 751c29a0f3f3..affdc8121b57 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -40,6 +40,8 @@
#include <rte_macsec.h>
#include <rte_ib.h>
+#include "rte_ethdev.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -3222,30 +3224,6 @@ struct rte_flow_query_count {
uint64_t bytes; /**< Number of bytes through this rule [out]. */
};
-/**
- * Hash function types.
- */
-enum rte_eth_hash_function {
- /** DEFAULT means driver decides which hash algorithm to pick. */
- RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
- RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
- RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
- /**
- * Symmetric Toeplitz: src, dst will be replaced by
- * xor(src, dst). For the case with src/dst only,
- * src or dst address will xor with zero pair.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ,
- /**
- * Symmetric Toeplitz: L3 and L4 fields are sorted prior to
- * the hash function.
- * If src_ip > dst_ip, swap src_ip and dst_ip.
- * If src_port > dst_port, swap src_port and dst_port.
- */
- RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ_SORT,
- RTE_ETH_HASH_FUNCTION_MAX,
-};
-
/**
* RTE_FLOW_ACTION_TYPE_RSS
*
--
2.30.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2
@ 2023-11-02 10:23 4% ` Bruce Richardson
2023-11-02 10:48 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-11-02 10:23 UTC (permalink / raw)
To: Sevincer, Abdullah
Cc: Jerin Jacob, dev, jerinj, Chen, Mike Ximing, stable, Marchand,
David, Thomas Monjalon, Xia, Chenbo, nipun.gupta
On Wed, Nov 01, 2023 at 07:05:54PM +0000, Sevincer, Abdullah wrote:
>
> >++ PCIe maintainers.
>
> >+I will leave this up to @David Marchand / @Thomas as this patch has common code changes and needs to come via main tree.
>
> >+Also in this case, The comment was given very early(Back in June 7) for the same.
> >+https://patches.dpdk.org/project/dpdk/patch/20230607210050.107944-1-abdullah.sevincer@intel.com/
>
> Thanks Jerrin and Bruce for the comments.
> I will wait for opinion of PCI maintainers.
Thinking on this more, any API for enable/disable pasid would be
internal-only, so therefore would not be subject to ABI/API change rules
AFAIK. This gives us more freedom to change it as more discovery
capabilities become available.
Therefore, an initial version of the function can take the offset as
parameter, and we can update it without API/ABI concerns later. I was
previously worried about trying to get the API correct first time, but for
internal functions, we don't need to.
WDYT, Jerin, Abdullah.
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2
2023-11-02 10:23 4% ` Bruce Richardson
@ 2023-11-02 10:48 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-11-02 10:48 UTC (permalink / raw)
To: Sevincer, Abdullah, Bruce Richardson
Cc: Jerin Jacob, dev, jerinj, Chen, Mike Ximing, stable, Marchand,
David, Xia, Chenbo, nipun.gupta
02/11/2023 11:23, Bruce Richardson:
> On Wed, Nov 01, 2023 at 07:05:54PM +0000, Sevincer, Abdullah wrote:
> >
> > >++ PCIe maintainers.
> >
> > >+I will leave this up to @David Marchand / @Thomas as this patch has common code changes and needs to come via main tree.
> >
> > >+Also in this case, The comment was given very early(Back in June 7) for the same.
> > >+https://patches.dpdk.org/project/dpdk/patch/20230607210050.107944-1-abdullah.sevincer@intel.com/
> >
> > Thanks Jerrin and Bruce for the comments.
> > I will wait for opinion of PCI maintainers.
>
> Thinking on this more, any API for enable/disable pasid would be
> internal-only, so therefore would not be subject to ABI/API change rules
> AFAIK. This gives us more freedom to change it as more discovery
> capabilities become available.
> Therefore, an initial version of the function can take the offset as
> parameter, and we can update it without API/ABI concerns later. I was
> previously worried about trying to get the API correct first time, but for
> internal functions, we don't need to.
It looks a good option.
Better to add an internal PCI function than doing it in a PMD.
> WDYT, Jerin, Abdullah.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v9 0/9] support setting and querying RSS algorithms
2023-11-02 8:20 3% ` [PATCH v9 0/9] " Jie Hai
2023-11-02 8:20 3% ` [PATCH v9 1/9] ethdev: overwrite some comment related to RSS Jie Hai
2023-11-02 8:20 4% ` [PATCH v9 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
@ 2023-11-02 13:11 0% ` Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-11-02 13:11 UTC (permalink / raw)
To: Jie Hai, dev; +Cc: lihuisong, fengchengwen, liudongdong3
On 11/2/2023 8:20 AM, Jie Hai wrote:
> This patchset is to support setting and querying RSS algorithms.
> For this purpose, field "rss_algo_capa" is added to ``rte_eth_dev_info``
> and field "algorithm" is added to ``rte_eth_rss_conf``.
> The drivers should reports their "rss_algo_capa" if they support
> updating RSS algorithms. Otherwise, the "rss_algo_capa" is set to
> RTE_ETH_HASH_ALGO_CAPA_MASK(DEFAULT). The app configures RSS algorithms
> by field "algorithm" and the related API should verify "algorithm" with
> "rss_algo_capa".
>
> --
> v9:
> 1. rewrite some comments.
> 2. modify check on rss_key_len and move it to patch 1.
> 3. add API change for rss_key_len.
> 4. add NEW Feature for RSS.
> 5. move modification on rss_config_display to patch 7/9.
> 6. update testpmd documentation.
> 7. add acked-bys.
>
> v8:
> 1. rewrite some comments.
> 2. add check for rss_key_len in ethdev level.
> 3. add Acked-by: Huisong Li <lihuisong@huawei.com>.
> 4. fix log on RSS hash algorithm.
> 5. add rte_eth_dev_rss_algo_name to lib/ethdev/version.map.
> 6. fix RSS algorithm display on testpmd.
>
> v7:
> 1. fix compile error.
> 2. add signed-off-by to patch[4/9].
> v6:
> 1. rewrite some comments.
> 2. add "rss_algo_capa" for `rte_eth_dev_info``.
> 3. add new API to get name of RSS algorithms
>
> v5:
> 1. rewrite some comments.
> 2. check RSS algorithm for drivers supporting RSS.
> 3. change field "func" of rss_conf to "algorithm".
> 4. fix commit log for [PATCH v4 4/7].
> 5. add Acked-by Reshma Pattan.
> 6. add symmetric_toeplitz_sort for showing.
> 7. change "hf" to "hash function" for showing.
>
> v4:
> 1. recomment some definitions related to RSS.
> 2. allocate static memory for rss_key instead of dynamic.
> 3. use array of strings to get the name of rss algorithm.
> 4. add display of rss algorithm with testpmd.
>
> v3:
> 1. fix commit log for PATCH [1/5].
> 2. make RSS ABI changes description to start the actual text at the margin.
> 3. move defnition of enum rte_eth_hash_function to rte_ethdev.h.
> 4. fix some comment codes.
>
> v2:
> 1. return error if "func" is invalid.
> 2. modify the comments of the "func" field.
> 3. modify commit log of patch [3/5].
> 4. use malloc instead of rte_malloc.
> 5. adjust display format of RSS info.
> 6. remove the string display of rss_hf.
>
> Huisong Li (1):
> net/hns3: support setting and querying RSS hash function
>
> Jie Hai (8):
> ethdev: overwrite some comment related to RSS
> ethdev: support setting and querying RSS algorithm
> net/hns3: report RSS hash algorithms capability
> app/proc-info: fix never show RSS info
> app/proc-info: adjust the display format of RSS info
> ethdev: add API to get RSS algorithm names
> app/proc-info: support querying RSS hash algorithm
> app/testpmd: add RSS hash algorithms display
>
>
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@amd.com>
Series applied to dpdk-next-net/main, thanks.
^ permalink raw reply [relevance 0%]
* Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
@ 2023-11-02 18:37 3% ` Stephen Hemminger
2023-11-07 17:33 0% ` rahul gupta
2023-11-08 4:38 0% ` Rahul Gupta
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2023-11-02 18:37 UTC (permalink / raw)
To: Rahul Gupta
Cc: dev, thomas, sovaradh, okaya, sujithsankar, sowmini.varadhan,
rahulrgupta27, Rahul Gupta
On Thu, 2 Nov 2023 11:19:24 -0700
Rahul Gupta <rahulgupt@linux.microsoft.com> wrote:
> From: Rahul Gupta <rahulgupt@linux.microsoft.com>
> To: dev@dpdk.org, thomas@monjalon.net
> Cc: sovaradh@linux.microsoft.com, okaya@kernel.org, sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com, rahulrgupta27@gmail.com, Rahul Gupta <rahulgupt@microsoft.com>, Rahul Gupta <rahulgupt@linux.microsoft.com>
> Subject: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
> Date: Thu, 2 Nov 2023 11:19:24 -0700
> X-Mailer: git-send-email 1.8.3.1
>
> From: Rahul Gupta <rahulgupt@microsoft.com>
>
> Initialization often requires rte_eal_init + rte_pktmbuf_pool_create
> which can consume a total time of 500-600 ms:
> a) For many devices FLR may take a significant chunk of time
> (200-250 ms in our use-case), this FLR is triggered during device
> probe in rte_eal_init().
> b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for
> applications that require huge memory.
>
> This cost is incurred on each restart (which happens in our use-case
> during binary updates for servicing).
> This patch provides an optimization using pthreads that appplications
> can use and which can save 200-230ms.
>
> In this patch, rte_eal_init() is refactored into two parts-
> a) 1st part is dependent code ie- it’s a perquisite of the FLR and
> mempool creation. So this code needs to be executed before any
> pthreads. Its named as rte_eal_init_setup()
> b) 2nd part of code is independent code ie- it can execute in parallel
> to mempool creation in a pthread. Its named as rte_probe_and_ioctl().
>
> Existing applications require no changes unless they wish to leverage
> the optimization.
>
> If the application wants to use pthread functionality, it should call-
> a) rte_eal_init_setup() then create two or more pthreads-
> b) in one pthread call- rte_probe_and_ioctl(),
> c) second pthread call- rte_pktmbuf_pool_create()
> d) (optional) Other pthreads for any other independent function.
>
> Signed-off-by: Rahul Gupta <rahulgupt@linux.microsoft.com>
These probably marked internal rather than part of API/ABI.
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 1/5] kvargs: add one new process API
@ 2023-11-06 3:18 4% ` Stephen Hemminger
2023-11-06 7:13 0% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-11-06 3:18 UTC (permalink / raw)
To: Chengwen Feng; +Cc: thomas, ferruh.yigit, dev
On Sun, 5 Nov 2023 05:45:35 +0000
Chengwen Feng <fengchengwen@huawei.com> wrote:
> +* **Updated kvargs process API.**
> +
> + * Introduced rte_kvargs_process_opt() API, which inherits the function
> + of rte_kvargs_process() and could handle both key=value and only-key
> + cases.
> +
> + * Constraint rte_kvargs_process() API can only handle key=value cases,
> + it will return -1 when handle only-key case (that is the matched key's
> + value is NULL).
> +
Looks good but may I suggest some alternatives.
Since this is an API and ABI change as was not announced, maybe a little late
in the process for this release. And since unlikely to go in 23.11 need to do something
better in 24.03.
What about changing the args to rte_kvargs_process() to add an additional default
value. Most callers don't have a default (use key-value) but the ones that take only-key
would pass the default value.
Then use ABI versioning to add the new arg and you would not have to introduce
a new function. And add a legacy API version that does what current code does.
All the drivers in DPDK would get the new API/ABI but any customer apps using rte_kvargs_process()
would get the old version.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 1/5] kvargs: add one new process API
2023-11-06 3:18 4% ` Stephen Hemminger
@ 2023-11-06 7:13 0% ` fengchengwen
2023-11-06 16:19 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: fengchengwen @ 2023-11-06 7:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: thomas, ferruh.yigit, dev
Hi Stephen,
On 2023/11/6 11:18, Stephen Hemminger wrote:
> On Sun, 5 Nov 2023 05:45:35 +0000
> Chengwen Feng <fengchengwen@huawei.com> wrote:
>
>> +* **Updated kvargs process API.**
>> +
>> + * Introduced rte_kvargs_process_opt() API, which inherits the function
>> + of rte_kvargs_process() and could handle both key=value and only-key
>> + cases.
>> +
>> + * Constraint rte_kvargs_process() API can only handle key=value cases,
>> + it will return -1 when handle only-key case (that is the matched key's
>> + value is NULL).
>> +
>
> Looks good but may I suggest some alternatives.
>
> Since this is an API and ABI change as was not announced, maybe a little late
> in the process for this release. And since unlikely to go in 23.11 need to do something
> better in 24.03.
>
> What about changing the args to rte_kvargs_process() to add an additional default
> value. Most callers don't have a default (use key-value) but the ones that take only-key
> would pass the default value.
The API definition changed, it may need modify most drivers.
Although it's a little late, better continue current.
Thanks
Chengwen
>
> Then use ABI versioning to add the new arg and you would not have to introduce
> a new function. And add a legacy API version that does what current code does.
>
> All the drivers in DPDK would get the new API/ABI but any customer apps using rte_kvargs_process()
> would get the old version.
>
>
> .
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/5] kvargs: add one new process API
2023-11-06 7:13 0% ` fengchengwen
@ 2023-11-06 16:19 0% ` Stephen Hemminger
2023-11-07 3:21 0% ` fengchengwen
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-11-06 16:19 UTC (permalink / raw)
To: fengchengwen; +Cc: thomas, ferruh.yigit, dev
On Mon, 6 Nov 2023 15:13:35 +0800
fengchengwen <fengchengwen@huawei.com> wrote:
> >> +
> >
> > Looks good but may I suggest some alternatives.
> >
> > Since this is an API and ABI change as was not announced, maybe a little late
> > in the process for this release. And since unlikely to go in 23.11 need to do something
> > better in 24.03.
> >
> > What about changing the args to rte_kvargs_process() to add an additional default
> > value. Most callers don't have a default (use key-value) but the ones that take only-key
> > would pass the default value.
>
> The API definition changed, it may need modify most drivers.
>
> Although it's a little late, better continue current.
>
> Thanks
> Chengwen
Looking ahead, I would like to replace all of EAL args and KVargs processing
with something more like the python parseargs library. The API is cleaner and
incorporating the help with arg parsing is a real benefit. Thomas also suggested
integrating help in the arg parsing.
Something like: https://github.com/cofyc/argparse
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/5] kvargs: add one new process API
2023-11-06 16:19 0% ` Stephen Hemminger
@ 2023-11-07 3:21 0% ` fengchengwen
0 siblings, 0 replies; 200+ results
From: fengchengwen @ 2023-11-07 3:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: thomas, ferruh.yigit, dev
Hi Stephen,
On 2023/11/7 0:19, Stephen Hemminger wrote:
> On Mon, 6 Nov 2023 15:13:35 +0800
> fengchengwen <fengchengwen@huawei.com> wrote:
>
>>>> +
>>>
>>> Looks good but may I suggest some alternatives.
>>>
>>> Since this is an API and ABI change as was not announced, maybe a little late
>>> in the process for this release. And since unlikely to go in 23.11 need to do something
>>> better in 24.03.
>>>
>>> What about changing the args to rte_kvargs_process() to add an additional default
>>> value. Most callers don't have a default (use key-value) but the ones that take only-key
>>> would pass the default value.
>>
>> The API definition changed, it may need modify most drivers.
>>
>> Although it's a little late, better continue current.
>>
>> Thanks
>> Chengwen
>
> Looking ahead, I would like to replace all of EAL args and KVargs processing
> with something more like the python parseargs library. The API is cleaner and
> incorporating the help with arg parsing is a real benefit. Thomas also suggested
> integrating help in the arg parsing.
>
> Something like: https://github.com/cofyc/argparse
The argparse is great, especial it integrate help in the arg parsing, which could help
for parse args.
I will propose a argparse library RFC later, and we could both work on it.
As for this commit, I think it has difference: the KV pair was not separated by spaces,
So for: dpdk-testpmd -a 0000:7d:00.0,a=1,b=2,c=3 --file-prefix=feng
We could parse 'a' has value: 0000:7d:00.0,a=1,b=2,c=3
'file-prefix' has value: feng
by argparse.
and then use kvargs to parse a=1,b=2,c=3.
Thanks
Chengwen
>
> .
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7 0/3] add telemetry cmds for ring
` (2 preceding siblings ...)
2023-10-28 9:50 0% ` Jie Hai
@ 2023-11-08 2:55 0% ` lihuisong (C)
3 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-11-08 2:55 UTC (permalink / raw)
To: Jie Hai; +Cc: dev, liudongdong3
lgtm, for series,
Acked-by: Huisong Li <lihuisong@huawei.com>
在 2023/7/4 17:04, Jie Hai 写道:
> This patch set supports telemetry cmd to list rings and dump information
> of a ring by its name.
>
> v1->v2:
> 1. Add space after "switch".
> 2. Fix wrong strlen parameter.
>
> v2->v3:
> 1. Remove prefix "rte_" for static function.
> 2. Add Acked-by Konstantin Ananyev for PATCH 1.
> 3. Introduce functions to return strings instead copy strings.
> 4. Check pointer to memzone of ring.
> 5. Remove redundant variable.
> 6. Hold lock when access ring data.
>
> v3->v4:
> 1. Update changelog according to reviews of Honnappa Nagarahalli.
> 2. Add Reviewed-by Honnappa Nagarahalli.
> 3. Correct grammar in help information.
> 4. Correct spell warning on "te" reported by checkpatch.pl.
> 5. Use ring_walk() to query ring info instead of rte_ring_lookup().
> 6. Fix that type definition the flag field of rte_ring does not match the usage.
> 7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
> for mask and flags.
>
> v4->v5:
> 1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
> 2. Add ABI change explanation for commit message of patch 1/3.
>
> v5->v6:
> 1. Add Acked-by Morten Brørup.
> 2. Fix incorrect reference of commit.
>
> v6->v7:
> 1. Remove prod/consumer head/tail info.
>
> Jie Hai (3):
> ring: fix unmatched type definition and usage
> ring: add telemetry cmd to list rings
> ring: add telemetry cmd for ring info
>
> lib/ring/meson.build | 1 +
> lib/ring/rte_ring.c | 135 +++++++++++++++++++++++++++++++++++++++
> lib/ring/rte_ring_core.h | 2 +-
> 3 files changed, 137 insertions(+), 1 deletion(-)
>
^ permalink raw reply [relevance 0%]
* Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
2023-11-02 18:37 3% ` Stephen Hemminger
2023-11-07 17:33 0% ` rahul gupta
@ 2023-11-08 4:38 0% ` Rahul Gupta
1 sibling, 0 replies; 200+ results
From: Rahul Gupta @ 2023-11-08 4:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, thomas, sovaradh, okaya, sujithsankar, sowmini.varadhan,
rahulrgupta27, Rahul Gupta, Rahul Gupta
On (11/02/23 11:37), Stephen Hemminger wrote:
> Date: Thu, 2 Nov 2023 11:37:59 -0700
> From: Stephen Hemminger <stephen@networkplumber.org>
> To: Rahul Gupta <rahulgupt@linux.microsoft.com>
> Cc: dev@dpdk.org, thomas@monjalon.net, sovaradh@linux.microsoft.com,
> okaya@kernel.org, sujithsankar@microsoft.com,
> sowmini.varadhan@microsoft.com, rahulrgupta27@gmail.com, Rahul Gupta
> <rahulgupt@microsoft.com>
> Subject: Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu)
>
> On Thu, 2 Nov 2023 11:19:24 -0700
> Rahul Gupta <rahulgupt@linux.microsoft.com> wrote:
>
> > From: Rahul Gupta <rahulgupt@linux.microsoft.com>
> > To: dev@dpdk.org, thomas@monjalon.net
> > Cc: sovaradh@linux.microsoft.com, okaya@kernel.org, sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com, rahulrgupta27@gmail.com, Rahul Gupta <rahulgupt@microsoft.com>, Rahul Gupta <rahulgupt@linux.microsoft.com>
> > Subject: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
> > Date: Thu, 2 Nov 2023 11:19:24 -0700
> > X-Mailer: git-send-email 1.8.3.1
> >
> > From: Rahul Gupta <rahulgupt@microsoft.com>
> >
> > Initialization often requires rte_eal_init + rte_pktmbuf_pool_create
> > which can consume a total time of 500-600 ms:
> > a) For many devices FLR may take a significant chunk of time
> > (200-250 ms in our use-case), this FLR is triggered during device
> > probe in rte_eal_init().
> > b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for
> > applications that require huge memory.
> >
> > This cost is incurred on each restart (which happens in our use-case
> > during binary updates for servicing).
> > This patch provides an optimization using pthreads that appplications
> > can use and which can save 200-230ms.
> >
> > In this patch, rte_eal_init() is refactored into two parts-
> > a) 1st part is dependent code ie- it’s a perquisite of the FLR and
> > mempool creation. So this code needs to be executed before any
> > pthreads. Its named as rte_eal_init_setup()
> > b) 2nd part of code is independent code ie- it can execute in parallel
> > to mempool creation in a pthread. Its named as rte_probe_and_ioctl().
> >
> > Existing applications require no changes unless they wish to leverage
> > the optimization.
> >
> > If the application wants to use pthread functionality, it should call-
> > a) rte_eal_init_setup() then create two or more pthreads-
> > b) in one pthread call- rte_probe_and_ioctl(),
> > c) second pthread call- rte_pktmbuf_pool_create()
> > d) (optional) Other pthreads for any other independent function.
> >
> > Signed-off-by: Rahul Gupta <rahulgupt@linux.microsoft.com>
>
> These probably marked internal rather than part of API/ABI.
Hi Stephen,
Thanks for your review.
If I make it __rte_internal then, testpmd or our application can't use it.
So instead I am planning to make it __rte_experimental.
Regards,
Rahul.
^ permalink raw reply [relevance 0%]
* Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
2023-11-02 18:37 3% ` Stephen Hemminger
@ 2023-11-07 17:33 0% ` rahul gupta
2023-11-08 4:38 0% ` Rahul Gupta
1 sibling, 0 replies; 200+ results
From: rahul gupta @ 2023-11-07 17:33 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Rahul Gupta, dev, thomas, sovaradh, okaya, sujithsankar,
sowmini.varadhan, Rahul Gupta
[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]
Hi Stephen,
Thanks for your review.
If I make it __rte_internal then, testpmd or our application can't use it.
So instead I am planning to make it __rte_experimental.
Regards,
Rahul.
On Fri, 3 Nov 2023 at 00:08, Stephen Hemminger <stephen@networkplumber.org>
wrote:
> On Thu, 2 Nov 2023 11:19:24 -0700
> Rahul Gupta <rahulgupt@linux.microsoft.com> wrote:
>
> > From: Rahul Gupta <rahulgupt@linux.microsoft.com>
> > To: dev@dpdk.org, thomas@monjalon.net
> > Cc: sovaradh@linux.microsoft.com, okaya@kernel.org,
> sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com,
> rahulrgupta27@gmail.com, Rahul Gupta <rahulgupt@microsoft.com>, Rahul
> Gupta <rahulgupt@linux.microsoft.com>
> > Subject: [RFC] eal: RFC to refactor rte_eal_init into sub-functions
> > Date: Thu, 2 Nov 2023 11:19:24 -0700
> > X-Mailer: git-send-email 1.8.3.1
> >
> > From: Rahul Gupta <rahulgupt@microsoft.com>
> >
> > Initialization often requires rte_eal_init + rte_pktmbuf_pool_create
> > which can consume a total time of 500-600 ms:
> > a) For many devices FLR may take a significant chunk of time
> > (200-250 ms in our use-case), this FLR is triggered during device
> > probe in rte_eal_init().
> > b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for
> > applications that require huge memory.
> >
> > This cost is incurred on each restart (which happens in our use-case
> > during binary updates for servicing).
> > This patch provides an optimization using pthreads that appplications
> > can use and which can save 200-230ms.
> >
> > In this patch, rte_eal_init() is refactored into two parts-
> > a) 1st part is dependent code ie- it’s a perquisite of the FLR and
> > mempool creation. So this code needs to be executed before any
> > pthreads. Its named as rte_eal_init_setup()
> > b) 2nd part of code is independent code ie- it can execute in parallel
> > to mempool creation in a pthread. Its named as rte_probe_and_ioctl().
> >
> > Existing applications require no changes unless they wish to leverage
> > the optimization.
> >
> > If the application wants to use pthread functionality, it should call-
> > a) rte_eal_init_setup() then create two or more pthreads-
> > b) in one pthread call- rte_probe_and_ioctl(),
> > c) second pthread call- rte_pktmbuf_pool_create()
> > d) (optional) Other pthreads for any other independent function.
> >
> > Signed-off-by: Rahul Gupta <rahulgupt@linux.microsoft.com>
>
> These probably marked internal rather than part of API/ABI.
>
[-- Attachment #2: Type: text/html, Size: 4000 bytes --]
^ permalink raw reply [relevance 0%]
* [RESEND v7 1/3] ring: fix unmatched type definition and usage
2023-11-09 10:20 3% ` [RESEND v7 0/3] add telemetry cmds for ring Jie Hai
@ 2023-11-09 10:20 3% ` Jie Hai
2023-11-09 12:26 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Jie Hai @ 2023-11-09 10:20 UTC (permalink / raw)
To: honnappa.nagarahalli, konstantin.v.ananyev, dev, thomas,
david.marchand, Ruifeng.Wang, mb
Cc: lihuisong, fengchengwen, liudongdong3
Field 'flags' of struct rte_ring is defined as int type. However,
it is used as unsigned int. To ensure consistency, change the
type of flags to unsigned int. Since these two types has the
same byte size, this change is not an ABI change.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Jie Hai <haijie1@huawei.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
lib/ring/rte_ring_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ring/rte_ring_core.h b/lib/ring/rte_ring_core.h
index b7708730658a..14dac6495d83 100644
--- a/lib/ring/rte_ring_core.h
+++ b/lib/ring/rte_ring_core.h
@@ -119,7 +119,7 @@ struct rte_ring_hts_headtail {
struct rte_ring {
char name[RTE_RING_NAMESIZE] __rte_cache_aligned;
/**< Name of the ring. */
- int flags; /**< Flags supplied at creation. */
+ uint32_t flags; /**< Flags supplied at creation. */
const struct rte_memzone *memzone;
/**< Memzone, if any, containing the rte_ring */
uint32_t size; /**< Size of ring. */
--
2.30.0
^ permalink raw reply [relevance 3%]
* [RESEND v7 0/3] add telemetry cmds for ring
@ 2023-11-09 10:20 3% ` Jie Hai
2023-11-09 10:20 3% ` [RESEND v7 1/3] ring: fix unmatched type definition and usage Jie Hai
0 siblings, 1 reply; 200+ results
From: Jie Hai @ 2023-11-09 10:20 UTC (permalink / raw)
To: honnappa.nagarahalli, konstantin.v.ananyev, dev, thomas,
david.marchand, Ruifeng.Wang, mb
Cc: lihuisong, fengchengwen, liudongdong3
This patch set supports telemetry cmd to list rings and dump information
of a ring by its name.
v1->v2:
1. Add space after "switch".
2. Fix wrong strlen parameter.
v2->v3:
1. Remove prefix "rte_" for static function.
2. Add Acked-by Konstantin Ananyev for PATCH 1.
3. Introduce functions to return strings instead copy strings.
4. Check pointer to memzone of ring.
5. Remove redundant variable.
6. Hold lock when access ring data.
v3->v4:
1. Update changelog according to reviews of Honnappa Nagarahalli.
2. Add Reviewed-by Honnappa Nagarahalli.
3. Correct grammar in help information.
4. Correct spell warning on "te" reported by checkpatch.pl.
5. Use ring_walk() to query ring info instead of rte_ring_lookup().
6. Fix that type definition the flag field of rte_ring does not match the usage.
7. Use rte_tel_data_add_dict_uint_hex instead of rte_tel_data_add_dict_u64
for mask and flags.
v4->v5:
1. Add Acked-by Konstantin Ananyev and Chengwen Feng.
2. Add ABI change explanation for commit message of patch 1/3.
v5->v6:
1. Add Acked-by Morten Br?rup.
2. Fix incorrect reference of commit.
v6->v7:
1. Remove prod/consumer head/tail info.
Jie Hai (3):
ring: fix unmatched type definition and usage
ring: add telemetry cmd to list rings
ring: add telemetry cmd for ring info
lib/ring/meson.build | 1 +
lib/ring/rte_ring.c | 135 +++++++++++++++++++++++++++++++++++++++
lib/ring/rte_ring_core.h | 2 +-
3 files changed, 137 insertions(+), 1 deletion(-)
--
2.30.0
^ permalink raw reply [relevance 3%]
* Re: [RESEND v7 1/3] ring: fix unmatched type definition and usage
2023-11-09 10:20 3% ` [RESEND v7 1/3] ring: fix unmatched type definition and usage Jie Hai
@ 2023-11-09 12:26 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-11-09 12:26 UTC (permalink / raw)
To: Jie Hai, honnappa.nagarahalli, konstantin.v.ananyev, dev, thomas,
david.marchand, Ruifeng.Wang, mb
Cc: fengchengwen, liudongdong3
Acked-by: Huisong Li <lihuisong@huawei.com>
在 2023/11/9 18:20, Jie Hai 写道:
> Field 'flags' of struct rte_ring is defined as int type. However,
> it is used as unsigned int. To ensure consistency, change the
> type of flags to unsigned int. Since these two types has the
> same byte size, this change is not an ABI change.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
> lib/ring/rte_ring_core.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/ring/rte_ring_core.h b/lib/ring/rte_ring_core.h
> index b7708730658a..14dac6495d83 100644
> --- a/lib/ring/rte_ring_core.h
> +++ b/lib/ring/rte_ring_core.h
> @@ -119,7 +119,7 @@ struct rte_ring_hts_headtail {
> struct rte_ring {
> char name[RTE_RING_NAMESIZE] __rte_cache_aligned;
> /**< Name of the ring. */
> - int flags; /**< Flags supplied at creation. */
> + uint32_t flags; /**< Flags supplied at creation. */
> const struct rte_memzone *memzone;
> /**< Memzone, if any, containing the rte_ring */
> uint32_t size; /**< Size of ring. */
^ permalink raw reply [relevance 0%]
* Re: [PATCH v7 00/25] Promote 22.11 and older API's to stable
2023-10-24 2:53 3% ` [PATCH v7 00/25] Promote 22.11 and older " Stephen Hemminger
2023-10-24 2:54 2% ` [PATCH v7 22/25] compressdev: remove experimental flag Stephen Hemminger
@ 2023-11-13 15:45 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2023-11-13 15:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Oct 24, 2023 at 4:54 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Since 23.11 is an LTS release it is time to remove the experimental
> bandaid off many API's. There are about 890 API's marked with experimental
> on current main branch. This addresses the easy to remove ones and
> gets it down to about 510 places.
>
> The rule is any API that has been in since 22.11 needs to have
> experimental removed (or have API deleted). The experimental flag is not a
> "get out of ABI stability for free" card
There is no such rule.
And I think some libraries do keep the experimental tag for good reasons.
The topic of such a rule is to be discussed in a later techboard meeting.
In any case, there is enough acks on this series.
I fixed the lib/node patch, sorted version.map files content and
removed inclusion of rte_compat as I had requested in a previous
revision.
Series applied thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [PATCH v5 1/2] devtools: add check on symbol maps format
@ 2023-11-15 10:42 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-11-15 10:42 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon
Add a check on symbol maps format.
This will be required by a next commit.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v4:
- rebased,
- handled next abi version in the check,
Changes since v3:
- fixed Alpine build (same issue with { in awk expression than commit
e1ab26df4862 ("buildtools: fix build with busybox")),
Changes since v2:
- fixed FreeBSD build by replacing (|pattern) with (pattern)?,
Changes since v1:
- moved this check in a separate patch,
- fixed ethdev map file,
---
devtools/check-symbol-maps.sh | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 8c116bfa9c..ba2f892f56 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -74,4 +74,27 @@ if [ -n "$empty_maps" ] ; then
ret=1
fi
+find_bad_format_maps ()
+{
+ abi_version=$(cut -d'.' -f 1 ABI_VERSION)
+ next_abi_version=$((abi_version + 1))
+ for map in $@ ; do
+ cat $map | awk '
+ /^(DPDK_('$abi_version'|'$next_abi_version')|EXPERIMENTAL|INTERNAL) \{$/ { next; } # start of a section
+ /^}( DPDK_'$abi_version')?;$/ { next; } # end of a section
+ /^$/ { next; } # empty line
+ /^\t(global:|local: \*;)$/ { next; } # qualifiers
+ /^\t[a-zA-Z_0-9]*;( # WINDOWS_NO_EXPORT)?$/ { next; } # symbols
+ /^\t# added in [0-9]*\.[0-9]*$/ { next; } # version comments
+ { print $0; }' || echo $map
+ done
+}
+
+bad_format_maps=$(find_bad_format_maps $@)
+if [ -n "$bad_format_maps" ] ; then
+ echo "Found badly formatted maps:"
+ echo "$bad_format_maps"
+ ret=1
+fi
+
exit $ret
--
2.41.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH] eal: use C11 alignas instead of GCC attribute aligned
@ 2023-11-15 20:08 3% ` Morten Brørup
2023-11-15 21:03 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-11-15 20:08 UTC (permalink / raw)
To: Tyler Retzlaff, dev, Stanislaw Kardach
Cc: Mattias Rönnblom, Anatoly Burakov, Bruce Richardson,
David Christensen, Harry van Haaren, Konstantin Ananyev,
Min Zhou, Ruifeng Wang
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 15 November 2023 18.40
>
> Now that we have enabled C11 replace the use of __rte_cache_aligned
> and __rte_aligned(n) with alignas(RTE_CACHE_LINE_SIZE) and
> __rte_aligned(n) respectively.
>
[...]
> typedef union rte_xmm {
> + alignas(16)
> xmm_t x;
> uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> double pd[XMM_SIZE / sizeof(double)];
> -} __rte_aligned(16) rte_xmm_t;
> +} rte_xmm_t;
Your patch message should mention that C11 doesn't allow alignas() being applied to the declarations of struct/union types, so it is applied to the first field in the struct/union, which has the same effect.
Someone unfamiliar with alignas() would expect:
-typedef union rte_xmm {
+typedef alignas(16) union rte_xmm {
[...]
-} __rte_aligned(16) rte_xmm_t;
+} rte_xmm_t;
[...]
> #ifndef RTE_VECT_RISCV_H
> #define RTE_VECT_RISCV_H
>
> +#include <stdalign.h>
> #include <stdint.h>
> #include "generic/rte_vect.h"
> #include "rte_common.h"
> @@ -23,13 +24,14 @@
> #define XMM_MASK (XMM_SIZE - 1)
>
> typedef union rte_xmm {
> + alignas(16) /* !! NOTE !! changed to 16 it looks like this was a
> bug? */
> xmm_t x;
> uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> double pd[XMM_SIZE / sizeof(double)];
> -} __rte_aligned(8) rte_xmm_t;
> +} rte_xmm_t;
Yes, this looks very much like a bug.
Even if a RISC-V CPU could handle alignment like that, it might interact with other software/hardware expecting type-sized alignment, i.e. 16-byte alignment, so partially using 8-byte alignment would cause bugs.
It should be a separate patch with a Fixes tag.
We need to urgently decide if this bug should live on in DPDK 23.11, or if the fix should be included although we are very late in the release process.
Stanislaw, what do you think?
Furthermore, I wonder if it can be backported to stable, and to what extent backporting it would break the ABI/API.
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal: use C11 alignas instead of GCC attribute aligned
2023-11-15 20:08 3% ` Morten Brørup
@ 2023-11-15 21:03 0% ` Tyler Retzlaff
2023-11-15 22:43 0% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-11-15 21:03 UTC (permalink / raw)
To: Morten Brørup
Cc: dev, Stanislaw Kardach, Mattias Rönnblom, Anatoly Burakov,
Bruce Richardson, David Christensen, Harry van Haaren,
Konstantin Ananyev, Min Zhou, Ruifeng Wang
On Wed, Nov 15, 2023 at 09:08:05PM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Wednesday, 15 November 2023 18.40
> >
> > Now that we have enabled C11 replace the use of __rte_cache_aligned
> > and __rte_aligned(n) with alignas(RTE_CACHE_LINE_SIZE) and
> > __rte_aligned(n) respectively.
> >
>
> [...]
>
> > typedef union rte_xmm {
> > + alignas(16)
> > xmm_t x;
> > uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> > uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> > uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> > uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> > double pd[XMM_SIZE / sizeof(double)];
> > -} __rte_aligned(16) rte_xmm_t;
> > +} rte_xmm_t;
>
> Your patch message should mention that C11 doesn't allow alignas() being applied to the declarations of struct/union types, so it is applied to the first field in the struct/union, which has the same effect.
no problem, will add a note.
>
> Someone unfamiliar with alignas() would expect:
>
> -typedef union rte_xmm {
> +typedef alignas(16) union rte_xmm {
> [...]
> -} __rte_aligned(16) rte_xmm_t;
> +} rte_xmm_t;
>
> [...]
>
> > #ifndef RTE_VECT_RISCV_H
> > #define RTE_VECT_RISCV_H
> >
> > +#include <stdalign.h>
> > #include <stdint.h>
> > #include "generic/rte_vect.h"
> > #include "rte_common.h"
> > @@ -23,13 +24,14 @@
> > #define XMM_MASK (XMM_SIZE - 1)
> >
> > typedef union rte_xmm {
> > + alignas(16) /* !! NOTE !! changed to 16 it looks like this was a
> > bug? */
> > xmm_t x;
> > uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> > uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> > uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> > uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> > double pd[XMM_SIZE / sizeof(double)];
> > -} __rte_aligned(8) rte_xmm_t;
> > +} rte_xmm_t;
>
> Yes, this looks very much like a bug.
> Even if a RISC-V CPU could handle alignment like that, it might interact with other software/hardware expecting type-sized alignment, i.e. 16-byte alignment, so partially using 8-byte alignment would cause bugs.
>
> It should be a separate patch with a Fixes tag.
i'll submit a patch/fix for this so it is available and others can
discuss if it should or shouldn't be merged for 23.11.
>
> We need to urgently decide if this bug should live on in DPDK 23.11, or if the fix should be included although we are very late in the release process.
>
> Stanislaw, what do you think?
>
> Furthermore, I wonder if it can be backported to stable, and to what extent backporting it would break the ABI/API.
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] eal: fix alignment of RISCV xmm vector type
@ 2023-11-15 21:31 3% ` Morten Brørup
2023-11-15 23:20 0% ` Stanisław Kardach
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-11-15 21:31 UTC (permalink / raw)
To: Tyler Retzlaff, dev, Stanislaw Kardach; +Cc: Michal Mazurek, stable
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 15 November 2023 22.17
>
> Fix the alignment for rte_xmm_t it should be 16 instead of 8 bytes.
>
> Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> Cc: maz@semihalf.com
> Cc: stable@dpdk.org
> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> ---
Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
As mentioned in the other thread:
We need to urgently decide if this bug should live on in DPDK 23.11, or if the fix should be included although we are very late in the release process.
Stanislaw, what do you think?
Furthermore, I wonder if it can be backported to stable, and to what extent backporting it would break the ABI/API.
^ permalink raw reply [relevance 3%]
* Re: [PATCH] eal: use C11 alignas instead of GCC attribute aligned
2023-11-15 21:03 0% ` Tyler Retzlaff
@ 2023-11-15 22:43 0% ` Stanisław Kardach
0 siblings, 0 replies; 200+ results
From: Stanisław Kardach @ 2023-11-15 22:43 UTC (permalink / raw)
To: Tyler Retzlaff
Cc: Morten Brørup, dev, Mattias Rönnblom, Anatoly Burakov,
Bruce Richardson, David Christensen, Harry van Haaren,
Konstantin Ananyev, Min Zhou, Ruifeng Wang
On Wed, Nov 15, 2023 at 10:03 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> On Wed, Nov 15, 2023 at 09:08:05PM +0100, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Wednesday, 15 November 2023 18.40
> > >
> > > Now that we have enabled C11 replace the use of __rte_cache_aligned
> > > and __rte_aligned(n) with alignas(RTE_CACHE_LINE_SIZE) and
> > > __rte_aligned(n) respectively.
> > >
> >
> > [...]
> >
> > > typedef union rte_xmm {
> > > + alignas(16)
> > > xmm_t x;
> > > uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> > > uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> > > uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> > > uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> > > double pd[XMM_SIZE / sizeof(double)];
> > > -} __rte_aligned(16) rte_xmm_t;
> > > +} rte_xmm_t;
> >
> > Your patch message should mention that C11 doesn't allow alignas() being applied to the declarations of struct/union types, so it is applied to the first field in the struct/union, which has the same effect.
>
> no problem, will add a note.
>
> >
> > Someone unfamiliar with alignas() would expect:
> >
> > -typedef union rte_xmm {
> > +typedef alignas(16) union rte_xmm {
> > [...]
> > -} __rte_aligned(16) rte_xmm_t;
> > +} rte_xmm_t;
> >
> > [...]
> >
> > > #ifndef RTE_VECT_RISCV_H
> > > #define RTE_VECT_RISCV_H
> > >
> > > +#include <stdalign.h>
> > > #include <stdint.h>
> > > #include "generic/rte_vect.h"
> > > #include "rte_common.h"
> > > @@ -23,13 +24,14 @@
> > > #define XMM_MASK (XMM_SIZE - 1)
> > >
> > > typedef union rte_xmm {
> > > + alignas(16) /* !! NOTE !! changed to 16 it looks like this was a
> > > bug? */
> > > xmm_t x;
> > > uint8_t u8[XMM_SIZE / sizeof(uint8_t)];
> > > uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> > > uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> > > uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> > > double pd[XMM_SIZE / sizeof(double)];
> > > -} __rte_aligned(8) rte_xmm_t;
> > > +} rte_xmm_t;
> >
> > Yes, this looks very much like a bug.
> > Even if a RISC-V CPU could handle alignment like that, it might interact with other software/hardware expecting type-sized alignment, i.e. 16-byte alignment, so partially using 8-byte alignment would cause bugs.
> >
> > It should be a separate patch with a Fixes tag.
>
> i'll submit a patch/fix for this so it is available and others can
> discuss if it should or shouldn't be merged for 23.11.
It is definitely a bug. Good catch. Since we did not have vector
extensions on our bring-up board, all xmm_t handling was essentially
scalar.
>
> >
> > We need to urgently decide if this bug should live on in DPDK 23.11, or if the fix should be included although we are very late in the release process.
> >
> > Stanislaw, what do you think?
> >
> > Furthermore, I wonder if it can be backported to stable, and to what extent backporting it would break the ABI/API.
> >
--
Best Regards,
Stanisław Kardach
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal: fix alignment of RISCV xmm vector type
2023-11-15 21:31 3% ` Morten Brørup
@ 2023-11-15 23:20 0% ` Stanisław Kardach
2023-11-16 7:45 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Stanisław Kardach @ 2023-11-15 23:20 UTC (permalink / raw)
To: Morten Brørup; +Cc: Tyler Retzlaff, dev, Michal Mazurek, stable
On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Wednesday, 15 November 2023 22.17
> >
> > Fix the alignment for rte_xmm_t it should be 16 instead of 8 bytes.
> >
> > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> > Cc: maz@semihalf.com
> > Cc: stable@dpdk.org
> > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > ---
>
> Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
>
> As mentioned in the other thread:
>
> We need to urgently decide if this bug should live on in DPDK 23.11, or if the fix should be included although we are very late in the release process.
>
> Stanislaw, what do you think?
Good catch! As for backporting I'm not sure of the urgency given that
our examples still use scalar instructions for handling xmm_t. The
question is whether there is a platform in use which has vector
extensions enabled and that utilizes DPDK. I'm not that sure of it
though I'd be happy to be proven wrong.
Reviewed-by: Stanislaw Kardach <kda@semihalf.com>
>
> Furthermore, I wonder if it can be backported to stable, and to what extent backporting it would break the ABI/API.
>
--
Best Regards,
Stanisław Kardach
^ permalink raw reply [relevance 0%]
* RE: [PATCH] eal: fix alignment of RISCV xmm vector type
2023-11-15 23:20 0% ` Stanisław Kardach
@ 2023-11-16 7:45 3% ` Morten Brørup
2023-11-17 10:54 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-11-16 7:45 UTC (permalink / raw)
To: Stanisław Kardach, bruce.richardson
Cc: Tyler Retzlaff, dev, Michal Mazurek, stable
> From: Stanisław Kardach [mailto:kda@semihalf.com]
> Sent: Thursday, 16 November 2023 00.21
>
> On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup
> <mb@smartsharesystems.com> wrote:
> >
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Wednesday, 15 November 2023 22.17
> > >
> > > Fix the alignment for rte_xmm_t it should be 16 instead of 8 bytes.
> > >
> > > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> > > Cc: maz@semihalf.com
> > > Cc: stable@dpdk.org
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> >
> > Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> >
> > As mentioned in the other thread:
> >
> > We need to urgently decide if this bug should live on in DPDK 23.11,
> or if the fix should be included although we are very late in the
> release process.
> >
> > Stanislaw, what do you think?
> Good catch! As for backporting I'm not sure of the urgency given that
> our examples still use scalar instructions for handling xmm_t. The
> question is whether there is a platform in use which has vector
> extensions enabled and that utilizes DPDK. I'm not that sure of it
> though I'd be happy to be proven wrong.
Can we extrapolate this, and also conclude that postponing this bugfix until the next ABI/API breaking release, DPDK 24.11, is not really going to hurt anyone?
Stanislaw, please confirm?
Bruce, I don't feel 100 % confident in making this postponement recommendation. Could you please provide a second opinion regarding the timing of fixing this bug? Or rather: do you have any strong arguments *against* postponing it to DPDK 24.11?
>
> Reviewed-by: Stanislaw Kardach <kda@semihalf.com>
>
> >
> > Furthermore, I wonder if it can be backported to stable, and to what
> extent backporting it would break the ABI/API.
Based on your input regarding the current deployment status, backporting the bugfix clearly isn't worth the effort. Excellent!
> >
>
>
> --
> Best Regards,
> Stanisław Kardach
^ permalink raw reply [relevance 3%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
@ 2023-11-17 0:50 3% ` Ferruh Yigit
2023-11-17 3:28 0% ` Stephen Hemminger
2023-11-20 9:21 0% ` Deng, KaiwenX
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2023-11-17 0:50 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Kaiwen Deng, dev, stable, qiming.yang, yidingx.zhou, Aman Singh,
Yuying Zhang, Olivier Matz, Pablo de Lara
On 11/16/2023 10:58 PM, Stephen Hemminger wrote:
> On Thu, 2 Nov 2023 19:20:07 +0000
> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
>> On 8/4/2023 9:28 AM, Kaiwen Deng wrote:
>>> IEEE 802 packets may have a minimum size limit. The data fields
>>> should be padded when necessary. In some cases, the padding data
>>> is not zero. Testpmd does not trim these IP packets to the true
>>> length of the frame, so errors will occur when calculating TCP
>>> or UDP checksum.
>>>
>>
>> Hi Kaiwen,
>>
>> I am trying to understand the problem, what is the testcase that has
>> checksum error?
>>
>> Are the received mbuf data_len & pkt_len wrong? Instead of trying to fix
>> the mbuf during forwarding, can we fix where packet generated?
>
> The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len
> which maybe larger than the actual data. The real issue is there and
> in rte_ip.h checksum code. The correct fix would be to use l3_len instead.
>
I see, you are right.
In 'rte_ipv4_udptcp_cksum_mbuf()',
as payload length "mbuf->pkt_len - l4_off" is used, which includes
padding and if padding is not zero it will end up producing wrong checksum.
I agree using 'l3_len' instead is correct fix.
But this requires ABI/API change,
plus do we have any reason to keep the padding, discarding it as this
patch does is also simpler alternative.
Other alternative can be to zero the padding bytes. I guess standard
doesn't enforce them to be zero, but we can do this to remove its impact
on checksum calculation.
@Kaiwen, did you able to test this with HW offload, what is the behavior
of the HW, does is remove padding bytes?
> It also looks like test-pmd is not validating the IP header.
> Both parse_ipv4() and parse_ipv6() should check if packet was truncated.
> Same for both UDP and TCP lengths.
>
^ permalink raw reply [relevance 3%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 0:50 3% ` Ferruh Yigit
@ 2023-11-17 3:28 0% ` Stephen Hemminger
2023-11-17 9:29 0% ` Ferruh Yigit
2023-11-20 9:21 0% ` Deng, KaiwenX
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-11-17 3:28 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Kaiwen Deng, dev, stable, qiming.yang, yidingx.zhou, Aman Singh,
Yuying Zhang, Olivier Matz, Pablo de Lara
On Fri, 17 Nov 2023 00:50:16 +0000
Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >> Hi Kaiwen,
> >>
> >> I am trying to understand the problem, what is the testcase that has
> >> checksum error?
> >>
> >> Are the received mbuf data_len & pkt_len wrong? Instead of trying to fix
> >> the mbuf during forwarding, can we fix where packet generated?
> >
> > The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len
> > which maybe larger than the actual data. The real issue is there and
> > in rte_ip.h checksum code. The correct fix would be to use l3_len instead.
> >
>
> I see, you are right.
>
> In 'rte_ipv4_udptcp_cksum_mbuf()',
> as payload length "mbuf->pkt_len - l4_off" is used, which includes
> padding and if padding is not zero it will end up producing wrong checksum.
>
>
> I agree using 'l3_len' instead is correct fix.
>
> But this requires ABI/API change,
> plus do we have any reason to keep the padding, discarding it as this
> patch does is also simpler alternative.
Possibly an API version to change the args would work to fix.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 3:28 0% ` Stephen Hemminger
@ 2023-11-17 9:29 0% ` Ferruh Yigit
2023-11-17 12:11 0% ` Morten Brørup
2023-11-17 16:22 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2023-11-17 9:29 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Kaiwen Deng, dev, stable, qiming.yang, yidingx.zhou, Aman Singh,
Yuying Zhang, Olivier Matz, Pablo de Lara
On 11/17/2023 3:28 AM, Stephen Hemminger wrote:
> On Fri, 17 Nov 2023 00:50:16 +0000
> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
>>>> Hi Kaiwen,
>>>>
>>>> I am trying to understand the problem, what is the testcase that has
>>>> checksum error?
>>>>
>>>> Are the received mbuf data_len & pkt_len wrong? Instead of trying to fix
>>>> the mbuf during forwarding, can we fix where packet generated?
>>>
>>> The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len
>>> which maybe larger than the actual data. The real issue is there and
>>> in rte_ip.h checksum code. The correct fix would be to use l3_len instead.
>>>
>>
>> I see, you are right.
>>
>> In 'rte_ipv4_udptcp_cksum_mbuf()',
>> as payload length "mbuf->pkt_len - l4_off" is used, which includes
>> padding and if padding is not zero it will end up producing wrong checksum.
>>
>>
>> I agree using 'l3_len' instead is correct fix.
>>
>> But this requires ABI/API change,
>> plus do we have any reason to keep the padding, discarding it as this
>> patch does is also simpler alternative.
>
>
> Possibly an API version to change the args would work to fix.
>
rte_ipv4_udptcp_cksum_mbuf() and rte_ipv6_udptcp_cksum_mbuf() are inline
functions, unfortunately we can't version them.
But those functions already gets IP header as parameter, can't we use IP
header to get the payload size? If so this can be fixed without updating
API.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal: fix alignment of RISCV xmm vector type
2023-11-16 7:45 3% ` Morten Brørup
@ 2023-11-17 10:54 3% ` Bruce Richardson
2023-11-17 11:18 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-11-17 10:54 UTC (permalink / raw)
To: Morten Brørup
Cc: Stanisław Kardach, Tyler Retzlaff, dev, Michal Mazurek, stable
On Thu, Nov 16, 2023 at 08:45:35AM +0100, Morten Brørup wrote:
> > From: Stanisław Kardach [mailto:kda@semihalf.com]
> > Sent: Thursday, 16 November 2023 00.21
> >
> > On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup
> > <mb@smartsharesystems.com> wrote:
> > >
> > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > Sent: Wednesday, 15 November 2023 22.17
> > > >
> > > > Fix the alignment for rte_xmm_t it should be 16 instead of 8 bytes.
> > > >
> > > > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> > > > Cc: maz@semihalf.com
> > > > Cc: stable@dpdk.org
> > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > ---
> > >
> > > Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> > >
> > > As mentioned in the other thread:
> > >
> > > We need to urgently decide if this bug should live on in DPDK 23.11,
> > or if the fix should be included although we are very late in the
> > release process.
> > >
> > > Stanislaw, what do you think?
> > Good catch! As for backporting I'm not sure of the urgency given that
> > our examples still use scalar instructions for handling xmm_t. The
> > question is whether there is a platform in use which has vector
> > extensions enabled and that utilizes DPDK. I'm not that sure of it
> > though I'd be happy to be proven wrong.
>
> Can we extrapolate this, and also conclude that postponing this bugfix until the next ABI/API breaking release, DPDK 24.11, is not really going to hurt anyone?
>
> Stanislaw, please confirm?
>
> Bruce, I don't feel 100 % confident in making this postponement recommendation. Could you please provide a second opinion regarding the timing of fixing this bug? Or rather: do you have any strong arguments *against* postponing it to DPDK 24.11?
>
Not sure I'm any better placed to make an argument either way! However, I
would very much tend to say that we should include this in 23.11, on the
basis that if it turns out to be important we can't backport it later
without affecting ABI. Right now, the code looks broken to me, and I'm also
struggling to find circumstances where increasing the alignment will
actually stop something from working. There could well be performance
implications of having extra padding, but things should still work, AFAIK.
On the other hand, if we don't include the fix, it is possible that a
system (possibly a future one) could break and segfault due to incorrect
vector code. I'd take a possible slowdown over a segfault!
Is my assessment correct, or perhaps I'm missing some detail.
/Bruce
^ permalink raw reply [relevance 3%]
* RE: [PATCH] eal: fix alignment of RISCV xmm vector type
2023-11-17 10:54 3% ` Bruce Richardson
@ 2023-11-17 11:18 0% ` Morten Brørup
2023-11-18 8:04 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-11-17 11:18 UTC (permalink / raw)
To: Bruce Richardson, Stanisław Kardach
Cc: Tyler Retzlaff, dev, Michal Mazurek, stable, thomas
+CC Thomas, this patch is ready to be applied to 23.11.
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 17 November 2023 11.55
>
> On Thu, Nov 16, 2023 at 08:45:35AM +0100, Morten Brørup wrote:
> > > From: Stanisław Kardach [mailto:kda@semihalf.com]
> > > Sent: Thursday, 16 November 2023 00.21
> > >
> > > On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup
> > > <mb@smartsharesystems.com> wrote:
> > > >
> > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > > Sent: Wednesday, 15 November 2023 22.17
> > > > >
> > > > > Fix the alignment for rte_xmm_t it should be 16 instead of 8
> bytes.
> > > > >
> > > > > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> > > > > Cc: maz@semihalf.com
> > > > > Cc: stable@dpdk.org
> > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > ---
> > > >
> > > > Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> > > >
> > > > As mentioned in the other thread:
> > > >
> > > > We need to urgently decide if this bug should live on in DPDK
> 23.11,
> > > or if the fix should be included although we are very late in the
> > > release process.
> > > >
> > > > Stanislaw, what do you think?
> > > Good catch! As for backporting I'm not sure of the urgency given
> that
> > > our examples still use scalar instructions for handling xmm_t. The
> > > question is whether there is a platform in use which has vector
> > > extensions enabled and that utilizes DPDK. I'm not that sure of it
> > > though I'd be happy to be proven wrong.
> >
> > Can we extrapolate this, and also conclude that postponing this
> bugfix until the next ABI/API breaking release, DPDK 24.11, is not
> really going to hurt anyone?
> >
> > Stanislaw, please confirm?
> >
> > Bruce, I don't feel 100 % confident in making this postponement
> recommendation. Could you please provide a second opinion regarding the
> timing of fixing this bug? Or rather: do you have any strong arguments
> *against* postponing it to DPDK 24.11?
> >
>
> Not sure I'm any better placed to make an argument either way!
Bruce, I picked you because of your experience with vector code.
> However, I
> would very much tend to say that we should include this in 23.11, on
> the
> basis that if it turns out to be important we can't backport it later
> without affecting ABI. Right now, the code looks broken to me, and I'm
> also
> struggling to find circumstances where increasing the alignment will
> actually stop something from working. There could well be performance
> implications of having extra padding, but things should still work,
> AFAIK.
> On the other hand, if we don't include the fix, it is possible that a
> system (possibly a future one) could break and segfault due to
> incorrect
> vector code. I'd take a possible slowdown over a segfault!
The risk of slowdown isn't a factor for me at this stage.
I'm trying to balance the risk of fixing the bug vs. breaking something this late in the 23.11 release cycle.
You have a strong point that we also need to consider the bugfix in the context of the total lifetime of DPDK 23.11 in the wild.
With RISC-V's current traction, that certainly speaks in favor of including it in 23.11.
>
> Is my assessment correct, or perhaps I'm missing some detail.
Thank you for your valuable feedback, Bruce.
I was just being overly cautious... After all, 23.11 is still at a stage where bug fixes are accepted!
New conclusion: Let's get it into 23.11.
^ permalink raw reply [relevance 0%]
* RE: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 9:29 0% ` Ferruh Yigit
@ 2023-11-17 12:11 0% ` Morten Brørup
2023-11-17 16:22 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2023-11-17 12:11 UTC (permalink / raw)
To: Ferruh Yigit, Stephen Hemminger, Kaiwen Deng
Cc: dev, stable, qiming.yang, yidingx.zhou, Aman Singh, Yuying Zhang,
Olivier Matz, Pablo de Lara
> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com]
> Sent: Friday, 17 November 2023 10.30
>
> On 11/17/2023 3:28 AM, Stephen Hemminger wrote:
> > On Fri, 17 Nov 2023 00:50:16 +0000
> > Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >
> >>>> Hi Kaiwen,
> >>>>
> >>>> I am trying to understand the problem, what is the testcase that
> has
> >>>> checksum error?
> >>>>
> >>>> Are the received mbuf data_len & pkt_len wrong? Instead of trying
> to fix
> >>>> the mbuf during forwarding, can we fix where packet generated?
> >>>
> >>> The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len
> >>> which maybe larger than the actual data. The real issue is there
> and
> >>> in rte_ip.h checksum code. The correct fix would be to use l3_len
> instead.
> >>>
> >>
> >> I see, you are right.
> >>
> >> In 'rte_ipv4_udptcp_cksum_mbuf()',
> >> as payload length "mbuf->pkt_len - l4_off" is used, which includes
> >> padding and if padding is not zero it will end up producing wrong
> checksum.
> >>
> >>
> >> I agree using 'l3_len' instead is correct fix.
> >>
> >> But this requires ABI/API change,
> >> plus do we have any reason to keep the padding, discarding it as
> this
> >> patch does is also simpler alternative.
> >
> >
> > Possibly an API version to change the args would work to fix.
> >
>
> rte_ipv4_udptcp_cksum_mbuf() and rte_ipv6_udptcp_cksum_mbuf() are
> inline
> functions, unfortunately we can't version them.
>
> But those functions already gets IP header as parameter, can't we use
> IP
> header to get the payload size? If so this can be fixed without
> updating
> API.
If rte_ipv4_udptcp_cksum_mbuf() - or any other function in the DPDK Network Headers library - includes Ethernet padding (which may be non-zero) when calculating the TCP/UDP checksum of an IPv4 packet, it is a bug, and must be fixed there.
Our test cases should use random padding to catch bugs like this.
And I just realized that Ethernet padding may be added to any IP packet, so don't assume that this bug only applies to small packets.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 9:29 0% ` Ferruh Yigit
2023-11-17 12:11 0% ` Morten Brørup
@ 2023-11-17 16:22 0% ` Stephen Hemminger
2023-11-20 10:47 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-11-17 16:22 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Kaiwen Deng, dev, stable, qiming.yang, yidingx.zhou, Aman Singh,
Yuying Zhang, Olivier Matz, Pablo de Lara
On Fri, 17 Nov 2023 09:29:41 +0000
Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >> I agree using 'l3_len' instead is correct fix.
> >>
> >> But this requires ABI/API change,
> >> plus do we have any reason to keep the padding, discarding it as this
> >> patch does is also simpler alternative.
> >
> >
> > Possibly an API version to change the args would work to fix.
> >
>
> rte_ipv4_udptcp_cksum_mbuf() and rte_ipv6_udptcp_cksum_mbuf() are inline
> functions, unfortunately we can't version them.
>
> But those functions already gets IP header as parameter, can't we use IP
> header to get the payload size? If so this can be fixed without updating
> API.
Inlines are easier. Just make a fixed new function and make sure the old
one is not used. They shouldn't have been inline in the first place.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal: fix alignment of RISCV xmm vector type
2023-11-17 11:18 0% ` Morten Brørup
@ 2023-11-18 8:04 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-11-18 8:04 UTC (permalink / raw)
To: Bruce Richardson, Stanisław Kardach, Tyler Retzlaff,
Morten Brørup
Cc: dev, Michal Mazurek, stable
17/11/2023 12:18, Morten Brørup:
> +CC Thomas, this patch is ready to be applied to 23.11.
>
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 17 November 2023 11.55
> >
> > On Thu, Nov 16, 2023 at 08:45:35AM +0100, Morten Brørup wrote:
> > > > From: Stanisław Kardach [mailto:kda@semihalf.com]
> > > > Sent: Thursday, 16 November 2023 00.21
> > > >
> > > > On Wed, Nov 15, 2023 at 10:31 PM Morten Brørup
> > > > <mb@smartsharesystems.com> wrote:
> > > > >
> > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > > > Sent: Wednesday, 15 November 2023 22.17
> > > > > >
> > > > > > Fix the alignment for rte_xmm_t it should be 16 instead of 8
> > bytes.
> > > > > >
> > > > > > Fixes: f22e705ebf12 ("eal/riscv: support RISC-V architecture")
> > > > > > Cc: maz@semihalf.com
> > > > > > Cc: stable@dpdk.org
> > > > > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > > > > ---
> > > > >
> > > > > Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> > > > >
> > > > > As mentioned in the other thread:
> > > > >
> > > > > We need to urgently decide if this bug should live on in DPDK
> > 23.11,
> > > > or if the fix should be included although we are very late in the
> > > > release process.
> > > > >
> > > > > Stanislaw, what do you think?
> > > > Good catch! As for backporting I'm not sure of the urgency given
> > that
> > > > our examples still use scalar instructions for handling xmm_t. The
> > > > question is whether there is a platform in use which has vector
> > > > extensions enabled and that utilizes DPDK. I'm not that sure of it
> > > > though I'd be happy to be proven wrong.
> > >
> > > Can we extrapolate this, and also conclude that postponing this
> > bugfix until the next ABI/API breaking release, DPDK 24.11, is not
> > really going to hurt anyone?
> > >
> > > Stanislaw, please confirm?
> > >
> > > Bruce, I don't feel 100 % confident in making this postponement
> > recommendation. Could you please provide a second opinion regarding the
> > timing of fixing this bug? Or rather: do you have any strong arguments
> > *against* postponing it to DPDK 24.11?
> > >
> >
> > Not sure I'm any better placed to make an argument either way!
>
> Bruce, I picked you because of your experience with vector code.
>
> > However, I
> > would very much tend to say that we should include this in 23.11, on
> > the
> > basis that if it turns out to be important we can't backport it later
> > without affecting ABI. Right now, the code looks broken to me, and I'm
> > also
> > struggling to find circumstances where increasing the alignment will
> > actually stop something from working. There could well be performance
> > implications of having extra padding, but things should still work,
> > AFAIK.
> > On the other hand, if we don't include the fix, it is possible that a
> > system (possibly a future one) could break and segfault due to
> > incorrect
> > vector code. I'd take a possible slowdown over a segfault!
>
> The risk of slowdown isn't a factor for me at this stage.
>
> I'm trying to balance the risk of fixing the bug vs. breaking something this late in the 23.11 release cycle.
>
> You have a strong point that we also need to consider the bugfix in the context of the total lifetime of DPDK 23.11 in the wild.
> With RISC-V's current traction, that certainly speaks in favor of including it in 23.11.
>
> >
> > Is my assessment correct, or perhaps I'm missing some detail.
>
> Thank you for your valuable feedback, Bruce.
>
> I was just being overly cautious... After all, 23.11 is still at a stage where bug fixes are accepted!
>
> New conclusion: Let's get it into 23.11.
Applied, thanks.
I've kept CC:stable as it is a real fix.
I don't see a problem in breaking API/ABI for RISC-V which is quite new.
Anyway stable maintainers will choose what to do.
^ permalink raw reply [relevance 3%]
* RE: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 0:50 3% ` Ferruh Yigit
2023-11-17 3:28 0% ` Stephen Hemminger
@ 2023-11-20 9:21 0% ` Deng, KaiwenX
2023-11-20 10:46 3% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Deng, KaiwenX @ 2023-11-20 9:21 UTC (permalink / raw)
To: Ferruh Yigit, Stephen Hemminger
Cc: dev, stable, Yang, Qiming, Zhou, YidingX, Singh, Aman Deep,
Zhang, Yuying, Matz, Olivier, De Lara Guarch, Pablo
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Friday, November 17, 2023 8:50 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Deng, KaiwenX <kaiwenx.deng@intel.com>; dev@dpdk.org;
> stable@dpdk.org; Yang, Qiming <qiming.yang@intel.com>; Zhou, YidingX
> <yidingx.zhou@intel.com>; Singh, Aman Deep <aman.deep.singh@intel.com>;
> Zhang, Yuying <yuying.zhang@intel.com>; Matz, Olivier
> <olivier.matz@6wind.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
>
> On 11/16/2023 10:58 PM, Stephen Hemminger wrote:
> > On Thu, 2 Nov 2023 19:20:07 +0000
> > Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >
> >> On 8/4/2023 9:28 AM, Kaiwen Deng wrote:
> >>> IEEE 802 packets may have a minimum size limit. The data fields
> >>> should be padded when necessary. In some cases, the padding data is
> >>> not zero. Testpmd does not trim these IP packets to the true length
> >>> of the frame, so errors will occur when calculating TCP or UDP
> >>> checksum.
> >>>
> >>
> >> Hi Kaiwen,
> >>
> >> I am trying to understand the problem, what is the testcase that has
> >> checksum error?
> >>
> >> Are the received mbuf data_len & pkt_len wrong? Instead of trying to
> >> fix the mbuf during forwarding, can we fix where packet generated?
> >
> > The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len which
> > maybe larger than the actual data. The real issue is there and in
> > rte_ip.h checksum code. The correct fix would be to use l3_len instead.
> >
>
> I see, you are right.
>
> In 'rte_ipv4_udptcp_cksum_mbuf()',
> as payload length "mbuf->pkt_len - l4_off" is used, which includes padding
> and if padding is not zero it will end up producing wrong checksum.
>
>
> I agree using 'l3_len' instead is correct fix.
>
> But this requires ABI/API change,
> plus do we have any reason to keep the padding, discarding it as this patch
> does is also simpler alternative.
>
>
> Other alternative can be to zero the padding bytes. I guess standard doesn't
> enforce them to be zero, but we can do this to remove its impact on checksum
> calculation.
I'm not sure if this is ok, it feels like it would reduce performance.
I can try this alternative if needed.
>
>
> @Kaiwen, did you able to test this with HW offload, what is the behavior of
> the HW, does is remove padding bytes?
>
I tested the HW offload case and the same tcp/udp checksum error occurs when padding is not 0,
But if change pkt_len to the true length of the frame, the checksum is correct.
>
> > It also looks like test-pmd is not validating the IP header.
> > Both parse_ipv4() and parse_ipv6() should check if packet was truncated.
> > Same for both UDP and TCP lengths.
> >
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-20 9:21 0% ` Deng, KaiwenX
@ 2023-11-20 10:46 3% ` Ferruh Yigit
2023-11-22 3:04 0% ` Deng, KaiwenX
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-11-20 10:46 UTC (permalink / raw)
To: Deng, KaiwenX, Stephen Hemminger, Morten Brørup
Cc: dev, stable, Yang, Qiming, Zhou, YidingX, Singh, Aman Deep,
Zhang, Yuying, Matz, Olivier, De Lara Guarch, Pablo
On 11/20/2023 9:21 AM, Deng, KaiwenX wrote:
>
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>> Sent: Friday, November 17, 2023 8:50 AM
>> To: Stephen Hemminger <stephen@networkplumber.org>
>> Cc: Deng, KaiwenX <kaiwenx.deng@intel.com>; dev@dpdk.org;
>> stable@dpdk.org; Yang, Qiming <qiming.yang@intel.com>; Zhou, YidingX
>> <yidingx.zhou@intel.com>; Singh, Aman Deep <aman.deep.singh@intel.com>;
>> Zhang, Yuying <yuying.zhang@intel.com>; Matz, Olivier
>> <olivier.matz@6wind.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Subject: Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
>>
>> On 11/16/2023 10:58 PM, Stephen Hemminger wrote:
>>> On Thu, 2 Nov 2023 19:20:07 +0000
>>> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>>
>>>> On 8/4/2023 9:28 AM, Kaiwen Deng wrote:
>>>>> IEEE 802 packets may have a minimum size limit. The data fields
>>>>> should be padded when necessary. In some cases, the padding data is
>>>>> not zero. Testpmd does not trim these IP packets to the true length
>>>>> of the frame, so errors will occur when calculating TCP or UDP
>>>>> checksum.
>>>>>
>>>>
>>>> Hi Kaiwen,
>>>>
>>>> I am trying to understand the problem, what is the testcase that has
>>>> checksum error?
>>>>
>>>> Are the received mbuf data_len & pkt_len wrong? Instead of trying to
>>>> fix the mbuf during forwarding, can we fix where packet generated?
>>>
>>> The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len which
>>> maybe larger than the actual data. The real issue is there and in
>>> rte_ip.h checksum code. The correct fix would be to use l3_len instead.
>>>
>>
>> I see, you are right.
>>
>> In 'rte_ipv4_udptcp_cksum_mbuf()',
>> as payload length "mbuf->pkt_len - l4_off" is used, which includes padding
>> and if padding is not zero it will end up producing wrong checksum.
>>
>>
>> I agree using 'l3_len' instead is correct fix.
>>
>> But this requires ABI/API change,
>> plus do we have any reason to keep the padding, discarding it as this patch
>> does is also simpler alternative.
>>
>>
>> Other alternative can be to zero the padding bytes. I guess standard doesn't
>> enforce them to be zero, but we can do this to remove its impact on checksum
>> calculation.
> I'm not sure if this is ok, it feels like it would reduce performance.
> I can try this alternative if needed.
>
Yes impacts performance, so not a good alternative, please scratch it.
As discussion with Stephen and Morten, consensus is to fix SW functions
that calculates checksum.
'rte_ipv4_udptcp_cksum_mbuf()' & 'rte_ipv6_udptcp_cksum_mbuf()'.
Instead of using packet_len, those functions can use packet length,
which will make the checksum correct.
Can you please send a patch to fix those functions? I think this can be
done without changing function fingerprint, so without causing any
ABI/API break.
>>
>>
>> @Kaiwen, did you able to test this with HW offload, what is the behavior of
>> the HW, does is remove padding bytes?
>>
> I tested the HW offload case and the same tcp/udp checksum error occurs when padding is not 0,
> But if change pkt_len to the true length of the frame, the checksum is correct.
>
I was expecting HW not impacted, since padding is part of the spec, my
assumption would be HW only take the actual payload size into account,
instead of buffer size.
Can you please double check? Which HW you are testing with, can you
please add maintainer of that HW to this discussion?
If HW requires padding to be removed, we may go with your solution.
>>
>>> It also looks like test-pmd is not validating the IP header.
>>> Both parse_ipv4() and parse_ipv6() should check if packet was truncated.
>>> Same for both UDP and TCP lengths.
>>>
>>
>
^ permalink raw reply [relevance 3%]
* Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-17 16:22 0% ` Stephen Hemminger
@ 2023-11-20 10:47 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-11-20 10:47 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Kaiwen Deng, dev, stable, qiming.yang, yidingx.zhou, Aman Singh,
Yuying Zhang, Olivier Matz, Pablo de Lara
On 11/17/2023 4:22 PM, Stephen Hemminger wrote:
> On Fri, 17 Nov 2023 09:29:41 +0000
> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
>>>> I agree using 'l3_len' instead is correct fix.
>>>>
>>>> But this requires ABI/API change,
>>>> plus do we have any reason to keep the padding, discarding it as this
>>>> patch does is also simpler alternative.
>>>
>>>
>>> Possibly an API version to change the args would work to fix.
>>>
>>
>> rte_ipv4_udptcp_cksum_mbuf() and rte_ipv6_udptcp_cksum_mbuf() are inline
>> functions, unfortunately we can't version them.
>>
>> But those functions already gets IP header as parameter, can't we use IP
>> header to get the payload size? If so this can be fixed without updating
>> API.
>
> Inlines are easier. Just make a fixed new function and make sure the old
> one is not used. They shouldn't have been inline in the first place.
>
I guess inlines as because of performance concerns, since it is in datapath.
^ permalink raw reply [relevance 0%]
* RE: [PATCH] app/test-pmd: fix L4 checksum with padding data
2023-11-20 10:46 3% ` Ferruh Yigit
@ 2023-11-22 3:04 0% ` Deng, KaiwenX
0 siblings, 0 replies; 200+ results
From: Deng, KaiwenX @ 2023-11-22 3:04 UTC (permalink / raw)
To: Ferruh Yigit, Stephen Hemminger, Morten Brørup, Zhang, Qi Z
Cc: dev, stable, Yang, Qiming, Zhou, YidingX, Singh, Aman Deep,
Zhang, Yuying, Matz, Olivier, De Lara Guarch, Pablo
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Monday, November 20, 2023 6:46 PM
> To: Deng, KaiwenX <kaiwenx.deng@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>; Morten Brørup
> <mb@smartsharesystems.com>
> Cc: dev@dpdk.org; stable@dpdk.org; Yang, Qiming <qiming.yang@intel.com>;
> Zhou, YidingX <yidingx.zhou@intel.com>; Singh, Aman Deep
> <aman.deep.singh@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>;
> Matz, Olivier <olivier.matz@6wind.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
>
> On 11/20/2023 9:21 AM, Deng, KaiwenX wrote:
> >
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit@amd.com>
> >> Sent: Friday, November 17, 2023 8:50 AM
> >> To: Stephen Hemminger <stephen@networkplumber.org>
> >> Cc: Deng, KaiwenX <kaiwenx.deng@intel.com>; dev@dpdk.org;
> >> stable@dpdk.org; Yang, Qiming <qiming.yang@intel.com>; Zhou, YidingX
> >> <yidingx.zhou@intel.com>; Singh, Aman Deep
> >> <aman.deep.singh@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>;
> >> Matz, Olivier <olivier.matz@6wind.com>; De Lara Guarch, Pablo
> >> <pablo.de.lara.guarch@intel.com>
> >> Subject: Re: [PATCH] app/test-pmd: fix L4 checksum with padding data
> >>
> >> On 11/16/2023 10:58 PM, Stephen Hemminger wrote:
> >>> On Thu, 2 Nov 2023 19:20:07 +0000
> >>> Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >>>
> >>>> On 8/4/2023 9:28 AM, Kaiwen Deng wrote:
> >>>>> IEEE 802 packets may have a minimum size limit. The data fields
> >>>>> should be padded when necessary. In some cases, the padding data
> >>>>> is not zero. Testpmd does not trim these IP packets to the true
> >>>>> length of the frame, so errors will occur when calculating TCP or
> >>>>> UDP checksum.
> >>>>>
> >>>>
> >>>> Hi Kaiwen,
> >>>>
> >>>> I am trying to understand the problem, what is the testcase that
> >>>> has checksum error?
> >>>>
> >>>> Are the received mbuf data_len & pkt_len wrong? Instead of trying
> >>>> to fix the mbuf during forwarding, can we fix where packet generated?
> >>>
> >>> The root cause is that get_udptcp_cksum_mbuf is using m->pkt_len
> >>> which maybe larger than the actual data. The real issue is there and
> >>> in rte_ip.h checksum code. The correct fix would be to use l3_len instead.
> >>>
> >>
> >> I see, you are right.
> >>
> >> In 'rte_ipv4_udptcp_cksum_mbuf()',
> >> as payload length "mbuf->pkt_len - l4_off" is used, which includes
> >> padding and if padding is not zero it will end up producing wrong
> checksum.
> >>
> >>
> >> I agree using 'l3_len' instead is correct fix.
> >>
> >> But this requires ABI/API change,
> >> plus do we have any reason to keep the padding, discarding it as this
> >> patch does is also simpler alternative.
> >>
> >>
> >> Other alternative can be to zero the padding bytes. I guess standard
> >> doesn't enforce them to be zero, but we can do this to remove its
> >> impact on checksum calculation.
> > I'm not sure if this is ok, it feels like it would reduce performance.
> > I can try this alternative if needed.
> >
>
> Yes impacts performance, so not a good alternative, please scratch it.
>
> As discussion with Stephen and Morten, consensus is to fix SW functions that
> calculates checksum.
> 'rte_ipv4_udptcp_cksum_mbuf()' & 'rte_ipv6_udptcp_cksum_mbuf()'.
>
> Instead of using packet_len, those functions can use packet length, which will
> make the checksum correct.
>
>
> Can you please send a patch to fix those functions? I think this can be done
> without changing function fingerprint, so without causing any ABI/API break.
>
>
> >>
> >>
> >> @Kaiwen, did you able to test this with HW offload, what is the
> >> behavior of the HW, does is remove padding bytes?
> >>
> > I tested the HW offload case and the same tcp/udp checksum error
> > occurs when padding is not 0, But if change pkt_len to the true length of the
> frame, the checksum is correct.
> >
>
> I was expecting HW not impacted, since padding is part of the spec, my
> assumption would be HW only take the actual payload size into account,
> instead of buffer size.
>
> Can you please double check? Which HW you are testing with, can you please
> add maintainer of that HW to this discussion?
I've tested hw offloads for udp and tcp with Intel E810. The hardware takes the size
of the buffer into account when calculating the udp/tcp checksum, not the size of the
actual payload.
Hi @Zhang, Qi Z,
Can you help confirm if this behavior is normal in hw?
Thanks!
>
> If HW requires padding to be removed, we may go with your solution.
>
>
> >>
> >>> It also looks like test-pmd is not validating the IP header.
> >>> Both parse_ipv4() and parse_ipv6() should check if packet was truncated.
> >>> Same for both UDP and TCP lengths.
> >>>
> >>
> >
^ permalink raw reply [relevance 0%]
* [PATCH 1/2] devtools: remove ABI exception for baseband FFT
@ 2023-11-23 8:58 9% David Marchand
2023-11-23 8:58 9% ` [PATCH 2/2] devtools: remove ABI exception for crypto asym operations David Marchand
2023-11-23 9:36 4% ` [PATCH 1/2] devtools: remove ABI exception for baseband FFT Maxime Coquelin
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2023-11-23 8:58 UTC (permalink / raw)
To: dev; +Cc: thomas, Stephen Hemminger, Maxime Coquelin
Those API are now stable.
Fixes: c96b519bd1c3 ("bbdev: promote some functions as stable")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/libabigail.abignore | 4 ----
1 file changed, 4 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 325f34e0b6..3ff51509de 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -37,10 +37,6 @@
type_kind = enum
changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
-; Ignore changes to bbdev FFT API which is experimental
-[suppress_type]
- name = rte_bbdev_fft_op
-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
--
2.41.0
^ permalink raw reply [relevance 9%]
* [PATCH 2/2] devtools: remove ABI exception for crypto asym operations
2023-11-23 8:58 9% [PATCH 1/2] devtools: remove ABI exception for baseband FFT David Marchand
@ 2023-11-23 8:58 9% ` David Marchand
2023-11-24 19:39 4% ` [EXT] " Akhil Goyal
2023-11-27 7:35 4% ` David Marchand
2023-11-23 9:36 4% ` [PATCH 1/2] devtools: remove ABI exception for baseband FFT Maxime Coquelin
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2023-11-23 8:58 UTC (permalink / raw)
To: dev; +Cc: thomas, Stephen Hemminger, Akhil Goyal
Those API are now stable.
Fixes: 79a4c2cda131 ("cryptodev: promote some functions as stable")
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/libabigail.abignore | 7 -------
1 file changed, 7 deletions(-)
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 3ff51509de..21b8cd6113 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -30,13 +30,6 @@
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
-; Ignore changes to asymmetric crypto API which is experimental
-[suppress_type]
- name = rte_crypto_asym_op
-[suppress_type]
- type_kind = enum
- changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
--
2.41.0
^ permalink raw reply [relevance 9%]
* Re: [PATCH 1/2] devtools: remove ABI exception for baseband FFT
2023-11-23 8:58 9% [PATCH 1/2] devtools: remove ABI exception for baseband FFT David Marchand
2023-11-23 8:58 9% ` [PATCH 2/2] devtools: remove ABI exception for crypto asym operations David Marchand
@ 2023-11-23 9:36 4% ` Maxime Coquelin
1 sibling, 0 replies; 200+ results
From: Maxime Coquelin @ 2023-11-23 9:36 UTC (permalink / raw)
To: David Marchand, dev; +Cc: thomas, Stephen Hemminger
On 11/23/23 09:58, David Marchand wrote:
> Those API are now stable.
>
> Fixes: c96b519bd1c3 ("bbdev: promote some functions as stable")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/libabigail.abignore | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 325f34e0b6..3ff51509de 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -37,10 +37,6 @@
> type_kind = enum
> changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM, RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>
> -; Ignore changes to bbdev FFT API which is experimental
> -[suppress_type]
> - name = rte_bbdev_fft_op
> -
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ; Temporary exceptions till next major ABI version ;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Thanks,
Maxime
^ permalink raw reply [relevance 4%]
* RE: [EXT] [PATCH 2/2] devtools: remove ABI exception for crypto asym operations
2023-11-23 8:58 9% ` [PATCH 2/2] devtools: remove ABI exception for crypto asym operations David Marchand
@ 2023-11-24 19:39 4% ` Akhil Goyal
2023-11-27 7:35 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2023-11-24 19:39 UTC (permalink / raw)
To: David Marchand, dev; +Cc: thomas, Stephen Hemminger
> Those API are now stable.
>
> Fixes: 79a4c2cda131 ("cryptodev: promote some functions as stable")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] devtools: remove ABI exception for crypto asym operations
2023-11-23 8:58 9% ` [PATCH 2/2] devtools: remove ABI exception for crypto asym operations David Marchand
2023-11-24 19:39 4% ` [EXT] " Akhil Goyal
@ 2023-11-27 7:35 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2023-11-27 7:35 UTC (permalink / raw)
To: David Marchand
Cc: dev, thomas, Stephen Hemminger, Akhil Goyal, Maxime Coquelin
On Thu, Nov 23, 2023 at 9:58 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> Those API are now stable.
>
> Fixes: 79a4c2cda131 ("cryptodev: promote some functions as stable")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Series applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* DPDK 23.11 released
@ 2023-11-28 16:15 4% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-11-28 16:15 UTC (permalink / raw)
To: announce; +Cc: Thomas Monjalon
A new major release is available:
https://fast.dpdk.org/rel/dpdk-23.11.tar.xz
The number of commits has been stable for the 23.xx releases:
1161 commits from 161 authors
1647 files changed, 97078 insertions(+), 44688 deletions(-)
The branch 23.11 should be supported for three years,
making it recommended for system integration and deployment.
The new major ABI version is 24.
The next releases 24.03 and 24.07 will be ABI-compatible with 23.11.
Below are some highlights of this release:
- build requires C11 compiler
- early support of MSVC build
- new atomic operations API
- power management on AMD CPU
- mbuf recycling
- RSS algorithm management
- maximum Rx buffer size
- flow action type for P4-defined actions
- flow group miss action
- flow item for packet type matching
- TLS record offload
- security Rx inject
- eventdev link profiles
- eventdev adapter for dmadev
- event dispatcher library
- nfp vDPA driver
- graph application
- removed flow_classify library
- removed KNI library and driver
More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_23_11.html
There are 40 new contributors (including authors, reviewers and testers).
Welcome to Alan Brady, Ales Musil, Andrey Ignatov, Artemy Kovalyov,
Chang Miao, Fengjiang Liu, Igor de Paula, Jayaprakash Shanmugam,
John Romein, Jonathan Erb, Jonathan Tsai, Josh Hay, Julian Grajkowski,
Karen Kelly, Kuan Xu, Madhu Chittim, Mahesh Adulla, Matthew Dirba,
Paul Szczepanek, Peter Nilsson, Sam Andrew, Sampath Peechu,
Saurabh Singhal, Shailendra Bhatnagar, Shihong Wang, Shubham Rohila,
Shujing Dong, Sibaranjan Pattnayak, Sinan Kaya, Sivaprasad Tummala,
Sivaramakrishnan Venkat, Timothy Miskell, Tomer Shmilovich, Trevor Tao,
Trevor Tao, Vamsi Krishna Attunuru, Wajeeh Atrash, Wei Hu,
Xiaoming Jiang, Zhenning Xiao.
Below is the number of commits per employer (with authors count):
240 Marvell (29)
203 Intel (39)
140 Corigine (9)
139 NVIDIA (25)
96 Huawei (4)
90 Red Hat (4)
71 Microsoft (5)
64 stephen@networkplumber.org (1)
24 AMD (9)
16 NXP (4)
13 Trustnet (1)
12 Arm (5)
...
A big thank to all courageous people who took on the non rewarding task
of reviewing other's job.
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
78 Morten Brørup <mb@smartsharesystems.com>
60 Bruce Richardson <bruce.richardson@intel.com>
55 David Marchand <david.marchand@redhat.com>
47 Ferruh Yigit <ferruh.yigit@amd.com>
33 Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
29 Maxime Coquelin <maxime.coquelin@redhat.com>
27 Tyler Retzlaff <roretzla@linux.microsoft.com>
21 Chengwen Feng <fengchengwen@huawei.com>
20 Stephen Hemminger <stephen@networkplumber.org>
20 Akhil Goyal <gakhil@marvell.com>
A special thanks to Stephen Hemminger who started cleaning stale patches in
patchwork.
We still have many Bugzilla tickets and unattended patches, all help is
welcome.
The next version will be 24.03 in March.
The new features for 24.03 can be submitted during the next weeks:
http://core.dpdk.org/roadmap#dates
Please share your roadmap.
Thanks everyone!
--
David Marchand
^ permalink raw reply [relevance 4%]
* [PATCH] doc: add sunset clause for experimental tag
@ 2023-11-29 15:27 4% Stephen Hemminger
2023-11-29 15:46 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2023-11-29 15:27 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The experimental tag is intended as temporary to avoid having
all of DPDK APIs as experimental and thereby rendering the
stable policy as worthless.
Add some wording into the existing policy in doc.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/contributing/abi_policy.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index 5fd405258592..fbf26ea24fd6 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -328,6 +328,16 @@ new APIs and start finding issues with them, new DPDK APIs will be automatically
marked as ``experimental`` to allow for a period of stabilization before they
become part of a tracked ABI version.
+The experimental tag has as limited lifetime (sunset provision).
+It is expected to be removed in a future release.
+The tag may be removed as soon as the second release with the new DPDK API.
+After one year, the API must be stable and tag removed unless an
+exception is approved by the technical board.
+
+For example, the symbol ``rte_flow_dev_dump`` was introduced
+in 20.02 release as ``experimental``. The tag could have been removed
+in 20.05 release, and should have been removed in 21.03 release.
+
Note that marking an API as experimental is a multi step process.
To mark an API as experimental, the symbols which are desired to be exported
must be placed in an EXPERIMENTAL version block in the corresponding libraries'
--
2.42.0
^ permalink raw reply [relevance 4%]
* Re: [PATCH] doc: add sunset clause for experimental tag
2023-11-29 15:27 4% [PATCH] doc: add sunset clause for experimental tag Stephen Hemminger
@ 2023-11-29 15:46 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-11-29 15:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Nov 29, 2023 at 07:27:38AM -0800, Stephen Hemminger wrote:
> The experimental tag is intended as temporary to avoid having
> all of DPDK APIs as experimental and thereby rendering the
> stable policy as worthless.
>
> Add some wording into the existing policy in doc.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> doc/guides/contributing/abi_policy.rst | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
> index 5fd405258592..fbf26ea24fd6 100644
> --- a/doc/guides/contributing/abi_policy.rst
> +++ b/doc/guides/contributing/abi_policy.rst
> @@ -328,6 +328,16 @@ new APIs and start finding issues with them, new DPDK APIs will be automatically
> marked as ``experimental`` to allow for a period of stabilization before they
> become part of a tracked ABI version.
>
> +The experimental tag has as limited lifetime (sunset provision).
> +It is expected to be removed in a future release.
> +The tag may be removed as soon as the second release with the new DPDK API.
> +After one year, the API must be stable and tag removed unless an
> +exception is approved by the technical board.
> +
We should also mention about the API being possibly removed or reworked.
> +For example, the symbol ``rte_flow_dev_dump`` was introduced
> +in 20.02 release as ``experimental``. The tag could have been removed
> +in 20.05 release, and should have been removed in 21.03 release.
> +
> Note that marking an API as experimental is a multi step process.
> To mark an API as experimental, the symbols which are desired to be exported
> must be placed in an EXPERIMENTAL version block in the corresponding libraries'
> --
> 2.42.0
>
^ permalink raw reply [relevance 0%]
* [PATCH] version: 24.03-rc0
@ 2023-11-29 16:18 11% David Marchand
2023-11-30 9:23 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-11-29 16:18 UTC (permalink / raw)
To: dev; +Cc: thomas, Aaron Conole, Michael Santana
Start a new release cycle with empty release notes.
Bump version and ABI minor.
Bump libabigail from 2.1 to 2.4 and enable ABI checks.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 7 +-
.github/workflows/build.yml | 6 +-
ABI_VERSION | 2 +-
VERSION | 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_24_03.rst | 138 +++++++++++++++++++++++++
6 files changed, 148 insertions(+), 8 deletions(-)
create mode 100644 doc/guides/rel_notes/release_24_03.rst
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 4cdbe9b9e9..1edbf5afc2 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -12,15 +12,16 @@ fi
install_libabigail() {
version=$1
instdir=$2
+ tarball=$version.tar.xz
- wget -q "http://mirrors.kernel.org/sourceware/libabigail/${version}.tar.gz"
- tar -xf ${version}.tar.gz
+ wget -q "http://mirrors.kernel.org/sourceware/libabigail/$tarball"
+ tar -xf $tarball
cd $version && autoreconf -vfi && cd -
mkdir $version/build
cd $version/build && ../configure --prefix=$instdir && cd -
make -C $version/build all install
rm -rf $version
- rm ${version}.tar.gz
+ rm $tarball
}
configure_coredump() {
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 272a6ffc7f..af514e9545 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -23,11 +23,11 @@ jobs:
BUILD_EXAMPLES: ${{ contains(matrix.config.checks, 'examples') }}
CC: ccache ${{ matrix.config.compiler }}
DEF_LIB: ${{ matrix.config.library }}
- LIBABIGAIL_VERSION: libabigail-2.1
+ LIBABIGAIL_VERSION: libabigail-2.4
MINGW: ${{ matrix.config.cross == 'mingw' }}
MINI: ${{ matrix.config.mini != '' }}
PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
- REF_GIT_TAG: none
+ REF_GIT_TAG: v23.11
RISCV64: ${{ matrix.config.cross == 'riscv64' }}
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
STDATOMIC: ${{ contains(matrix.config.checks, 'stdatomic') }}
@@ -47,7 +47,7 @@ jobs:
checks: stdatomic
- os: ubuntu-20.04
compiler: gcc
- checks: debug+doc+examples+tests
+ checks: abi+debug+doc+examples+tests
- os: ubuntu-20.04
compiler: clang
checks: asan+doc+tests
diff --git a/ABI_VERSION b/ABI_VERSION
index d9133a54b6..0dad123924 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-24.0
+24.1
diff --git a/VERSION b/VERSION
index 94c0153b26..04137136bd 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-23.11.0
+24.03.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index d072815279..88f2b30b03 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+ release_24_03
release_23_11
release_23_07
release_23_03
diff --git a/doc/guides/rel_notes/release_24_03.rst b/doc/guides/rel_notes/release_24_03.rst
new file mode 100644
index 0000000000..e9c9717706
--- /dev/null
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2023 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 24.03
+==================
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ ninja -C build doc
+ xdg-open build/doc/guides/html/rel_notes/release_24_03.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Removed Items
+-------------
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+* No ABI change that would break compatibility with 23.11.
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue
+ in the present tense. Add information on any known workarounds.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+ with this release.
+
+ The format is:
+
+ * <vendor> platform with <vendor> <type of devices> combinations
+
+ * List of CPU
+ * List of OS
+ * List of devices
+ * Other relevant details...
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
--
2.42.0
^ permalink raw reply [relevance 11%]
* [PATCH v5 01/19] mbuf: replace term sanity check
@ 2023-11-29 17:25 2% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-11-29 17:25 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Andrew Rybchenko, Morten Brørup,
Steven Webster, Matt Peters
Replace rte_mbuf_sanity_check() with rte_mbuf_verify()
to match the similar macro RTE_VERIFY() in rte_debug.h
The term sanity check is on the Tier 2 list of words
that should be replaced.
Note: the rte_mbuf_verify() function is added without
the experimental tag since it is intended as direct replacement
for old function name.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
---
app/test/test_mbuf.c | 28 +++++------
doc/guides/prog_guide/mbuf_lib.rst | 4 +-
doc/guides/rel_notes/deprecation.rst | 3 ++
drivers/net/avp/avp_ethdev.c | 18 +++----
drivers/net/sfc/sfc_ef100_rx.c | 6 +--
drivers/net/sfc/sfc_ef10_essb_rx.c | 4 +-
drivers/net/sfc/sfc_ef10_rx.c | 4 +-
drivers/net/sfc/sfc_rx.c | 2 +-
examples/ipv4_multicast/main.c | 2 +-
lib/mbuf/rte_mbuf.c | 23 +++++----
lib/mbuf/rte_mbuf.h | 71 +++++++++++++++-------------
lib/mbuf/version.map | 1 +
12 files changed, 90 insertions(+), 76 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index d7393df7eb5d..261c6e5d71e9 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -261,8 +261,8 @@ test_one_pktmbuf(struct rte_mempool *pktmbuf_pool)
GOTO_FAIL("Buffer should be continuous");
memset(hdr, 0x55, MBUF_TEST_HDR2_LEN);
- rte_mbuf_sanity_check(m, 1);
- rte_mbuf_sanity_check(m, 0);
+ rte_mbuf_verify(m, 1);
+ rte_mbuf_verify(m, 0);
rte_pktmbuf_dump(stdout, m, 0);
/* this prepend should fail */
@@ -1161,7 +1161,7 @@ test_refcnt_mbuf(void)
#ifdef RTE_EXEC_ENV_WINDOWS
static int
-test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
+test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
{
RTE_SET_USED(pktmbuf_pool);
return TEST_SKIPPED;
@@ -1180,12 +1180,12 @@ mbuf_check_pass(struct rte_mbuf *buf)
}
static int
-test_failing_mbuf_sanity_check(struct rte_mempool *pktmbuf_pool)
+test_failing_mbuf_verify(struct rte_mempool *pktmbuf_pool)
{
struct rte_mbuf *buf;
struct rte_mbuf badbuf;
- printf("Checking rte_mbuf_sanity_check for failure conditions\n");
+ printf("Checking rte_mbuf_verify for failure conditions\n");
/* get a good mbuf to use to make copies */
buf = rte_pktmbuf_alloc(pktmbuf_pool);
@@ -1707,7 +1707,7 @@ test_mbuf_validate_tx_offload(const char *test_name,
GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- rte_mbuf_sanity_check(m, 0);
+ rte_mbuf_verify(m, 0);
m->ol_flags = ol_flags;
m->tso_segsz = segsize;
ret = rte_validate_tx_offload(m);
@@ -1914,7 +1914,7 @@ test_pktmbuf_read(struct rte_mempool *pktmbuf_pool)
GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- rte_mbuf_sanity_check(m, 0);
+ rte_mbuf_verify(m, 0);
data = rte_pktmbuf_append(m, MBUF_TEST_DATA_LEN2);
if (data == NULL)
@@ -1963,7 +1963,7 @@ test_pktmbuf_read_from_offset(struct rte_mempool *pktmbuf_pool)
if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- rte_mbuf_sanity_check(m, 0);
+ rte_mbuf_verify(m, 0);
/* prepend an ethernet header */
hdr = (struct ether_hdr *)rte_pktmbuf_prepend(m, hdr_len);
@@ -2108,7 +2108,7 @@ create_packet(struct rte_mempool *pktmbuf_pool,
GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
if (rte_pktmbuf_pkt_len(pkt_seg) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- rte_mbuf_sanity_check(pkt_seg, 0);
+ rte_mbuf_verify(pkt_seg, 0);
/* Add header only for the first segment */
if (test_data->flags == MBUF_HEADER && seg == 0) {
hdr_len = sizeof(struct rte_ether_hdr);
@@ -2320,7 +2320,7 @@ test_pktmbuf_ext_shinfo_init_helper(struct rte_mempool *pktmbuf_pool)
GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- rte_mbuf_sanity_check(m, 0);
+ rte_mbuf_verify(m, 0);
ext_buf_addr = rte_malloc("External buffer", buf_len,
RTE_CACHE_LINE_SIZE);
@@ -2484,8 +2484,8 @@ test_pktmbuf_ext_pinned_buffer(struct rte_mempool *std_pool)
GOTO_FAIL("%s: test_pktmbuf_copy(pinned) failed\n",
__func__);
- if (test_failing_mbuf_sanity_check(pinned_pool) < 0)
- GOTO_FAIL("%s: test_failing_mbuf_sanity_check(pinned)"
+ if (test_failing_mbuf_verify(pinned_pool) < 0)
+ GOTO_FAIL("%s: test_failing_mbuf_verify(pinned)"
" failed\n", __func__);
if (test_mbuf_linearize_check(pinned_pool) < 0)
@@ -2859,8 +2859,8 @@ test_mbuf(void)
goto err;
}
- if (test_failing_mbuf_sanity_check(pktmbuf_pool) < 0) {
- printf("test_failing_mbuf_sanity_check() failed\n");
+ if (test_failing_mbuf_verify(pktmbuf_pool) < 0) {
+ printf("test_failing_mbuf_verify() failed\n");
goto err;
}
diff --git a/doc/guides/prog_guide/mbuf_lib.rst b/doc/guides/prog_guide/mbuf_lib.rst
index 049357c75563..0accb51a98c7 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -266,8 +266,8 @@ can be found in several of the sample applications, for example, the IPv4 Multic
Debug
-----
-In debug mode, the functions of the mbuf library perform sanity checks before any operation (such as, buffer corruption,
-bad type, and so on).
+In debug mode, the functions of the mbuf library perform consistency checks
+before any operation (such as, buffer corruption, bad type, and so on).
Use Cases
---------
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 81b93515cbd9..1e1544b5b644 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -146,3 +146,6 @@ Deprecation Notices
will be deprecated and subsequently removed in DPDK 24.11 release.
Before this, the new port library API (functions rte_swx_port_*)
will gradually transition from experimental to stable status.
+
+* mbuf: The function ``rte_mbuf_sanity_check`` is deprecated.
+ Use the new function ``rte_mbuf_verify`` instead.
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index 53d9e38c939b..ae76fad84948 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -1231,7 +1231,7 @@ _avp_mac_filter(struct avp_dev *avp, struct rte_mbuf *m)
#ifdef RTE_LIBRTE_AVP_DEBUG_BUFFERS
static inline void
-__avp_dev_buffer_sanity_check(struct avp_dev *avp, struct rte_avp_desc *buf)
+__avp_dev_buffer_check(struct avp_dev *avp, struct rte_avp_desc *buf)
{
struct rte_avp_desc *first_buf;
struct rte_avp_desc *pkt_buf;
@@ -1272,12 +1272,12 @@ __avp_dev_buffer_sanity_check(struct avp_dev *avp, struct rte_avp_desc *buf)
first_buf->pkt_len, pkt_len);
}
-#define avp_dev_buffer_sanity_check(a, b) \
- __avp_dev_buffer_sanity_check((a), (b))
+#define avp_dev_buffer_check(a, b) \
+ __avp_dev_buffer_check((a), (b))
#else /* RTE_LIBRTE_AVP_DEBUG_BUFFERS */
-#define avp_dev_buffer_sanity_check(a, b) do {} while (0)
+#define avp_dev_buffer_check(a, b) do {} while (0)
#endif
@@ -1302,7 +1302,7 @@ avp_dev_copy_from_buffers(struct avp_dev *avp,
void *pkt_data;
unsigned int i;
- avp_dev_buffer_sanity_check(avp, buf);
+ avp_dev_buffer_check(avp, buf);
/* setup the first source buffer */
pkt_buf = avp_dev_translate_buffer(avp, buf);
@@ -1370,7 +1370,7 @@ avp_dev_copy_from_buffers(struct avp_dev *avp,
rte_pktmbuf_pkt_len(m) = total_length;
m->vlan_tci = vlan_tci;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
return m;
}
@@ -1614,7 +1614,7 @@ avp_dev_copy_to_buffers(struct avp_dev *avp,
char *pkt_data;
unsigned int i;
- __rte_mbuf_sanity_check(mbuf, 1);
+ __rte_mbuf_verify(mbuf, 1);
m = mbuf;
src_offset = 0;
@@ -1680,7 +1680,7 @@ avp_dev_copy_to_buffers(struct avp_dev *avp,
first_buf->vlan_tci = mbuf->vlan_tci;
}
- avp_dev_buffer_sanity_check(avp, buffers[0]);
+ avp_dev_buffer_check(avp, buffers[0]);
return total_length;
}
@@ -1798,7 +1798,7 @@ avp_xmit_scattered_pkts(void *tx_queue,
#ifdef RTE_LIBRTE_AVP_DEBUG_BUFFERS
for (i = 0; i < nb_pkts; i++)
- avp_dev_buffer_sanity_check(avp, tx_bufs[i]);
+ avp_dev_buffer_check(avp, tx_bufs[i]);
#endif
/* send the packets */
diff --git a/drivers/net/sfc/sfc_ef100_rx.c b/drivers/net/sfc/sfc_ef100_rx.c
index 2677003da326..8199b56f2740 100644
--- a/drivers/net/sfc/sfc_ef100_rx.c
+++ b/drivers/net/sfc/sfc_ef100_rx.c
@@ -179,7 +179,7 @@ sfc_ef100_rx_qrefill(struct sfc_ef100_rxq *rxq)
struct sfc_ef100_rx_sw_desc *rxd;
rte_iova_t dma_addr;
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
dma_addr = rte_mbuf_data_iova_default(m);
if (rxq->flags & SFC_EF100_RXQ_NIC_DMA_MAP) {
@@ -551,7 +551,7 @@ sfc_ef100_rx_process_ready_pkts(struct sfc_ef100_rxq *rxq,
rxq->ready_pkts--;
pkt = sfc_ef100_rx_next_mbuf(rxq);
- __rte_mbuf_raw_sanity_check(pkt);
+ __rte_mbuf_raw_verify(pkt);
RTE_BUILD_BUG_ON(sizeof(pkt->rearm_data[0]) !=
sizeof(rxq->rearm_data));
@@ -575,7 +575,7 @@ sfc_ef100_rx_process_ready_pkts(struct sfc_ef100_rxq *rxq,
struct rte_mbuf *seg;
seg = sfc_ef100_rx_next_mbuf(rxq);
- __rte_mbuf_raw_sanity_check(seg);
+ __rte_mbuf_raw_verify(seg);
seg->data_off = RTE_PKTMBUF_HEADROOM;
diff --git a/drivers/net/sfc/sfc_ef10_essb_rx.c b/drivers/net/sfc/sfc_ef10_essb_rx.c
index 78bd430363b1..74647e2792b1 100644
--- a/drivers/net/sfc/sfc_ef10_essb_rx.c
+++ b/drivers/net/sfc/sfc_ef10_essb_rx.c
@@ -125,7 +125,7 @@ sfc_ef10_essb_next_mbuf(const struct sfc_ef10_essb_rxq *rxq,
struct rte_mbuf *m;
m = (struct rte_mbuf *)((uintptr_t)mbuf + rxq->buf_stride);
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
return m;
}
@@ -136,7 +136,7 @@ sfc_ef10_essb_mbuf_by_index(const struct sfc_ef10_essb_rxq *rxq,
struct rte_mbuf *m;
m = (struct rte_mbuf *)((uintptr_t)mbuf + idx * rxq->buf_stride);
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
return m;
}
diff --git a/drivers/net/sfc/sfc_ef10_rx.c b/drivers/net/sfc/sfc_ef10_rx.c
index 30a320d0791c..72b03b3bba7a 100644
--- a/drivers/net/sfc/sfc_ef10_rx.c
+++ b/drivers/net/sfc/sfc_ef10_rx.c
@@ -148,7 +148,7 @@ sfc_ef10_rx_qrefill(struct sfc_ef10_rxq *rxq)
struct sfc_ef10_rx_sw_desc *rxd;
rte_iova_t phys_addr;
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
SFC_ASSERT((id & ~ptr_mask) == 0);
rxd = &rxq->sw_ring[id];
@@ -297,7 +297,7 @@ sfc_ef10_rx_process_event(struct sfc_ef10_rxq *rxq, efx_qword_t rx_ev,
rxd = &rxq->sw_ring[pending++ & ptr_mask];
m = rxd->mbuf;
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
m->data_off = RTE_PKTMBUF_HEADROOM;
rte_pktmbuf_data_len(m) = seg_len;
diff --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c
index 1dde2c111001..645c8643d1c1 100644
--- a/drivers/net/sfc/sfc_rx.c
+++ b/drivers/net/sfc/sfc_rx.c
@@ -120,7 +120,7 @@ sfc_efx_rx_qrefill(struct sfc_efx_rxq *rxq)
++i, id = (id + 1) & rxq->ptr_mask) {
m = objs[i];
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
rxd = &rxq->sw_desc[id];
rxd->mbuf = m;
diff --git a/examples/ipv4_multicast/main.c b/examples/ipv4_multicast/main.c
index 6d0a8501eff5..f39658f4e249 100644
--- a/examples/ipv4_multicast/main.c
+++ b/examples/ipv4_multicast/main.c
@@ -258,7 +258,7 @@ mcast_out_pkt(struct rte_mbuf *pkt, int use_clone)
hdr->pkt_len = (uint16_t)(hdr->data_len + pkt->pkt_len);
hdr->nb_segs = pkt->nb_segs + 1;
- __rte_mbuf_sanity_check(hdr, 1);
+ __rte_mbuf_verify(hdr, 1);
return hdr;
}
/* >8 End of mcast_out_kt. */
diff --git a/lib/mbuf/rte_mbuf.c b/lib/mbuf/rte_mbuf.c
index 686e797c80c4..91cb2f84f6a1 100644
--- a/lib/mbuf/rte_mbuf.c
+++ b/lib/mbuf/rte_mbuf.c
@@ -363,9 +363,9 @@ rte_pktmbuf_pool_create_extbuf(const char *name, unsigned int n,
return mp;
}
-/* do some sanity checks on a mbuf: panic if it fails */
+/* do some checks on a mbuf: panic if it fails */
void
-rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
+rte_mbuf_verify(const struct rte_mbuf *m, int is_header)
{
const char *reason;
@@ -373,6 +373,13 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
rte_panic("%s\n", reason);
}
+/* For ABI compatibility, to be removed in next release */
+void
+rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
+{
+ rte_mbuf_verify(m, is_header);
+}
+
int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
const char **reason)
{
@@ -492,7 +499,7 @@ void rte_pktmbuf_free_bulk(struct rte_mbuf **mbufs, unsigned int count)
if (unlikely(m == NULL))
continue;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
do {
m_next = m->next;
@@ -542,7 +549,7 @@ rte_pktmbuf_clone(struct rte_mbuf *md, struct rte_mempool *mp)
return NULL;
}
- __rte_mbuf_sanity_check(mc, 1);
+ __rte_mbuf_verify(mc, 1);
return mc;
}
@@ -592,7 +599,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
struct rte_mbuf *mc, *m_last, **prev;
/* garbage in check */
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
/* check for request to copy at offset past end of mbuf */
if (unlikely(off >= m->pkt_len))
@@ -656,7 +663,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
}
/* garbage out check */
- __rte_mbuf_sanity_check(mc, 1);
+ __rte_mbuf_verify(mc, 1);
return mc;
}
@@ -667,7 +674,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len)
unsigned int len;
unsigned int nb_segs;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
fprintf(f, "dump mbuf at %p, iova=%#" PRIx64 ", buf_len=%u\n", m, rte_mbuf_iova_get(m),
m->buf_len);
@@ -685,7 +692,7 @@ rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len)
nb_segs = m->nb_segs;
while (m && nb_segs != 0) {
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(m, 0);
fprintf(f, " segment at %p, data=%p, len=%u, off=%u, refcnt=%u\n",
m, rte_pktmbuf_mtod(m, void *),
diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf/rte_mbuf.h
index 286b32b788a5..380663a0893b 100644
--- a/lib/mbuf/rte_mbuf.h
+++ b/lib/mbuf/rte_mbuf.h
@@ -339,13 +339,13 @@ rte_pktmbuf_priv_flags(struct rte_mempool *mp)
#ifdef RTE_LIBRTE_MBUF_DEBUG
-/** check mbuf type in debug mode */
-#define __rte_mbuf_sanity_check(m, is_h) rte_mbuf_sanity_check(m, is_h)
+/** do mbuf type in debug mode */
+#define __rte_mbuf_verify(m, is_h) rte_mbuf_verify(m, is_h)
#else /* RTE_LIBRTE_MBUF_DEBUG */
-/** check mbuf type in debug mode */
-#define __rte_mbuf_sanity_check(m, is_h) do { } while (0)
+/** ignore mbuf checks if not in debug mode */
+#define __rte_mbuf_verify(m, is_h) do { } while (0)
#endif /* RTE_LIBRTE_MBUF_DEBUG */
@@ -514,10 +514,9 @@ rte_mbuf_ext_refcnt_update(struct rte_mbuf_ext_shared_info *shinfo,
/**
- * Sanity checks on an mbuf.
+ * Check that the mbuf is valid and panic if corrupted.
*
- * Check the consistency of the given mbuf. The function will cause a
- * panic if corruption is detected.
+ * Acts assertion that mbuf is consistent. If not it calls rte_panic().
*
* @param m
* The mbuf to be checked.
@@ -526,13 +525,17 @@ rte_mbuf_ext_refcnt_update(struct rte_mbuf_ext_shared_info *shinfo,
* of a packet (in this case, some fields like nb_segs are not checked)
*/
void
+rte_mbuf_verify(const struct rte_mbuf *m, int is_header);
+
+/* Older deprecated name for rte_mbuf_verify() */
+void __rte_deprecated
rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
/**
- * Sanity checks on a mbuf.
+ * Do consistency checks on a mbuf.
*
- * Almost like rte_mbuf_sanity_check(), but this function gives the reason
- * if corruption is detected rather than panic.
+ * Check the consistency of the given mbuf and if not valid
+ * return the reason.
*
* @param m
* The mbuf to be checked.
@@ -551,7 +554,7 @@ int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
const char **reason);
/**
- * Sanity checks on a reinitialized mbuf in debug mode.
+ * Do checks on a reinitialized mbuf in debug mode.
*
* Check the consistency of the given reinitialized mbuf.
* The function will cause a panic if corruption is detected.
@@ -563,16 +566,16 @@ int rte_mbuf_check(const struct rte_mbuf *m, int is_header,
* The mbuf to be checked.
*/
static __rte_always_inline void
-__rte_mbuf_raw_sanity_check(__rte_unused const struct rte_mbuf *m)
+__rte_mbuf_raw_verify(__rte_unused const struct rte_mbuf *m)
{
RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
RTE_ASSERT(m->next == NULL);
RTE_ASSERT(m->nb_segs == 1);
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(m, 0);
}
/** For backwards compatibility. */
-#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_sanity_check(m)
+#define MBUF_RAW_ALLOC_CHECK(m) __rte_mbuf_raw_verify(m)
/**
* Allocate an uninitialized mbuf from mempool *mp*.
@@ -599,7 +602,7 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct rte_mempool *mp)
if (rte_mempool_get(mp, (void **)&m) < 0)
return NULL;
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
return m;
}
@@ -622,7 +625,7 @@ rte_mbuf_raw_free(struct rte_mbuf *m)
{
RTE_ASSERT(!RTE_MBUF_CLONED(m) &&
(!RTE_MBUF_HAS_EXTBUF(m) || RTE_MBUF_HAS_PINNED_EXTBUF(m)));
- __rte_mbuf_raw_sanity_check(m);
+ __rte_mbuf_raw_verify(m);
rte_mempool_put(m->pool, m);
}
@@ -885,7 +888,7 @@ static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
rte_pktmbuf_reset_headroom(m);
m->data_len = 0;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
}
/**
@@ -941,22 +944,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool,
switch (count % 4) {
case 0:
while (idx != count) {
- __rte_mbuf_raw_sanity_check(mbufs[idx]);
+ __rte_mbuf_raw_verify(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 3:
- __rte_mbuf_raw_sanity_check(mbufs[idx]);
+ __rte_mbuf_raw_verify(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 2:
- __rte_mbuf_raw_sanity_check(mbufs[idx]);
+ __rte_mbuf_raw_verify(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 1:
- __rte_mbuf_raw_sanity_check(mbufs[idx]);
+ __rte_mbuf_raw_verify(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
@@ -1184,8 +1187,8 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
mi->pkt_len = mi->data_len;
mi->nb_segs = 1;
- __rte_mbuf_sanity_check(mi, 1);
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(mi, 1);
+ __rte_mbuf_verify(m, 0);
}
/**
@@ -1340,7 +1343,7 @@ static inline int __rte_pktmbuf_pinned_extbuf_decref(struct rte_mbuf *m)
static __rte_always_inline struct rte_mbuf *
rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
{
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(m, 0);
if (likely(rte_mbuf_refcnt_read(m) == 1)) {
@@ -1411,7 +1414,7 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
struct rte_mbuf *m_next;
if (m != NULL)
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
while (m != NULL) {
m_next = m->next;
@@ -1492,7 +1495,7 @@ rte_pktmbuf_copy(const struct rte_mbuf *m, struct rte_mempool *mp,
*/
static inline void rte_pktmbuf_refcnt_update(struct rte_mbuf *m, int16_t v)
{
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
do {
rte_mbuf_refcnt_update(m, v);
@@ -1509,7 +1512,7 @@ static inline void rte_pktmbuf_refcnt_update(struct rte_mbuf *m, int16_t v)
*/
static inline uint16_t rte_pktmbuf_headroom(const struct rte_mbuf *m)
{
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(m, 0);
return m->data_off;
}
@@ -1523,7 +1526,7 @@ static inline uint16_t rte_pktmbuf_headroom(const struct rte_mbuf *m)
*/
static inline uint16_t rte_pktmbuf_tailroom(const struct rte_mbuf *m)
{
- __rte_mbuf_sanity_check(m, 0);
+ __rte_mbuf_verify(m, 0);
return (uint16_t)(m->buf_len - rte_pktmbuf_headroom(m) -
m->data_len);
}
@@ -1538,7 +1541,7 @@ static inline uint16_t rte_pktmbuf_tailroom(const struct rte_mbuf *m)
*/
static inline struct rte_mbuf *rte_pktmbuf_lastseg(struct rte_mbuf *m)
{
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
while (m->next != NULL)
m = m->next;
return m;
@@ -1582,7 +1585,7 @@ static inline struct rte_mbuf *rte_pktmbuf_lastseg(struct rte_mbuf *m)
static inline char *rte_pktmbuf_prepend(struct rte_mbuf *m,
uint16_t len)
{
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
if (unlikely(len > rte_pktmbuf_headroom(m)))
return NULL;
@@ -1617,7 +1620,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf *m, uint16_t len)
void *tail;
struct rte_mbuf *m_last;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
m_last = rte_pktmbuf_lastseg(m);
if (unlikely(len > rte_pktmbuf_tailroom(m_last)))
@@ -1645,7 +1648,7 @@ static inline char *rte_pktmbuf_append(struct rte_mbuf *m, uint16_t len)
*/
static inline char *rte_pktmbuf_adj(struct rte_mbuf *m, uint16_t len)
{
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
if (unlikely(len > m->data_len))
return NULL;
@@ -1677,7 +1680,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m, uint16_t len)
{
struct rte_mbuf *m_last;
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
m_last = rte_pktmbuf_lastseg(m);
if (unlikely(len > m_last->data_len))
@@ -1699,7 +1702,7 @@ static inline int rte_pktmbuf_trim(struct rte_mbuf *m, uint16_t len)
*/
static inline int rte_pktmbuf_is_contiguous(const struct rte_mbuf *m)
{
- __rte_mbuf_sanity_check(m, 1);
+ __rte_mbuf_verify(m, 1);
return m->nb_segs == 1;
}
diff --git a/lib/mbuf/version.map b/lib/mbuf/version.map
index daa65e2bbdb2..c85370e430b2 100644
--- a/lib/mbuf/version.map
+++ b/lib/mbuf/version.map
@@ -31,6 +31,7 @@ DPDK_24 {
rte_mbuf_set_platform_mempool_ops;
rte_mbuf_set_user_mempool_ops;
rte_mbuf_user_mempool_ops;
+ rte_mbuf_verify;
rte_pktmbuf_clone;
rte_pktmbuf_copy;
rte_pktmbuf_dump;
--
2.42.0
^ permalink raw reply [relevance 2%]
* Re: [PATCH] version: 24.03-rc0
2023-11-29 16:18 11% [PATCH] version: 24.03-rc0 David Marchand
@ 2023-11-30 9:23 3% ` David Marchand
2023-11-30 9:30 0% ` Ferruh Yigit
2023-11-30 18:33 0% ` Patrick Robb
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2023-11-30 9:23 UTC (permalink / raw)
To: David Marchand
Cc: dev, thomas, Aaron Conole, Michael Santana, Ferruh Yigit,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Akhil Goyal
On Wed, Nov 29, 2023 at 5:20 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Start a new release cycle with empty release notes.
> Bump version and ABI minor.
> Bump libabigail from 2.1 to 2.4 and enable ABI checks.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
Copying subtree maintainers, and ci@ mailing list.
As a result of the discussion on the ci ml
(http://inbox.dpdk.org/ci/CAJvnSUB2zXmHcdZC4rLruRm75MYOHJuWFUTtk8GNVRedfP_xXQ@mail.gmail.com/T/#t),
we worked on setting up some automatic mirroring of dpdk.org
repositories to the github DPDK repository.
What it means:
- for the https://dpdk.org/git/dpdk repository, all the branches and
tags are mirrored to https://github.com/DPDK/dpdk as it was done so
far,
- for the https://git.dpdk.org/next/dpdk-next-* repositories, only
branches named "main", "staging" or "for-*" are mirrored to
https://github.com/DPDK/dpdk with a prefix.
One example: changes to the for-main branch of the dpdk-next-crypto
repo will be mirrored to a github branch next-crypto-for-main
For subtree maintainers.
It should change nothing to you guys.
Please rebase your trees on v24.03-rc0 and push it to dpdk.org.
And then double check that the mirror happened (looking at git push
output, and checking https://github.com/DPDK/dpdk/branches).
If you hit some issue, ping me.
For CI.
This is more a fyi, there will be some delay before all mirrors are
up, so for now, don't swap the next-* repositories in your script yet.
However, one action that can be taken as v24.03-rc0 is pushed is to
re-enable ABI checks against the v23.11 official tag.
Questions?
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH] version: 24.03-rc0
2023-11-30 9:23 3% ` David Marchand
@ 2023-11-30 9:30 0% ` Ferruh Yigit
2023-11-30 9:32 0% ` David Marchand
2023-11-30 18:33 0% ` Patrick Robb
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-11-30 9:30 UTC (permalink / raw)
To: David Marchand
Cc: dev, thomas, Aaron Conole, Michael Santana, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Akhil Goyal
On 11/30/2023 9:23 AM, David Marchand wrote:
> On Wed, Nov 29, 2023 at 5:20 PM David Marchand
> <david.marchand@redhat.com> wrote:
>>
>> Start a new release cycle with empty release notes.
>> Bump version and ABI minor.
>> Bump libabigail from 2.1 to 2.4 and enable ABI checks.
>>
>> Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> Applied, thanks.
>
> Copying subtree maintainers, and ci@ mailing list.
> As a result of the discussion on the ci ml
> (http://inbox.dpdk.org/ci/CAJvnSUB2zXmHcdZC4rLruRm75MYOHJuWFUTtk8GNVRedfP_xXQ@mail.gmail.com/T/#t),
> we worked on setting up some automatic mirroring of dpdk.org
> repositories to the github DPDK repository.
>
>
> What it means:
> - for the https://dpdk.org/git/dpdk repository, all the branches and
> tags are mirrored to https://github.com/DPDK/dpdk as it was done so
> far,
> - for the https://git.dpdk.org/next/dpdk-next-* repositories, only
> branches named "main", "staging" or "for-*" are mirrored to
> https://github.com/DPDK/dpdk with a prefix.
> One example: changes to the for-main branch of the dpdk-next-crypto
> repo will be mirrored to a github branch next-crypto-for-main
>
>
> For subtree maintainers.
>
> It should change nothing to you guys.
> Please rebase your trees on v24.03-rc0 and push it to dpdk.org.
> And then double check that the mirror happened (looking at git push
> output, and checking https://github.com/DPDK/dpdk/branches).
> If you hit some issue, ping me.
>
I force push a lot, is mirroring configured to cope with this?
>
> For CI.
>
> This is more a fyi, there will be some delay before all mirrors are
> up, so for now, don't swap the next-* repositories in your script yet.
> However, one action that can be taken as v24.03-rc0 is pushed is to
> re-enable ABI checks against the v23.11 official tag.
>
>
> Questions?
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] version: 24.03-rc0
2023-11-30 9:30 0% ` Ferruh Yigit
@ 2023-11-30 9:32 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-11-30 9:32 UTC (permalink / raw)
To: Ferruh Yigit
Cc: dev, thomas, Aaron Conole, Michael Santana, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Akhil Goyal
On Thu, Nov 30, 2023 at 10:30 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 11/30/2023 9:23 AM, David Marchand wrote:
> > On Wed, Nov 29, 2023 at 5:20 PM David Marchand
> > <david.marchand@redhat.com> wrote:
> >>
> >> Start a new release cycle with empty release notes.
> >> Bump version and ABI minor.
> >> Bump libabigail from 2.1 to 2.4 and enable ABI checks.
> >>
> >> Signed-off-by: David Marchand <david.marchand@redhat.com>
> >
> > Applied, thanks.
> >
> > Copying subtree maintainers, and ci@ mailing list.
> > As a result of the discussion on the ci ml
> > (http://inbox.dpdk.org/ci/CAJvnSUB2zXmHcdZC4rLruRm75MYOHJuWFUTtk8GNVRedfP_xXQ@mail.gmail.com/T/#t),
> > we worked on setting up some automatic mirroring of dpdk.org
> > repositories to the github DPDK repository.
> >
> >
> > What it means:
> > - for the https://dpdk.org/git/dpdk repository, all the branches and
> > tags are mirrored to https://github.com/DPDK/dpdk as it was done so
> > far,
> > - for the https://git.dpdk.org/next/dpdk-next-* repositories, only
> > branches named "main", "staging" or "for-*" are mirrored to
> > https://github.com/DPDK/dpdk with a prefix.
> > One example: changes to the for-main branch of the dpdk-next-crypto
> > repo will be mirrored to a github branch next-crypto-for-main
> >
> >
> > For subtree maintainers.
> >
> > It should change nothing to you guys.
> > Please rebase your trees on v24.03-rc0 and push it to dpdk.org.
> > And then double check that the mirror happened (looking at git push
> > output, and checking https://github.com/DPDK/dpdk/branches).
> > If you hit some issue, ping me.
> >
>
> I force push a lot, is mirroring configured to cope with this?
It is supposed to be handled, yes.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH] version: 24.03-rc0
2023-11-30 9:23 3% ` David Marchand
2023-11-30 9:30 0% ` Ferruh Yigit
@ 2023-11-30 18:33 0% ` Patrick Robb
1 sibling, 0 replies; 200+ results
From: Patrick Robb @ 2023-11-30 18:33 UTC (permalink / raw)
To: David Marchand
Cc: dev, thomas, Aaron Conole, Michael Santana, Ferruh Yigit,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Akhil Goyal
[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]
On Thu, Nov 30, 2023 at 4:24 AM David Marchand <david.marchand@redhat.com>
wrote:
>
> What it means:
> - for the https://dpdk.org/git/dpdk repository, all the branches and
> tags are mirrored to https://github.com/DPDK/dpdk as it was done so
> far,
> - for the https://git.dpdk.org/next/dpdk-next-* repositories, only
> branches named "main", "staging" or "for-*" are mirrored to
> https://github.com/DPDK/dpdk with a prefix.
>
Thank you David for clearing some of this up on the CI testing meeting. I
think the final loose end was you were wondering which branches within the
next-* repos we were running from. I'll paste that below:
dpdk-next-crypto: for-main
dpdk-next-eventdev: for-main
dpdk-next-net: main
dpdk-next-net-brcm: main
dpdk-next-net-intel: main
dpdk-next-net-mlx: main
dpdk-next-net-mrvl: for-next-net
dpdk-next-virtio: main
dpdk-next-baseband: for-main
> One example: changes to the for-main branch of the dpdk-next-crypto
> repo will be mirrored to a github branch next-crypto-for-main
>
>
> For subtree maintainers.
>
> It should change nothing to you guys.
> Please rebase your trees on v24.03-rc0 and push it to dpdk.org.
> And then double check that the mirror happened (looking at git push
> output, and checking https://github.com/DPDK/dpdk/branches).
> If you hit some issue, ping me.
>
>
> For CI.
>
> This is more a fyi, there will be some delay before all mirrors are
> up, so for now, don't swap the next-* repositories in your script yet.
> However, one action that can be taken as v24.03-rc0 is pushed is to
> re-enable ABI checks against the v23.11 official tag.
>
> Okay, we will rebuild our container images to bake in new ABI references
this week. Thanks!
>
> Questions?
>
>
> --
> David Marchand
>
>
[-- Attachment #2: Type: text/html, Size: 3045 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [PATCH v13 00/21] Convert static log types in libraries to dynamic types
@ 2023-12-04 12:32 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-12-04 12:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Mon, Aug 21, 2023 at 6:09 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> This patchset removes most of the uses of static LOGTYPE's in DPDK
> libraries. It starts with the easy one and goes on to the more complex ones.
>
> There are several options on how to treat the old static types:
> leave them there, mark as deprecated, or remove them.
> This version removes them since there is no guarantee in current
> DPDK policies that says they can't be removed.
>
> Note: there is one patch in this series that will get
> flagged incorrectly as an ABI change.
>
> v13 - rebase because log now moved.
>
> v12 - rebase and add table and pipeline libraries
>
> v11 - fix include check on arm cross build
>
> v10 - add necessary rte_compat.h in thash_gfni stub for arm
>
> v9 - fix handling of crc32 alg in lib/hash.
> make it an internal global variable.
> fix gfni stubs for case where they are not used.
>
> Stephen Hemminger (21):
> gso: don't log message on non TCP/UDP
> eal: drop no longer used GSO logtype
> log: drop unused RTE_LOGTYPE_TIMER
> efd: convert RTE_LOGTYPE_EFD to dynamic type
> mbuf: convert RTE_LOGTYPE_MBUF to dynamic type
> acl: convert RTE_LOGTYPE_ACL to dynamic type
> examples/power: replace use of RTE_LOGTYPE_POWER
> examples/l3fwd-power: replace use of RTE_LOGTYPE_POWER
> power: convert RTE_LOGTYPE_POWER to dynamic type
> ring: convert RTE_LOGTYPE_RING to dynamic type
> mempool: convert RTE_LOGTYPE_MEMPOOL to dynamic type
> lpm: convert RTE_LOGTYPE_LPM to dynamic types
> sched: convert RTE_LOGTYPE_SCHED to dynamic type
> examples/ipsec-secgw: replace RTE_LOGTYPE_PORT
> port: convert RTE_LOGTYPE_PORT to dynamic type
> hash: move rte_thash_gfni stubs out of header file
> hash: move rte_hash_set_alg out header
> hash: convert RTE_LOGTYPE_HASH to dynamic type
> table: convert RTE_LOGTYPE_TABLE to dynamic type
> app/test: remove use of RTE_LOGTYPE_PIPELINE
> pipeline: convert RTE_LOGTYPE_PIPELINE to dynamic type
>
This series needs some rebase.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [PATCH 00/18] Convert static log types in libraries to dynamic
@ 2023-12-05 2:09 3% ` Stephen Hemminger
2023-12-05 2:09 2% ` [PATCH 17/18] hash: move rte_hash_set_alg out of header file Stephen Hemminger
2023-12-06 10:08 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic David Marchand
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2023-12-05 2:09 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This patchset removes most of the uses of static LOGTYPE's in DPDK
libraries. It starts with the easy one and goes on to the more complex ones.
There are several options on how to treat the old static types:
leave them there, mark as deprecated, or remove them.
This version removes them since there is no guarantee in current
DPDK policies that says they can't be removed.
Note: there is one patch in this series that will get
flagged incorrectly as an ABI change.
v14 - rebase on 24.03-rc0
skip port, table and pipeline libraries since lots of
to be deprecated code.
v13 - rebase because log now moved.
v12 - rebase and add table and pipeline libraries
v11 - fix include check on arm cross build
v10 - add necessary rte_compat.h in thash_gfni stub for arm
v9 - fix handling of crc32 alg in lib/hash.
make it an internal global variable.
fix gfni stubs for case where they are not used.
Stephen Hemminger (18):
gso: don't log message on non TCP/UDP
eal: drop no longer used GSO logtype
log: drop unused RTE_LOGTYPE_TIMER
efd: convert RTE_LOGTYPE_EFD to dynamic type
mbuf: convert RTE_LOGTYPE_MBUF to dynamic type
acl: convert RTE_LOGTYPE_ACL to dynamic type
examples/power: replace use of RTE_LOGTYPE_POWER
examples/l3fwd-power: replace use of RTE_LOGTYPE_POWER
power: convert RTE_LOGTYPE_POWER to dynamic type
ring: convert RTE_LOGTYPE_RING to dynamic type
mempool: convert RTE_LOGTYPE_MEMPOOL to dynamic type
lpm: convert RTE_LOGTYPE_LPM to dynamic types
sched: convert RTE_LOGTYPE_SCHED to dynamic type
examples/ipsec-secgw: replace RTE_LOGTYPE_PORT
app/test: remove use of RTE_LOGTYPE_PIPELINE
hash: mover rte_thash_gfni stubs out of header file
hash: move rte_hash_set_alg out of header file
hash: convert RTE_LOGTYPE_HASH to dynamic type
app/test/test_acl.c | 2 +-
app/test/test_table_acl.c | 50 ++++++++++++-------------
app/test/test_table_pipeline.c | 40 ++++++++++----------
examples/distributor/main.c | 2 +-
examples/ipsec-secgw/sa.c | 6 +--
examples/l3fwd-power/main.c | 17 +++++----
lib/acl/acl.h | 1 +
lib/acl/acl_bld.c | 3 ++
lib/acl/acl_gen.c | 1 +
lib/acl/acl_log.h | 6 +++
lib/acl/rte_acl.c | 3 ++
lib/acl/tb_mem.c | 3 +-
lib/efd/rte_efd.c | 4 ++
lib/fib/fib_log.h | 4 ++
lib/fib/rte_fib.c | 3 ++
lib/fib/rte_fib6.c | 2 +
lib/gso/rte_gso.c | 4 +-
lib/gso/rte_gso.h | 1 +
lib/hash/meson.build | 9 ++++-
lib/hash/rte_crc_arm64.h | 8 ++--
lib/hash/rte_crc_x86.h | 10 ++---
lib/hash/rte_cuckoo_hash.c | 5 +++
lib/hash/rte_fbk_hash.c | 5 +++
lib/hash/rte_hash_crc.c | 68 ++++++++++++++++++++++++++++++++++
lib/hash/rte_hash_crc.h | 48 ++----------------------
lib/hash/rte_thash.c | 3 ++
lib/hash/rte_thash_gfni.c | 50 +++++++++++++++++++++++++
lib/hash/rte_thash_gfni.h | 23 +++---------
lib/hash/version.map | 9 +++++
lib/log/log.c | 13 -------
lib/log/rte_log.h | 26 ++++++-------
lib/lpm/lpm_log.h | 4 ++
lib/lpm/rte_lpm.c | 3 ++
lib/lpm/rte_lpm6.c | 1 +
lib/mbuf/mbuf_log.h | 4 ++
lib/mbuf/rte_mbuf.c | 4 ++
lib/mbuf/rte_mbuf_dyn.c | 2 +
lib/mbuf/rte_mbuf_pool_ops.c | 2 +
lib/mempool/rte_mempool.c | 2 +
lib/mempool/rte_mempool.h | 8 ++++
lib/mempool/version.map | 3 ++
lib/power/power_common.c | 2 +
lib/power/power_common.h | 2 +
lib/power/power_kvm_vm.c | 1 +
lib/power/rte_power.c | 1 +
lib/power/rte_power_uncore.c | 1 +
lib/rib/rib_log.h | 4 ++
lib/rib/rte_rib.c | 3 ++
lib/rib/rte_rib6.c | 3 ++
lib/ring/rte_ring.c | 3 ++
lib/sched/rte_pie.c | 1 +
lib/sched/rte_sched.c | 5 +++
lib/sched/rte_sched_log.h | 4 ++
53 files changed, 329 insertions(+), 163 deletions(-)
create mode 100644 lib/acl/acl_log.h
create mode 100644 lib/fib/fib_log.h
create mode 100644 lib/hash/rte_hash_crc.c
create mode 100644 lib/hash/rte_thash_gfni.c
create mode 100644 lib/lpm/lpm_log.h
create mode 100644 lib/mbuf/mbuf_log.h
create mode 100644 lib/rib/rib_log.h
create mode 100644 lib/sched/rte_sched_log.h
--
2.42.0
^ permalink raw reply [relevance 3%]
* [PATCH 17/18] hash: move rte_hash_set_alg out of header file
2023-12-05 2:09 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic Stephen Hemminger
@ 2023-12-05 2:09 2% ` Stephen Hemminger
2023-12-06 10:08 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic David Marchand
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-12-05 2:09 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Ruifeng Wang, Yipeng Wang, Sameh Gobriel,
Bruce Richardson, Vladimir Medvedkin
The code for setting algorithm for hash is not at all perf sensitive,
and doing it inline has a couple of problems. First, it means that if
multiple files include the header, then the initialization gets done
multiple times. But also, it makes it harder to fix usage of RTE_LOG().
Despite what the checking script say. This is not an ABI change, the
previous version inlined the same code; therefore both old and new code
will work the same.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
---
lib/hash/meson.build | 1 +
lib/hash/rte_crc_arm64.h | 8 ++---
lib/hash/rte_crc_x86.h | 10 +++---
lib/hash/rte_hash_crc.c | 68 ++++++++++++++++++++++++++++++++++++++++
lib/hash/rte_hash_crc.h | 48 ++--------------------------
lib/hash/version.map | 7 +++++
6 files changed, 88 insertions(+), 54 deletions(-)
create mode 100644 lib/hash/rte_hash_crc.c
diff --git a/lib/hash/meson.build b/lib/hash/meson.build
index e56ee8572564..c345c6f561fc 100644
--- a/lib/hash/meson.build
+++ b/lib/hash/meson.build
@@ -19,6 +19,7 @@ indirect_headers += files(
sources = files(
'rte_cuckoo_hash.c',
+ 'rte_hash_crc.c',
'rte_fbk_hash.c',
'rte_thash.c',
'rte_thash_gfni.c'
diff --git a/lib/hash/rte_crc_arm64.h b/lib/hash/rte_crc_arm64.h
index c9f52510871b..414fe065caa8 100644
--- a/lib/hash/rte_crc_arm64.h
+++ b/lib/hash/rte_crc_arm64.h
@@ -53,7 +53,7 @@ crc32c_arm64_u64(uint64_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_ARM64))
+ if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u8(data, init_val);
return crc32c_1byte(data, init_val);
@@ -67,7 +67,7 @@ rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_ARM64))
+ if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u16(data, init_val);
return crc32c_2bytes(data, init_val);
@@ -81,7 +81,7 @@ rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_ARM64))
+ if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u32(data, init_val);
return crc32c_1word(data, init_val);
@@ -95,7 +95,7 @@ rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_8byte(uint64_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_ARM64))
+ if (likely(rte_hash_crc32_alg & CRC32_ARM64))
return crc32c_arm64_u64(data, init_val);
return crc32c_2words(data, init_val);
diff --git a/lib/hash/rte_crc_x86.h b/lib/hash/rte_crc_x86.h
index 205bc182be77..3b865e251db2 100644
--- a/lib/hash/rte_crc_x86.h
+++ b/lib/hash/rte_crc_x86.h
@@ -67,7 +67,7 @@ crc32c_sse42_u64(uint64_t data, uint64_t init_val)
static inline uint32_t
rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_SSE42))
+ if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u8(data, init_val);
return crc32c_1byte(data, init_val);
@@ -81,7 +81,7 @@ rte_hash_crc_1byte(uint8_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_SSE42))
+ if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u16(data, init_val);
return crc32c_2bytes(data, init_val);
@@ -95,7 +95,7 @@ rte_hash_crc_2byte(uint16_t data, uint32_t init_val)
static inline uint32_t
rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
{
- if (likely(crc32_alg & CRC32_SSE42))
+ if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u32(data, init_val);
return crc32c_1word(data, init_val);
@@ -110,11 +110,11 @@ static inline uint32_t
rte_hash_crc_8byte(uint64_t data, uint32_t init_val)
{
#ifdef RTE_ARCH_X86_64
- if (likely(crc32_alg == CRC32_SSE42_x64))
+ if (likely(rte_hash_crc32_alg == CRC32_SSE42_x64))
return crc32c_sse42_u64(data, init_val);
#endif
- if (likely(crc32_alg & CRC32_SSE42))
+ if (likely(rte_hash_crc32_alg & CRC32_SSE42))
return crc32c_sse42_u64_mimic(data, init_val);
return crc32c_2words(data, init_val);
diff --git a/lib/hash/rte_hash_crc.c b/lib/hash/rte_hash_crc.c
new file mode 100644
index 000000000000..1439d8a71f6a
--- /dev/null
+++ b/lib/hash/rte_hash_crc.c
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ */
+
+#include <rte_cpuflags.h>
+#include <rte_log.h>
+
+#include "rte_hash_crc.h"
+
+RTE_LOG_REGISTER_SUFFIX(hash_crc_logtype, crc, INFO);
+#define RTE_LOGTYPE_HASH_CRC hash_crc_logtype
+
+uint8_t rte_hash_crc32_alg = CRC32_SW;
+
+/**
+ * Allow or disallow use of SSE4.2/ARMv8 intrinsics for CRC32 hash
+ * calculation.
+ *
+ * @param alg
+ * An OR of following flags:
+ * - (CRC32_SW) Don't use SSE4.2/ARMv8 intrinsics (default non-[x86/ARMv8])
+ * - (CRC32_SSE42) Use SSE4.2 intrinsics if available
+ * - (CRC32_SSE42_x64) Use 64-bit SSE4.2 intrinsic if available (default x86)
+ * - (CRC32_ARM64) Use ARMv8 CRC intrinsic if available (default ARMv8)
+ *
+ */
+void
+rte_hash_crc_set_alg(uint8_t alg)
+{
+ rte_hash_crc32_alg = CRC32_SW;
+
+ if (alg == CRC32_SW)
+ return;
+
+#if defined RTE_ARCH_X86
+ if (!(alg & CRC32_SSE42_x64))
+ RTE_LOG(WARNING, HASH_CRC,
+ "Unsupported CRC32 algorithm requested using CRC32_x64/CRC32_SSE42\n");
+ if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T) || alg == CRC32_SSE42)
+ rte_hash_crc32_alg = CRC32_SSE42;
+ else
+ rte_hash_crc32_alg = CRC32_SSE42_x64;
+#endif
+
+#if defined RTE_ARCH_ARM64
+ if (!(alg & CRC32_ARM64))
+ RTE_LOG(WARNING, HASH_CRC,
+ "Unsupported CRC32 algorithm requested using CRC32_ARM64\n");
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_CRC32))
+ rte_hash_crc32_alg = CRC32_ARM64;
+#endif
+
+ if (rte_hash_crc32_alg == CRC32_SW)
+ RTE_LOG(WARNING, HASH_CRC,
+ "Unsupported CRC32 algorithm requested using CRC32_SW\n");
+}
+
+/* Setting the best available algorithm */
+RTE_INIT(rte_hash_crc_init_alg)
+{
+#if defined(RTE_ARCH_X86)
+ rte_hash_crc_set_alg(CRC32_SSE42_x64);
+#elif defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_CRC32)
+ rte_hash_crc_set_alg(CRC32_ARM64);
+#else
+ rte_hash_crc_set_alg(CRC32_SW);
+#endif
+}
diff --git a/lib/hash/rte_hash_crc.h b/lib/hash/rte_hash_crc.h
index 60bf42ce1d97..8ad2422ec333 100644
--- a/lib/hash/rte_hash_crc.h
+++ b/lib/hash/rte_hash_crc.h
@@ -20,8 +20,6 @@ extern "C" {
#include <rte_branch_prediction.h>
#include <rte_common.h>
#include <rte_config.h>
-#include <rte_cpuflags.h>
-#include <rte_log.h>
#include "rte_crc_sw.h"
@@ -31,7 +29,7 @@ extern "C" {
#define CRC32_SSE42_x64 (CRC32_x64|CRC32_SSE42)
#define CRC32_ARM64 (1U << 3)
-static uint8_t crc32_alg = CRC32_SW;
+extern uint8_t rte_hash_crc32_alg;
#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_CRC32)
#include "rte_crc_arm64.h"
@@ -52,48 +50,8 @@ static uint8_t crc32_alg = CRC32_SW;
* - (CRC32_SSE42_x64) Use 64-bit SSE4.2 intrinsic if available (default x86)
* - (CRC32_ARM64) Use ARMv8 CRC intrinsic if available (default ARMv8)
*/
-static inline void
-rte_hash_crc_set_alg(uint8_t alg)
-{
- crc32_alg = CRC32_SW;
-
- if (alg == CRC32_SW)
- return;
-
-#if defined RTE_ARCH_X86
- if (!(alg & CRC32_SSE42_x64))
- RTE_LOG(WARNING, HASH,
- "Unsupported CRC32 algorithm requested using CRC32_x64/CRC32_SSE42\n");
- if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_EM64T) || alg == CRC32_SSE42)
- crc32_alg = CRC32_SSE42;
- else
- crc32_alg = CRC32_SSE42_x64;
-#endif
-
-#if defined RTE_ARCH_ARM64
- if (!(alg & CRC32_ARM64))
- RTE_LOG(WARNING, HASH,
- "Unsupported CRC32 algorithm requested using CRC32_ARM64\n");
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_CRC32))
- crc32_alg = CRC32_ARM64;
-#endif
-
- if (crc32_alg == CRC32_SW)
- RTE_LOG(WARNING, HASH,
- "Unsupported CRC32 algorithm requested using CRC32_SW\n");
-}
-
-/* Setting the best available algorithm */
-RTE_INIT(rte_hash_crc_init_alg)
-{
-#if defined(RTE_ARCH_X86)
- rte_hash_crc_set_alg(CRC32_SSE42_x64);
-#elif defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_CRC32)
- rte_hash_crc_set_alg(CRC32_ARM64);
-#else
- rte_hash_crc_set_alg(CRC32_SW);
-#endif
-}
+void
+rte_hash_crc_set_alg(uint8_t alg);
#ifdef __DOXYGEN__
diff --git a/lib/hash/version.map b/lib/hash/version.map
index 56a0cbd4b8a5..ed0743adedbb 100644
--- a/lib/hash/version.map
+++ b/lib/hash/version.map
@@ -9,6 +9,7 @@ DPDK_24 {
rte_hash_add_key_with_hash;
rte_hash_add_key_with_hash_data;
rte_hash_count;
+ rte_hash_crc_set_alg;
rte_hash_create;
rte_hash_del_key;
rte_hash_del_key_with_hash;
@@ -46,3 +47,9 @@ DPDK_24 {
local: *;
};
+
+INTERNAL {
+ global:
+
+ rte_hash_crc32_alg;
+};
--
2.42.0
^ permalink raw reply [relevance 2%]
* Re: [PATCH 00/18] Convert static log types in libraries to dynamic
2023-12-05 2:09 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic Stephen Hemminger
2023-12-05 2:09 2% ` [PATCH 17/18] hash: move rte_hash_set_alg out of header file Stephen Hemminger
@ 2023-12-06 10:08 3% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2023-12-06 10:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Tue, Dec 5, 2023 at 3:13 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> This patchset removes most of the uses of static LOGTYPE's in DPDK
> libraries. It starts with the easy one and goes on to the more complex ones.
>
> There are several options on how to treat the old static types:
> leave them there, mark as deprecated, or remove them.
> This version removes them since there is no guarantee in current
> DPDK policies that says they can't be removed.
Those logtypes were internal things that should not have been public
in the first place.
And switching to a dynamic logtype for external users (if any) is trivial.
>
> Note: there is one patch in this series that will get
> flagged incorrectly as an ABI change.
Adding such stable symbols is not a problem.
We can ignore this warning (which is there to force maintainers to
inspect such additions).
>
> v14 - rebase on 24.03-rc0
> skip port, table and pipeline libraries since lots of
> to be deprecated code.
>
> v13 - rebase because log now moved.
>
> v12 - rebase and add table and pipeline libraries
>
> v11 - fix include check on arm cross build
>
> v10 - add necessary rte_compat.h in thash_gfni stub for arm
>
> v9 - fix handling of crc32 alg in lib/hash.
> make it an internal global variable.
> fix gfni stubs for case where they are not used.
>
> Stephen Hemminger (18):
> gso: don't log message on non TCP/UDP
> eal: drop no longer used GSO logtype
> log: drop unused RTE_LOGTYPE_TIMER
> efd: convert RTE_LOGTYPE_EFD to dynamic type
> mbuf: convert RTE_LOGTYPE_MBUF to dynamic type
> acl: convert RTE_LOGTYPE_ACL to dynamic type
> examples/power: replace use of RTE_LOGTYPE_POWER
> examples/l3fwd-power: replace use of RTE_LOGTYPE_POWER
> power: convert RTE_LOGTYPE_POWER to dynamic type
> ring: convert RTE_LOGTYPE_RING to dynamic type
> mempool: convert RTE_LOGTYPE_MEMPOOL to dynamic type
> lpm: convert RTE_LOGTYPE_LPM to dynamic types
> sched: convert RTE_LOGTYPE_SCHED to dynamic type
> examples/ipsec-secgw: replace RTE_LOGTYPE_PORT
> app/test: remove use of RTE_LOGTYPE_PIPELINE
> hash: mover rte_thash_gfni stubs out of header file
> hash: move rte_hash_set_alg out of header file
> hash: convert RTE_LOGTYPE_HASH to dynamic type
>
> app/test/test_acl.c | 2 +-
> app/test/test_table_acl.c | 50 ++++++++++++-------------
> app/test/test_table_pipeline.c | 40 ++++++++++----------
> examples/distributor/main.c | 2 +-
> examples/ipsec-secgw/sa.c | 6 +--
> examples/l3fwd-power/main.c | 17 +++++----
> lib/acl/acl.h | 1 +
> lib/acl/acl_bld.c | 3 ++
> lib/acl/acl_gen.c | 1 +
> lib/acl/acl_log.h | 6 +++
> lib/acl/rte_acl.c | 3 ++
> lib/acl/tb_mem.c | 3 +-
> lib/efd/rte_efd.c | 4 ++
> lib/fib/fib_log.h | 4 ++
> lib/fib/rte_fib.c | 3 ++
> lib/fib/rte_fib6.c | 2 +
> lib/gso/rte_gso.c | 4 +-
> lib/gso/rte_gso.h | 1 +
> lib/hash/meson.build | 9 ++++-
> lib/hash/rte_crc_arm64.h | 8 ++--
> lib/hash/rte_crc_x86.h | 10 ++---
> lib/hash/rte_cuckoo_hash.c | 5 +++
> lib/hash/rte_fbk_hash.c | 5 +++
> lib/hash/rte_hash_crc.c | 68 ++++++++++++++++++++++++++++++++++
> lib/hash/rte_hash_crc.h | 48 ++----------------------
> lib/hash/rte_thash.c | 3 ++
> lib/hash/rte_thash_gfni.c | 50 +++++++++++++++++++++++++
> lib/hash/rte_thash_gfni.h | 23 +++---------
> lib/hash/version.map | 9 +++++
> lib/log/log.c | 13 -------
> lib/log/rte_log.h | 26 ++++++-------
> lib/lpm/lpm_log.h | 4 ++
> lib/lpm/rte_lpm.c | 3 ++
> lib/lpm/rte_lpm6.c | 1 +
> lib/mbuf/mbuf_log.h | 4 ++
> lib/mbuf/rte_mbuf.c | 4 ++
> lib/mbuf/rte_mbuf_dyn.c | 2 +
> lib/mbuf/rte_mbuf_pool_ops.c | 2 +
> lib/mempool/rte_mempool.c | 2 +
> lib/mempool/rte_mempool.h | 8 ++++
> lib/mempool/version.map | 3 ++
> lib/power/power_common.c | 2 +
> lib/power/power_common.h | 2 +
> lib/power/power_kvm_vm.c | 1 +
> lib/power/rte_power.c | 1 +
> lib/power/rte_power_uncore.c | 1 +
> lib/rib/rib_log.h | 4 ++
> lib/rib/rte_rib.c | 3 ++
> lib/rib/rte_rib6.c | 3 ++
> lib/ring/rte_ring.c | 3 ++
> lib/sched/rte_pie.c | 1 +
> lib/sched/rte_sched.c | 5 +++
> lib/sched/rte_sched_log.h | 4 ++
> 53 files changed, 329 insertions(+), 163 deletions(-)
> create mode 100644 lib/acl/acl_log.h
> create mode 100644 lib/fib/fib_log.h
> create mode 100644 lib/hash/rte_hash_crc.c
> create mode 100644 lib/hash/rte_thash_gfni.c
> create mode 100644 lib/lpm/lpm_log.h
> create mode 100644 lib/mbuf/mbuf_log.h
> create mode 100644 lib/rib/rib_log.h
> create mode 100644 lib/sched/rte_sched_log.h
I fixed a few issues:
- added a release note update for the gso patch,
- fixed some styling issues in meson updates,
- reordered some hunks and patches,
- dropped some whitespace damage and typos,
- dropped unneeded include of rte_compat.h,
- fixed indent,
- marked exported variables as stable (such variable is part of the
application ABI),
Series applied.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 1/3] net/octeon_ep: optimize Rx and Tx routines
@ 2023-12-06 12:12 3% ` Jerin Jacob
2023-12-06 17:24 3% ` [PATCH v3 " pbhagavatula
1 sibling, 0 replies; 200+ results
From: Jerin Jacob @ 2023-12-06 12:12 UTC (permalink / raw)
To: pbhagavatula; +Cc: jerinj, Vamsi Attunuru, dev
On Mon, Nov 27, 2023 at 7:32 AM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Preset rearm data to avoid writing multiple fields in fastpath,
> Increase maximum outstanding Tx instructions from 128 to 256.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> v2 Changes:
> - Skip compiling for 32b x86 targets.
ABI issue due to
Error: cannot find librte_net_octeon_ep.so.24.0 in
/export/dpdk-next-net-mrvl/build-32b/install
^ permalink raw reply [relevance 3%]
* Re: [PATCH] cfgfile: increase value length
@ 2023-12-06 15:22 3% ` Varghese, Vipin
2023-12-06 15:50 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Varghese, Vipin @ 2023-12-06 15:22 UTC (permalink / raw)
To: Dumitrescu, Cristian, Richardson, Bruce
Cc: dev, Yigit, Ferruh, Parikh, Neerav
[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]
[AMD Official Use Only - General]
Thanks Bruce & Cristian for the comments.
An increase seems ok to me, but is an 8x increase really necessary? If
lines in the config files are over 1k in size, then it implies that some
other mechanism would surely be better for configuration.
Can we make do with an increase to 512 only?
VV> We encountered this issue https://bugs.dpdk.org/show_bug.cgi?id=1333 trying to use multiple queue with DSA. But I hear you 256 to 2048 is big jump.
Happy to compromise with 1K.
VV> Sure let me update this is v2.
Since there is a ABI breakage, https://patchwork.dpdk.org/project/dpdk/patch/20231206112952.1588-1-vipin.varghese@amd.com/ I will re work and share v2.
________________________________
From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
Sent: 06 December 2023 19:04
To: Richardson, Bruce <bruce.richardson@intel.com>; Varghese, Vipin <Vipin.Varghese@amd.com>
Cc: dev@dpdk.org <dev@dpdk.org>; Yigit, Ferruh <Ferruh.Yigit@amd.com>
Subject: RE: [PATCH] cfgfile: increase value length
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> -----Original Message-----
> From: Richardson, Bruce <bruce.richardson@intel.com>
> Sent: Wednesday, December 6, 2023 1:22 PM
> To: Vipin Varghese <vipin.varghese@amd.com>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> Ferruh Yigit <ferruh.yigit@amd.com>
> Subject: Re: [PATCH] cfgfile: increase value length
>
> On Wed, Dec 06, 2023 at 04:59:52PM +0530, Vipin Varghese wrote:
> > The default value for CFG_VALUE_LEN is set to 256 characters.
> > This limits the parsing for longer strings in configuration file.
> > Setting the default to 2048 characters increases the value array
> > size in `struct rte_cfgfile_entry`.
> >
> > Files using cfgfile library are
> > 1. drivers/net/mvpp2/
> > 2. app/test-dma-perf/
> > 3. app/test/
> > 4. examples/qos_sched/
> >
> > The structure `rte_cfgfile_entry` is not included in DPDK libraries.
> > Modifying from 256 to 2048 allows `app/test-dma-perf/main.c` helps to
> > parse longer string as shared in
> https://bugs.dpdk.org/show_bug.cgi?id=1333
> >
> > Signed-off-by: Vipin Varghese <vipin.varghese@amd.com>
> > Suggested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > ---
> > lib/cfgfile/rte_cfgfile.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/cfgfile/rte_cfgfile.h b/lib/cfgfile/rte_cfgfile.h
> > index 232c65c77b..401353c44e 100644
> > --- a/lib/cfgfile/rte_cfgfile.h
> > +++ b/lib/cfgfile/rte_cfgfile.h
> > @@ -24,7 +24,7 @@ extern "C" {
> > #endif
> >
> > #ifndef CFG_VALUE_LEN
> > -#define CFG_VALUE_LEN 256
> > +#define CFG_VALUE_LEN 2048
> > #endif
> >
> An increase seems ok to me, but is an 8x increase really necessary? If
> lines in the config files are over 1k in size, then it implies that some
> other mechanism would surely be better for configuration.
> Can we make do with an increase to 512 only?
>
> /Bruce
Happy to compromise with 1K.
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
[-- Attachment #2: Type: text/html, Size: 8779 bytes --]
^ permalink raw reply [relevance 3%]
* Re: [PATCH] cfgfile: increase value length
2023-12-06 15:22 3% ` Varghese, Vipin
@ 2023-12-06 15:50 3% ` Bruce Richardson
2023-12-06 16:46 3% ` Varghese, Vipin
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-12-06 15:50 UTC (permalink / raw)
To: Varghese, Vipin; +Cc: Dumitrescu, Cristian, dev, Yigit, Ferruh, Parikh, Neerav
On Wed, Dec 06, 2023 at 03:22:41PM +0000, Varghese, Vipin wrote:
> [AMD Official Use Only - General]
>
> Thanks Bruce & Cristian for the comments.
> An increase seems ok to me, but is an 8x increase really necessary? If
> lines in the config files are over 1k in size, then it implies that
> some
> other mechanism would surely be better for configuration.
> Can we make do with an increase to 512 only?
> VV> We encountered this issue
> [1]https://bugs.dpdk.org/show_bug.cgi?id=1333 trying to use multiple
> queue with DSA. But I hear you 256 to 2048 is big jump.
> Happy to compromise with 1K.
> VV> Sure let me update this is v2.
> Since there is a ABI breakage,
> [2]https://patchwork.dpdk.org/project/dpdk/patch/20231206112952.1588-1-
> vipin.varghese@amd.com/ I will re work and share v2.
Looking at the bugzilla, I still think even an increase to 1k is too much,
and that we should look to adjust the config file format in some way to
accomodate these longer line settings.
Taking the specific example in the bug:
* each entry in the line is wasting 5 characters with the string "lcore"
* each PCI ID is starting with 0000, so we can do like EAL does and assume
PCI domain is "0000" if just the BDF is given. This may involve changes
to the PCI driver in question, since i assume these queues are names
rather than addresses, but it would make them easier to address.
If we did these two items, then:
lcore_dma=lcore10@0000:00:04.2-q0,lcore12@0000:00:04.2-q1,lcore13@0000:00:04.2-q2,lcore14@0000:00:04.2-q3,lcore15@0000:00:04.2-q4,lcore16@0000:00:04.2-q5,lcore17@0000:00:04.2-q6,lcore18@0000:00:04.2-q7,lcore19@0000:00:04.4-q0,lcore20@0000:00:04.4-q1,lcore21@0000:00:04.4-q2,lcore22@0000:00:04.4-q3,lcore23@0000:00:04.4-q4,lcore24@0000:00:04.4-q5,lcore25@0000:00:04.4-q6,lcore26@0000:00:04.4-q7
becomes:
lcore_dma=10@00:04.2-q0,12@00:04.2-q1,13@00:04.2-q2,14@00:04.2-q3,15@00:04.2-q4,16@00:04.2-q5,17@00:04.2-q6,18@00:04.2-q7,19@00:04.4-q0,20@00:04.4-q1,21@00:04.4-q2,22@00:04.4-q3,23@00:04.4-q4,24@00:04.4-q5,25@00:04.4-q6,26@00:04.4-q7
a reduction from 394 chars to 234 (10 chars per device).
However, a better alternative may be to split up the lcore_dma item
entirely, so that we always have one element per line:
lcore_dma0=lcore10@0000:04.2-q0
lcore_dma1=lcore12@0000:04.2-q1
....
lcore_dma15=lcore26@0000:04.4-q7
What is especially good about using this is a solution is that it can be fully
backward compatible and has no ABI issues. If an "lcore_dma=" line exists,
we can split it, otherwise look for lcore_dma0, lcore_dma1 etc.
As I stated above, the need for really long lines in a config file is a
symptom of a more serious config problem, rather than an issue with the
cfgfile lib itself.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH] cfgfile: increase value length
2023-12-06 15:50 3% ` Bruce Richardson
@ 2023-12-06 16:46 3% ` Varghese, Vipin
0 siblings, 0 replies; 200+ results
From: Varghese, Vipin @ 2023-12-06 16:46 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Dumitrescu, Cristian, dev, Yigit, Ferruh, Parikh, Neerav
[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]
[AMD Official Use Only - General]
From: Bruce Richardson <bruce.richardson@intel.com>
Sent: 06 December 2023 21:20
To: Varghese, Vipin <Vipin.Varghese@amd.com>
Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org <dev@dpdk.org>; Yigit, Ferruh <Ferruh.Yigit@amd.com>; Parikh, Neerav <Neerav.Parikh@amd.com>
Subject: Re: [PATCH] cfgfile: increase value length
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
On Wed, Dec 06, 2023 at 03:22:41PM +0000, Varghese, Vipin wrote:
> [AMD Official Use Only - General]
>
> Thanks Bruce & Cristian for the comments.
> An increase seems ok to me, but is an 8x increase really necessary? If
> lines in the config files are over 1k in size, then it implies that
> some
> other mechanism would surely be better for configuration.
> Can we make do with an increase to 512 only?
> VV> We encountered this issue
> [1]https://bugs.dpdk.org/show_bug.cgi?id=1333 trying to use multiple
> queue with DSA. But I hear you 256 to 2048 is big jump.
> Happy to compromise with 1K.
> VV> Sure let me update this is v2.
> Since there is a ABI breakage,
> [2]https://patchwork.dpdk.org/project/dpdk/patch/20231206112952.1588-1-
> vipin.varghese@amd.com/ I will re work and share v2.
Looking at the bugzilla, I still think even an increase to 1k is too much,
and that we should look to adjust the config file format in some way to
accomodate these longer line settings.
Based on my testing 32 devices with the current format 2048B are appropriate.
That 4 DSA devices with 8 queues each.
Taking the specific example in the bug:
* each entry in the line is wasting 5 characters with the string "lcore"
* each PCI ID is starting with 0000, so we can do like EAL does and assume
PCI domain is "0000" if just the BDF is given. This may involve changes
to the PCI driver in question, since i assume these queues are names
rather than addresses, but it would make them easier to address.
If we did these two items, then:
lcore_dma=lcore10@0000:00:04.2-q0,lcore12@0000:00:04.2-q1,lcore13@0000:00:04.2-q2,lcore14@0000:00:04.2-q3,lcore15@0000:00:04.2-q4,lcore16@0000:00:04.2-q5,lcore17@0000:00:04.2-q6,lcore18@0000:00:04.2-q7,lcore19@0000:00:04.4-q0,lcore20@0000:00:04.4-q1,lcore21@0000:00:04.4-q2,lcore22@0000:00:04.4-q3,lcore23@0000:00:04.4-q4,lcore24@0000:00:04.4-q5,lcore25@0000:00:04.4-q6,lcore26@0000:00:04.4-q7
becomes:
lcore_dma=10@00:04.2-q0,12@00:04.2-q1,13@00:04.2-q2,14@00:04.2-q3,15@00:04.2-q4,16@00:04.2-q5,17@00:04.2-q6,18@00:04.2-q7,19@00:04.4-q0,20@00:04.4-q1,21@00:04.4-q2,22@00:04.4-q3,23@00:04.4-q4,24@00:04.4-q5,25@00:04.4-q6,26@00:04.4-q7
a reduction from 394 chars to 234 (10 chars per device).
I see what you are suggesting, even though DPDK documentation states 9. EAL parameters — Data Plane Development Kit 23.11.0 documentation (dpdk.org)<https://doc.dpdk.org/guides/linux_gsg/linux_eal_parameters.html> `<[domain:]bus:devid.func>`, omit the domain to `bus:devid.func>`. That will reduce the bytes I agree.
However, a better alternative may be to split up the lcore_dma item
entirely, so that we always have one element per line:
lcore_dma0=lcore10@0000:04.2-q0
lcore_dma1=lcore12@0000:04.2-q1
....
lcore_dma15=lcore26@0000:04.4-q7
What is especially good about using this is a solution is that it can be fully
backward compatible and has no ABI issues. If an "lcore_dma=" line exists,
we can split it, otherwise look for lcore_dma0, lcore_dma1 etc.
Ok, but this means the test-dma-perf will need parsing changes and cfgfile library.
As I stated above, the need for really long lines in a config file is a
symptom of a more serious config problem, rather than an issue with the
cfgfile lib itself.
I do not fully agree to this statement, here are my 2 points
1.
current code is `#ifndef CFG_VALUE_LEN` which means, the user can change the value using compiler flag `-DCFG_VALUE_LEN=[user desired value]` as cflags.
2.
If not declared as CFLAGS configuration value is assumed to be hardened to take only 256
Hence the reasoning would be `it was not assumed there would be change from 256B was not expected or explored. If 256B is the hardlimit then we should not have used #ifndef`.
But +1 for changing the parsing logic.
/Bruce
[-- Attachment #2: Type: text/html, Size: 8325 bytes --]
^ permalink raw reply [relevance 3%]
* [PATCH v3 1/3] net/octeon_ep: optimize Rx and Tx routines
2023-12-06 12:12 3% ` Jerin Jacob
@ 2023-12-06 17:24 3% ` pbhagavatula
2023-12-07 6:49 3% ` [PATCH v4 " pbhagavatula
1 sibling, 1 reply; 200+ results
From: pbhagavatula @ 2023-12-06 17:24 UTC (permalink / raw)
To: jerinj, Vamsi Attunuru; +Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Preset rearm data to avoid writing multiple fields in fastpath,
Increase maximum outstanding Tx instructions from 128 to 256.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
v3 Chnages:
- Add more comments to the code.
- Re-enable 32b build to prevent ABI break.
v2 Changes:
- Skip compiling for 32b x86 targets.
drivers/net/octeon_ep/cnxk_ep_rx.c | 12 ++++++++----
drivers/net/octeon_ep/otx_ep_common.h | 3 +++
drivers/net/octeon_ep/otx_ep_rxtx.c | 27 +++++++++++++++++++++++++++
drivers/net/octeon_ep/otx_ep_rxtx.h | 2 +-
4 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/net/octeon_ep/cnxk_ep_rx.c b/drivers/net/octeon_ep/cnxk_ep_rx.c
index 74f0011283..75bb7225d2 100644
--- a/drivers/net/octeon_ep/cnxk_ep_rx.c
+++ b/drivers/net/octeon_ep/cnxk_ep_rx.c
@@ -93,7 +93,7 @@ cnxk_ep_check_rx_pkts(struct otx_ep_droq *droq)
new_pkts = val - droq->pkts_sent_ism_prev;
droq->pkts_sent_ism_prev = val;
- if (val > (uint32_t)(1 << 31)) {
+ if (val > RTE_BIT32(31)) {
/* Only subtract the packet count in the HW counter
* when count above halfway to saturation.
*/
@@ -128,7 +128,6 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
{
struct rte_mbuf **recv_buf_list = droq->recv_buf_list;
uint32_t bytes_rsvd = 0, read_idx = droq->read_idx;
- uint16_t port_id = droq->otx_ep_dev->port_id;
uint16_t nb_desc = droq->nb_desc;
uint16_t pkts;
@@ -137,14 +136,19 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
struct rte_mbuf *mbuf;
uint16_t pkt_len;
+ rte_prefetch0(recv_buf_list[otx_ep_incr_index(read_idx, 2, nb_desc)]);
+ rte_prefetch0(rte_pktmbuf_mtod(recv_buf_list[otx_ep_incr_index(read_idx,
+ 2, nb_desc)],
+ void *));
+
mbuf = recv_buf_list[read_idx];
info = rte_pktmbuf_mtod(mbuf, struct otx_ep_droq_info *);
read_idx = otx_ep_incr_index(read_idx, 1, nb_desc);
pkt_len = rte_bswap16(info->length >> 48);
- mbuf->data_off += OTX_EP_INFO_SIZE;
mbuf->pkt_len = pkt_len;
mbuf->data_len = pkt_len;
- mbuf->port = port_id;
+
+ *(uint64_t *)&mbuf->rearm_data = droq->rearm_data;
rx_pkts[pkts] = mbuf;
bytes_rsvd += pkt_len;
}
diff --git a/drivers/net/octeon_ep/otx_ep_common.h b/drivers/net/octeon_ep/otx_ep_common.h
index 82e57520d3..299b5122d8 100644
--- a/drivers/net/octeon_ep/otx_ep_common.h
+++ b/drivers/net/octeon_ep/otx_ep_common.h
@@ -365,6 +365,9 @@ struct otx_ep_droq {
/* receive buffer list contains mbuf ptr list */
struct rte_mbuf **recv_buf_list;
+ /* Packet re-arm data. */
+ uint64_t rearm_data;
+
/* Packets pending to be processed */
uint64_t pkts_pending;
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c b/drivers/net/octeon_ep/otx_ep_rxtx.c
index c421ef0a1c..40c4a16a38 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -284,6 +284,32 @@ otx_ep_droq_setup_ring_buffers(struct otx_ep_droq *droq)
return 0;
}
+static inline uint64_t
+otx_ep_set_rearm_data(struct otx_ep_device *otx_ep)
+{
+ uint16_t port_id = otx_ep->port_id;
+ struct rte_mbuf mb_def;
+ uint64_t *tmp;
+
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, data_off) % 8 != 0);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, refcnt) - offsetof(struct rte_mbuf, data_off) !=
+ 2);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, nb_segs) - offsetof(struct rte_mbuf, data_off) !=
+ 4);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, port) - offsetof(struct rte_mbuf, data_off) !=
+ 6);
+ mb_def.nb_segs = 1;
+ mb_def.data_off = RTE_PKTMBUF_HEADROOM + OTX_EP_INFO_SIZE;
+ mb_def.port = port_id;
+ rte_mbuf_refcnt_set(&mb_def, 1);
+
+ /* Prevent compiler reordering: rearm_data covers previous fields */
+ rte_compiler_barrier();
+ tmp = (uint64_t *)&mb_def.rearm_data;
+
+ return *tmp;
+}
+
/* OQ initialization */
static int
otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
@@ -340,6 +366,7 @@ otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
goto init_droq_fail;
droq->refill_threshold = c_refill_threshold;
+ droq->rearm_data = otx_ep_set_rearm_data(otx_ep);
/* Set up OQ registers */
ret = otx_ep->fn_list.setup_oq_regs(otx_ep, q_no);
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.h b/drivers/net/octeon_ep/otx_ep_rxtx.h
index cb68ef3b41..b159c32cae 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.h
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.h
@@ -17,7 +17,7 @@
#define OTX_EP_FSZ 28
#define OTX2_EP_FSZ 24
-#define OTX_EP_MAX_INSTR 128
+#define OTX_EP_MAX_INSTR 256
/* SDP_LENGTH_S specifies packet length and is of 8-byte size */
#define OTX_EP_INFO_SIZE 8
--
2.25.1
^ permalink raw reply [relevance 3%]
* [PATCH v4 1/3] net/octeon_ep: optimize Rx and Tx routines
2023-12-06 17:24 3% ` [PATCH v3 " pbhagavatula
@ 2023-12-07 6:49 3% ` pbhagavatula
2023-12-11 13:43 3% ` [PATCH v5 " pbhagavatula
0 siblings, 1 reply; 200+ results
From: pbhagavatula @ 2023-12-07 6:49 UTC (permalink / raw)
To: jerinj, Vamsi Attunuru; +Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Preset rearm data to avoid writing multiple fields in fastpath,
Increase maximum outstanding Tx instructions from 128 to 256.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
v4 Changes:
- Fix checkpatch.
- Update release notes.
v3 Chnages:
- Add more comments to the code.
- Re-enable 32b build to prevent ABI break.
v2 Changes:
- Skip compiling for 32b x86 targets.
drivers/net/octeon_ep/cnxk_ep_rx.c | 12 ++++++++----
drivers/net/octeon_ep/otx_ep_common.h | 3 +++
drivers/net/octeon_ep/otx_ep_rxtx.c | 27 +++++++++++++++++++++++++++
drivers/net/octeon_ep/otx_ep_rxtx.h | 2 +-
4 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/net/octeon_ep/cnxk_ep_rx.c b/drivers/net/octeon_ep/cnxk_ep_rx.c
index 74f0011283..75bb7225d2 100644
--- a/drivers/net/octeon_ep/cnxk_ep_rx.c
+++ b/drivers/net/octeon_ep/cnxk_ep_rx.c
@@ -93,7 +93,7 @@ cnxk_ep_check_rx_pkts(struct otx_ep_droq *droq)
new_pkts = val - droq->pkts_sent_ism_prev;
droq->pkts_sent_ism_prev = val;
- if (val > (uint32_t)(1 << 31)) {
+ if (val > RTE_BIT32(31)) {
/* Only subtract the packet count in the HW counter
* when count above halfway to saturation.
*/
@@ -128,7 +128,6 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
{
struct rte_mbuf **recv_buf_list = droq->recv_buf_list;
uint32_t bytes_rsvd = 0, read_idx = droq->read_idx;
- uint16_t port_id = droq->otx_ep_dev->port_id;
uint16_t nb_desc = droq->nb_desc;
uint16_t pkts;
@@ -137,14 +136,19 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
struct rte_mbuf *mbuf;
uint16_t pkt_len;
+ rte_prefetch0(recv_buf_list[otx_ep_incr_index(read_idx, 2, nb_desc)]);
+ rte_prefetch0(rte_pktmbuf_mtod(recv_buf_list[otx_ep_incr_index(read_idx,
+ 2, nb_desc)],
+ void *));
+
mbuf = recv_buf_list[read_idx];
info = rte_pktmbuf_mtod(mbuf, struct otx_ep_droq_info *);
read_idx = otx_ep_incr_index(read_idx, 1, nb_desc);
pkt_len = rte_bswap16(info->length >> 48);
- mbuf->data_off += OTX_EP_INFO_SIZE;
mbuf->pkt_len = pkt_len;
mbuf->data_len = pkt_len;
- mbuf->port = port_id;
+
+ *(uint64_t *)&mbuf->rearm_data = droq->rearm_data;
rx_pkts[pkts] = mbuf;
bytes_rsvd += pkt_len;
}
diff --git a/drivers/net/octeon_ep/otx_ep_common.h b/drivers/net/octeon_ep/otx_ep_common.h
index 82e57520d3..299b5122d8 100644
--- a/drivers/net/octeon_ep/otx_ep_common.h
+++ b/drivers/net/octeon_ep/otx_ep_common.h
@@ -365,6 +365,9 @@ struct otx_ep_droq {
/* receive buffer list contains mbuf ptr list */
struct rte_mbuf **recv_buf_list;
+ /* Packet re-arm data. */
+ uint64_t rearm_data;
+
/* Packets pending to be processed */
uint64_t pkts_pending;
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c b/drivers/net/octeon_ep/otx_ep_rxtx.c
index c421ef0a1c..40c4a16a38 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -284,6 +284,32 @@ otx_ep_droq_setup_ring_buffers(struct otx_ep_droq *droq)
return 0;
}
+static inline uint64_t
+otx_ep_set_rearm_data(struct otx_ep_device *otx_ep)
+{
+ uint16_t port_id = otx_ep->port_id;
+ struct rte_mbuf mb_def;
+ uint64_t *tmp;
+
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, data_off) % 8 != 0);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, refcnt) - offsetof(struct rte_mbuf, data_off) !=
+ 2);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, nb_segs) - offsetof(struct rte_mbuf, data_off) !=
+ 4);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, port) - offsetof(struct rte_mbuf, data_off) !=
+ 6);
+ mb_def.nb_segs = 1;
+ mb_def.data_off = RTE_PKTMBUF_HEADROOM + OTX_EP_INFO_SIZE;
+ mb_def.port = port_id;
+ rte_mbuf_refcnt_set(&mb_def, 1);
+
+ /* Prevent compiler reordering: rearm_data covers previous fields */
+ rte_compiler_barrier();
+ tmp = (uint64_t *)&mb_def.rearm_data;
+
+ return *tmp;
+}
+
/* OQ initialization */
static int
otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
@@ -340,6 +366,7 @@ otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
goto init_droq_fail;
droq->refill_threshold = c_refill_threshold;
+ droq->rearm_data = otx_ep_set_rearm_data(otx_ep);
/* Set up OQ registers */
ret = otx_ep->fn_list.setup_oq_regs(otx_ep, q_no);
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.h b/drivers/net/octeon_ep/otx_ep_rxtx.h
index cb68ef3b41..b159c32cae 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.h
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.h
@@ -17,7 +17,7 @@
#define OTX_EP_FSZ 28
#define OTX2_EP_FSZ 24
-#define OTX_EP_MAX_INSTR 128
+#define OTX_EP_MAX_INSTR 256
/* SDP_LENGTH_S specifies packet length and is of 8-byte size */
#define OTX_EP_INFO_SIZE 8
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH RESEND v6 0/5] app/testpmd: support multiple process attach and detach port
2023-10-30 12:17 0% ` lihuisong (C)
@ 2023-12-08 2:25 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-12-08 2:25 UTC (permalink / raw)
To: thomas, ferruh.yigit
Cc: andrew.rybchenko, fengchengwen, liudongdong3, liuyonglong, dev
Hi Ferruh and Thomas,
This series have been discussing for over a year and a half.
Looking back on previous discussions, we have also made some progress
and consensus.
I am sticking to track it. Because they resolve a real exist issue.
Can you take a look at it again?
BR,
/Huisong
在 2023/10/30 20:17, lihuisong (C) 写道:
> Hi Ferruh and Thomas,
>
> This series have been discussing more than one year.
> Kindly ping for reivew.
>
>
> 在 2023/10/9 18:34, lihuisong (C) 写道:
>> Hi Ferruh and Thomas,
>>
>> Can you take a look at this series? They've been over a year on
>> disscussion.
>>
>>
>> 在 2023/8/2 11:15, Huisong Li 写道:
>>> This patchset fix some bugs and support attaching and detaching port
>>> in primary and secondary.
>>>
>>> ---
>>> -v6: adjust rte_eth_dev_is_used position based on alphabetical order
>>> in version.map
>>> -v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi
>>> break.
>>> -v4: fix a misspelling.
>>> -v3:
>>> #1 merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>> modification
>>> for other bus type.
>>> #2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to
>>> resolve
>>> the probelm in patch 2/5.
>>> -v2: resend due to CI unexplained failure.
>>>
>>> Huisong Li (5):
>>> drivers/bus: restore driver assignment at front of probing
>>> ethdev: fix skip valid port in probing callback
>>> app/testpmd: check the validity of the port
>>> app/testpmd: add attach and detach port for multiple process
>>> app/testpmd: stop forwarding in new or destroy event
>>>
>>> app/test-pmd/testpmd.c | 47
>>> +++++++++++++++---------
>>> app/test-pmd/testpmd.h | 1 -
>>> drivers/bus/auxiliary/auxiliary_common.c | 9 ++++-
>>> drivers/bus/dpaa/dpaa_bus.c | 9 ++++-
>>> drivers/bus/fslmc/fslmc_bus.c | 8 +++-
>>> drivers/bus/ifpga/ifpga_bus.c | 12 ++++--
>>> drivers/bus/pci/pci_common.c | 9 ++++-
>>> drivers/bus/vdev/vdev.c | 10 ++++-
>>> drivers/bus/vmbus/vmbus_common.c | 9 ++++-
>>> drivers/net/bnxt/bnxt_ethdev.c | 3 +-
>>> drivers/net/bonding/bonding_testpmd.c | 1 -
>>> drivers/net/mlx5/mlx5.c | 2 +-
>>> lib/ethdev/ethdev_driver.c | 13 +++++--
>>> lib/ethdev/ethdev_driver.h | 12 ++++++
>>> lib/ethdev/ethdev_pci.h | 2 +-
>>> lib/ethdev/rte_class_eth.c | 2 +-
>>> lib/ethdev/rte_ethdev.c | 4 +-
>>> lib/ethdev/rte_ethdev.h | 4 +-
>>> lib/ethdev/version.map | 1 +
>>> 19 files changed, 114 insertions(+), 44 deletions(-)
>>>
>>
>> .
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH] bus/uacce: introduce UACCE bus
@ 2023-12-08 6:18 2% Chengwen Feng
0 siblings, 0 replies; 200+ results
From: Chengwen Feng @ 2023-12-08 6:18 UTC (permalink / raw)
To: thomas, dev; +Cc: tangkunshan, fanghao11, wangzhou1
UACCE (Unified/User-space-access-intended Accelerator Framework) was
upstream to Linux kernel version 5.7, and it targets to provide Shared
Virtual Addressing (SVA) between accelerators and processes. So
accelerator can access any data structure of the main cpu. [1] for more
information.
This commit introduces UACCE bus, so that the accelerator devices could
seen at DPDK and could be further registered as a compress, crypto, dma
and ethdev device.
[1] https://docs.kernel.org/misc-devices/uacce.html
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
MAINTAINERS | 4 +
drivers/bus/meson.build | 1 +
drivers/bus/uacce/bus_uacce_driver.h | 254 ++++++++++
drivers/bus/uacce/meson.build | 12 +
drivers/bus/uacce/uacce.c | 702 +++++++++++++++++++++++++++
drivers/bus/uacce/version.map | 15 +
6 files changed, 988 insertions(+)
create mode 100644 drivers/bus/uacce/bus_uacce_driver.h
create mode 100644 drivers/bus/uacce/meson.build
create mode 100644 drivers/bus/uacce/uacce.c
create mode 100644 drivers/bus/uacce/version.map
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..89711029d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -604,6 +604,10 @@ Platform bus driver
M: Tomasz Duszynski <tduszynski@marvell.com>
F: drivers/bus/platform/
+UACCE bus driver
+M: Chengwen Feng <fengchengwen@huawei.com>
+F: drivers/bus/uacce/
+
VDEV bus driver
F: drivers/bus/vdev/
F: app/test/test_vdev.c
diff --git a/drivers/bus/meson.build b/drivers/bus/meson.build
index a78b4283bf..d67db8576b 100644
--- a/drivers/bus/meson.build
+++ b/drivers/bus/meson.build
@@ -9,6 +9,7 @@ drivers = [
'ifpga',
'pci',
'platform',
+ 'uacce',
'vdev',
'vmbus',
]
diff --git a/drivers/bus/uacce/bus_uacce_driver.h b/drivers/bus/uacce/bus_uacce_driver.h
new file mode 100644
index 0000000000..0276154658
--- /dev/null
+++ b/drivers/bus/uacce/bus_uacce_driver.h
@@ -0,0 +1,254 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 HiSilicon Limited
+ */
+
+#ifndef BUS_UACCE_DRIVER_H
+#define BUS_UACCE_DRIVER_H
+
+/**
+ * @file
+ *
+ * HiSilicon UACCE bus interface.
+ */
+
+#include <inttypes.h>
+#include <stdlib.h>
+#include <linux/types.h>
+
+#include <rte_compat.h>
+#include <rte_devargs.h>
+#include <dev_driver.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+#define RTE_UACCE_DEV_PATH_SIZE 256
+#define RTE_UACCE_API_NAME_SIZE 64
+#define RTE_UACCE_ALGS_NAME_SIZE 384
+#define RTE_UACCE_ATTR_MAX_SIZE 384
+
+/*
+ * Definition for queue file region type.
+ */
+enum rte_uacce_qfrt {
+ RTE_UACCE_QFRT_MMIO = 0, /**< Device mmio region. */
+ RTE_UACCE_QFRT_DUS, /**< Device user share region. */
+ RTE_UACCE_QFRT_BUTT
+};
+
+struct rte_uacce_driver;
+
+/**
+ * A structure describing a UACCE device.
+ */
+struct rte_uacce_device {
+ RTE_TAILQ_ENTRY(rte_uacce_device) next; /**< Next in device list. */
+ struct rte_device device; /**< Inherit core device. */
+ struct rte_uacce_driver *driver; /**< Driver used in probing. */
+ char name[RTE_DEV_NAME_MAX_LEN]; /**< Device name. */
+ char dev_root[RTE_UACCE_DEV_PATH_SIZE]; /**< Sysfs path with device name. */
+ char cdev_path[RTE_UACCE_DEV_PATH_SIZE]; /**< Device path in devfs. */
+ char api[RTE_UACCE_API_NAME_SIZE]; /**< Device context type. */
+ char algs[RTE_UACCE_ALGS_NAME_SIZE]; /**< Device supported algorithms. */
+ uint32_t flags; /**< Device flags. */
+ int numa_node; /**< NUMA node connection, -1 if unknown. */
+ uint32_t qfrt_sz[RTE_UACCE_QFRT_BUTT]; /**< Queue file region type's size. */
+};
+
+/**
+ * @internal
+ * Helper macro for drivers that need to convert to struct rte_uacce_device.
+ */
+#define RTE_DEV_TO_UACCE_DEV(ptr) \
+ container_of(ptr, struct rte_uacce_device, device)
+
+#define RTE_DEV_TO_UACCE_DEV_CONST(ptr) \
+ container_of(ptr, const struct rte_uacce_device, device)
+
+/**
+ * A structure describing an ID for a UACCE driver. Each driver provides a
+ * table of these IDs for each device that it supports.
+ */
+struct rte_uacce_id {
+ const char *dev_api; /**< Device context type. */
+ /** Device algorithm.
+ * If this field is NULL, only dev_api is matched. Otherwise, in
+ * addition to match dev_api, dev_alg must be a subset of device's
+ * algs.
+ */
+ const char *dev_alg;
+};
+
+/**
+ * Initialization function for the driver called during probing.
+ */
+typedef int (rte_uacce_probe_t)(struct rte_uacce_driver *, struct rte_uacce_device *);
+
+/**
+ * Uninitialization function for the driver called during hotplugging.
+ */
+typedef int (rte_uacce_remove_t)(struct rte_uacce_device *);
+
+/**
+ * A structure describing a UACCE driver.
+ */
+struct rte_uacce_driver {
+ RTE_TAILQ_ENTRY(rte_uacce_driver) next; /**< Next in list. */
+ struct rte_driver driver; /**< Inherit core driver. */
+ struct rte_uacce_bus *bus; /**< UACCE bus reference. */
+ rte_uacce_probe_t *probe; /**< Device probe function. */
+ rte_uacce_remove_t *remove; /**< Device remove function. */
+ const struct rte_uacce_id *id_table; /**< ID table, NULL terminated. */
+};
+
+/**
+ * Get available queue number.
+ *
+ * @param dev
+ * A pointer to a rte_uacce_device structure describing the device
+ * to use.
+ *
+ * @note The available queues on the device may changes dynamically,
+ * for examples, other process may alloc or free queues.
+ *
+ * @return
+ * 0 on success. Otherwise negative value is returned.
+ */
+__rte_internal
+int rte_uacce_avail_queues(struct rte_uacce_device *dev);
+
+/*
+ * The queue context for a UACCE queue.
+ */
+struct rte_uacce_qcontex {
+ int fd; /**< The file descriptor associated to the queue. */
+ struct rte_uacce_device *dev; /**< The device associated to the queue. */
+ void *qfrt_base[RTE_UACCE_QFRT_BUTT]; /**< The qfrt mmap's memory base. */
+};
+
+/**
+ * Alloc one queue.
+ *
+ * @param dev
+ * A pointer to a rte_uacce_device structure describing the device to use.
+ * @param qctx
+ * Pointer to queue context, which is used to store the queue information
+ * that is successfully applied for.
+ *
+ * @return
+ * 0 on success. Otherwise negative value is returned.
+ */
+__rte_internal
+int rte_uacce_queue_alloc(struct rte_uacce_device *dev, struct rte_uacce_qcontex *qctx);
+
+/**
+ * Free one queue.
+ *
+ * @param qctx
+ * Pointer to queue context, which allocated by @see rte_uacce_alloc_queue.
+ *
+ * @note Once the queue is freed, any operations on the queue (including
+ * control-plane and data-plane, and also read & write mmap region) are not
+ * allowed.
+ */
+__rte_internal
+void rte_uacce_queue_free(struct rte_uacce_qcontex *qctx);
+
+/**
+ * Start one queue.
+ *
+ * @param qctx
+ * Pointer to queue context, which allocated by @see rte_uacce_alloc_queue.
+ *
+ * @return
+ * 0 on success. Otherwise negative value is returned.
+ */
+__rte_internal
+int rte_uacce_queue_start(struct rte_uacce_qcontex *qctx);
+
+/**
+ * Send ioctl command to one queue.
+ *
+ * @param qctx
+ * Pointer to queue context, which allocated by @see rte_uacce_alloc_queue.
+ * @param cmd
+ * ioctl command.
+ * @note The nr must not conflict with the definition in Linux kerel:
+ * include/uapi/misc/uacce/uacce.h. It is recommended that the driver
+ * custom nr start from 64.
+ * @param arg
+ * Command input & output buffer.
+ *
+ * @return
+ * 0 on success. Otherwise negative value is returned.
+ */
+__rte_internal
+int rte_uacce_queue_ioctl(struct rte_uacce_qcontex *qctx, unsigned long cmd, void *arg);
+
+/**
+ * Mmap queue file region.
+ *
+ * @param qctx
+ * Pointer to queue context, which allocated by @see rte_uacce_alloc_queue.
+ * @param qfrt
+ * The queue file region type. Must be RTE_UACCE_QFRT_MMIO or
+ * RTE_UACCE_QFRT_DUS.
+ *
+ * @return
+ * Non-NULL on success. Otherwise NULL is returned.
+ */
+__rte_internal
+void *rte_uacce_queue_mmap(struct rte_uacce_qcontex *qctx, enum rte_uacce_qfrt qfrt);
+
+/**
+ * Unmap queue file region.
+ *
+ * @param qctx
+ * Pointer to queue context, which allocated by @see rte_uacce_alloc_queue.
+ * @param qfrt
+ * The queue file region type. Must be RTE_UACCE_QFRT_MMIO or
+ * RTE_UACCE_QFRT_DUS.
+ *
+ * @return
+ * Non-NULL on success. Otherwise NULL is returned.
+ */
+__rte_internal
+void rte_uacce_queue_unmap(struct rte_uacce_qcontex *qctx, enum rte_uacce_qfrt qfrt);
+
+/**
+ * Register a UACCE driver.
+ *
+ * @param driver
+ * A pointer to a rte_uacce_driver structure describing the driver to be
+ * registered.
+ */
+__rte_internal
+void rte_uacce_register(struct rte_uacce_driver *driver);
+
+/**
+ * Unregister a UACCE driver.
+ *
+ * @param driver
+ * A pointer to a rte_uacce_driver structure describing the driver to be
+ * unregistered.
+ */
+__rte_internal
+void rte_uacce_unregister(struct rte_uacce_driver *driver);
+
+/**
+ * Helper for UACCE device registration from driver instance.
+ */
+#define RTE_PMD_REGISTER_UACCE(nm, uacce_drv) \
+ RTE_INIT(uacceinitfn_ ##nm) \
+ {\
+ (uacce_drv).driver.name = RTE_STR(nm);\
+ rte_uacce_register(&uacce_drv); \
+ } \
+ RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* BUS_UACCE_DRIVER_H */
diff --git a/drivers/bus/uacce/meson.build b/drivers/bus/uacce/meson.build
new file mode 100644
index 0000000000..b48d6db11a
--- /dev/null
+++ b/drivers/bus/uacce/meson.build
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2023 HiSilicon Limited.
+
+if not is_linux
+ build = false
+ reason = 'only supported on Linux'
+endif
+
+sources = files('uacce.c')
+driver_sdk_headers += files('bus_uacce_driver.h')
+
+deps += ['kvargs']
diff --git a/drivers/bus/uacce/uacce.c b/drivers/bus/uacce/uacce.c
new file mode 100644
index 0000000000..8e824c44df
--- /dev/null
+++ b/drivers/bus/uacce/uacce.c
@@ -0,0 +1,702 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2023 HiSilicon Limited
+ */
+
+#include <dirent.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+
+#include <rte_bitops.h>
+#include <rte_common.h>
+#include <rte_devargs.h>
+#include <rte_errno.h>
+#include <rte_log.h>
+#include <rte_kvargs.h>
+#include <bus_driver.h>
+
+#include "bus_uacce_driver.h"
+
+#define UACCE_BUS_CLASS_PATH "/sys/class/uacce"
+
+/* UACCE device flag of SVA. */
+#define UACCE_DEV_FLGA_SVA RTE_BIT32(0)
+
+/* Support -a uacce:device-name when start DPDK application. */
+#define UACCE_DEV_PREFIX "uacce:"
+
+/*
+ * Structure describing the UACCE bus.
+ */
+struct rte_uacce_bus {
+ struct rte_bus bus; /* Inherit the generic class. */
+ TAILQ_HEAD(, rte_uacce_device) device_list; /* List of devices. */
+ TAILQ_HEAD(, rte_uacce_driver) driver_list; /* List of drivers. */
+};
+
+/* Forward declaration of UACCE bus. */
+static struct rte_uacce_bus uacce_bus;
+
+enum uacce_params {
+ RTE_UACCE_PARAM_NAME,
+};
+
+static const char *const uacce_params_keys[] = {
+ [RTE_UACCE_PARAM_NAME] = "name",
+ NULL,
+};
+
+#define FOREACH_DEVICE_ON_UACCEBUS(p) \
+ RTE_TAILQ_FOREACH(p, &uacce_bus.device_list, next)
+#define FOREACH_DRIVER_ON_UACCEBUS(p) \
+ RTE_TAILQ_FOREACH(p, &uacce_bus.driver_list, next)
+
+extern int uacce_bus_logtype;
+#define UACCE_BUS_LOG(level, fmt, args...) \
+ rte_log(RTE_LOG_ ## level, uacce_bus_logtype, "uacce: " fmt "\n", \
+ ##args)
+#define UACCE_BUS_ERR(fmt, args...) UACCE_BUS_LOG(ERR, fmt, ##args)
+#define UACCE_BUS_WARN(fmt, args...) UACCE_BUS_LOG(WARNING, fmt, ##args)
+#define UACCE_BUS_INFO(fmt, args...) UACCE_BUS_LOG(INFO, fmt, ##args)
+#define UACCE_BUS_DEBUG(fmt, args...) UACCE_BUS_LOG(DEBUG, fmt, ##args)
+
+
+static struct rte_devargs *
+uacce_devargs_lookup(const char *dev_name)
+{
+ char name[RTE_UACCE_DEV_PATH_SIZE] = {0};
+ struct rte_devargs *devargs;
+
+ snprintf(name, sizeof(name), "%s%s", UACCE_DEV_PREFIX, dev_name);
+ RTE_EAL_DEVARGS_FOREACH("uacce", devargs) {
+ if (strcmp(devargs->name, name) == 0)
+ return devargs;
+ }
+
+ return NULL;
+}
+
+static bool
+uacce_ignore_device(const char *dev_name)
+{
+ struct rte_devargs *devargs = uacce_devargs_lookup(dev_name);
+
+ switch (uacce_bus.bus.conf.scan_mode) {
+ case RTE_BUS_SCAN_ALLOWLIST:
+ if (devargs && devargs->policy == RTE_DEV_ALLOWED)
+ return false;
+ break;
+ case RTE_BUS_SCAN_UNDEFINED:
+ case RTE_BUS_SCAN_BLOCKLIST:
+ if (devargs == NULL || devargs->policy != RTE_DEV_BLOCKED)
+ return false;
+ break;
+ }
+
+ return true;
+}
+
+/*
+ * Returns the number of bytes read (removed last newline) on success.
+ * Otherwise negative value is returned.
+ */
+static int
+uacce_read_attr(const char *dev_root, const char *attr, char *buf, uint32_t sz)
+{
+ char filename[PATH_MAX] = {0};
+ int ret;
+ int fd;
+ int i;
+
+ snprintf(filename, sizeof(filename), "%s/%s", dev_root, attr);
+ fd = open(filename, O_RDONLY, 0);
+ if (fd < 0) {
+ UACCE_BUS_ERR("failed to open %s", filename);
+ return -EIO;
+ }
+
+ ret = read(fd, buf, sz);
+ if (ret > 0) {
+ /* Remove the last new line character. */
+ for (i = ret - 1; i >= 0; i--) {
+ if (buf[i] == '\n') {
+ buf[i] = '\0';
+ ret--;
+ break;
+ }
+ }
+ }
+ if (ret <= 0) {
+ UACCE_BUS_ERR("failed to read %s", filename);
+ return -EIO;
+ }
+
+ close(fd);
+
+ return ret;
+}
+
+/* 0 on success. Otherwise negative value is returned. */
+static int
+uacce_read_attr_int(const char *dev_root, const char *attr, int *val)
+{
+ char buf[RTE_UACCE_ATTR_MAX_SIZE] = {0};
+ char *s = NULL;
+ int ret;
+
+ ret = uacce_read_attr(dev_root, attr, buf, sizeof(buf) - 1);
+ if (ret < 0)
+ return ret;
+
+ *val = strtol(buf, &s, 0);
+ if (s[0] != '\0') {
+ UACCE_BUS_ERR("read attr %s/%s expect an integer value", dev_root, attr);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* 0 on success. Otherwise negative value is returned. */
+static int
+uacce_read_attr_u32(const char *dev_root, const char *attr, uint32_t *val)
+{
+ char buf[RTE_UACCE_ATTR_MAX_SIZE] = {0};
+ char *s = NULL;
+ int ret;
+
+ ret = uacce_read_attr(dev_root, attr, buf, sizeof(buf) - 1);
+ if (ret < 0)
+ return ret;
+
+ *val = strtoul(buf, &s, 0);
+ if (s[0] != '\0') {
+ UACCE_BUS_ERR("read attr %s/%s expect an uint32 value", dev_root, attr);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+uacce_read_api(struct rte_uacce_device *dev)
+{
+ int ret = uacce_read_attr(dev->dev_root, "api", dev->api, sizeof(dev->api) - 1);
+ if (ret < 0)
+ return ret;
+ return 0;
+}
+
+static int
+uacce_read_algs(struct rte_uacce_device *dev)
+{
+ int ret = uacce_read_attr(dev->dev_root, "algorithms", dev->algs, sizeof(dev->algs) - 1);
+ if (ret < 0)
+ return ret;
+ return 0;
+}
+
+static int
+uacce_read_flags(struct rte_uacce_device *dev)
+{
+ return uacce_read_attr_u32(dev->dev_root, "flags", &dev->flags);
+}
+
+static void
+uacce_read_numa_node(struct rte_uacce_device *dev)
+{
+ int ret = uacce_read_attr_int(dev->dev_root, "device/numa_node", &dev->numa_node);
+ if (ret != 0) {
+ UACCE_BUS_WARN("read attr numa_node failed! set to default");
+ dev->numa_node = -1;
+ }
+}
+
+static int
+uacce_read_qfrt_sz(struct rte_uacce_device *dev)
+{
+ int ret = uacce_read_attr_u32(dev->dev_root, "region_mmio_size",
+ &dev->qfrt_sz[RTE_UACCE_QFRT_MMIO]);
+ if (ret != 0)
+ return ret;
+ return uacce_read_attr_u32(dev->dev_root, "region_dus_size",
+ &dev->qfrt_sz[RTE_UACCE_QFRT_DUS]);
+}
+
+static int
+uacce_verify(struct rte_uacce_device *dev)
+{
+ if (!(dev->flags & UACCE_DEV_FLGA_SVA)) {
+ UACCE_BUS_WARN("device %s don't support SVA, skip it!", dev->name);
+ return 1; /* >0 will skip this device. */
+ }
+
+ return 0;
+}
+
+/*
+ * Scan one UACCE sysfs entry, and fill the devices list from it.
+ * It reads api/algs/flags/numa_node/region-size (please refer Linux kernel:
+ * Documentation/ABI/testing/sysfs-driver-uacce) and stores them for later
+ * device-driver matching, driver init...
+ */
+static int
+uacce_scan_one(const char *dev_name)
+{
+ struct rte_uacce_device *dev = NULL;
+ int ret;
+
+ dev = calloc(1, sizeof(*dev));
+ if (!dev)
+ return -ENOMEM;
+
+ dev->device.bus = &uacce_bus.bus;
+ dev->device.name = dev->name;
+ dev->device.devargs = uacce_devargs_lookup(dev_name);
+ snprintf(dev->name, sizeof(dev->name), "%s", dev_name);
+ snprintf(dev->dev_root, sizeof(dev->dev_root), "%s/%s",
+ UACCE_BUS_CLASS_PATH, dev_name);
+ snprintf(dev->cdev_path, sizeof(dev->cdev_path), "/dev/%s", dev_name);
+
+ ret = uacce_read_api(dev);
+ if (ret != 0)
+ goto err;
+ ret = uacce_read_algs(dev);
+ if (ret != 0)
+ goto err;
+ ret = uacce_read_flags(dev);
+ if (ret != 0)
+ goto err;
+ uacce_read_numa_node(dev);
+ ret = uacce_read_qfrt_sz(dev);
+ if (ret != 0)
+ goto err;
+
+ ret = uacce_verify(dev);
+ if (ret != 0)
+ goto err;
+
+ TAILQ_INSERT_TAIL(&uacce_bus.device_list, dev, next);
+ return 0;
+
+err:
+ free(dev);
+ return ret;
+}
+
+static int
+uacce_scan(void)
+{
+ struct dirent *e;
+ DIR *dir;
+
+ dir = opendir(UACCE_BUS_CLASS_PATH);
+ if (dir == NULL) {
+ UACCE_BUS_LOG(INFO, "open %s failed!", UACCE_BUS_CLASS_PATH);
+ return 0;
+ }
+
+ while ((e = readdir(dir)) != NULL) {
+ if (e->d_name[0] == '.')
+ continue;
+
+ if (strlen(e->d_name) >= RTE_DEV_NAME_MAX_LEN) {
+ UACCE_BUS_LOG(WARNING, "uacce device name %s too long, skip it!",
+ e->d_name);
+ continue;
+ }
+
+ if (uacce_ignore_device(e->d_name))
+ continue;
+
+ if (uacce_scan_one(e->d_name) < 0)
+ goto error;
+ }
+ closedir(dir);
+ return 0;
+
+error:
+ closedir(dir);
+ return -1;
+}
+
+static bool
+uacce_match(const struct rte_uacce_driver *dr, const struct rte_uacce_device *dev)
+{
+ const struct rte_uacce_id *id_table;
+ uint32_t len;
+ char *map;
+
+ for (id_table = dr->id_table; id_table->dev_api != NULL; id_table++) {
+ if (strcmp(id_table->dev_api, dev->api) != 0)
+ continue;
+
+ if (id_table->dev_alg == NULL)
+ return 1;
+
+ /* The dev->algs's algrothims is separated by new line, for
+ * example: dev->algs could be: aaa\nbbbb\ncc, which has three
+ * algorithms: aaa, bbbb and cc.
+ * The id_table->dev_alg should be a single algrithm, e.g. bbbb.
+ */
+ map = strstr(dev->algs, id_table->dev_alg);
+ if (map == NULL)
+ continue;
+ if (map != dev->algs && map[-1] != '\n')
+ continue;
+ len = strlen(id_table->dev_alg);
+ if (map[len] != '\0' && map[len] != '\n')
+ continue;
+
+ return 1;
+ }
+
+ return 0;
+}
+
+static int
+uacce_probe_one_driver(struct rte_uacce_driver *dr, struct rte_uacce_device *dev)
+{
+ const char *dev_name = dev->name;
+ bool already_probed;
+ int ret;
+
+ if (!uacce_match(dr, dev))
+ /* Match of device and driver failed */
+ return 1;
+
+ already_probed = rte_dev_is_probed(&dev->device);
+ if (already_probed) {
+ UACCE_BUS_INFO("device %s is already probed", dev_name);
+ return -EEXIST;
+ }
+
+ UACCE_BUS_DEBUG("probe device %s using driver %s", dev_name, dr->driver.name);
+
+ ret = dr->probe(dr, dev);
+ if (ret != 0) {
+ UACCE_BUS_ERR("probe device %s with driver %s failed %d",
+ dev_name, dr->driver.name, ret);
+ } else {
+ dev->device.driver = &dr->driver;
+ dev->driver = dr;
+ UACCE_BUS_DEBUG("probe device %s with driver %s success",
+ dev_name, dr->driver.name);
+ }
+
+ return ret;
+}
+
+static int
+uacce_probe_all_drivers(struct rte_uacce_device *dev)
+{
+ struct rte_uacce_driver *dr = NULL;
+ int rc = 0;
+
+ FOREACH_DRIVER_ON_UACCEBUS(dr) {
+ rc = uacce_probe_one_driver(dr, dev);
+ if (rc < 0)
+ /* negative value is an error */
+ return rc;
+ if (rc > 0)
+ /* positive value means driver doesn't support it */
+ continue;
+ return 0;
+ }
+ return 1;
+}
+
+static int
+uacce_probe(void)
+{
+ struct rte_uacce_device *dev = NULL;
+ size_t probed = 0, failed = 0;
+ int ret = 0;
+
+ FOREACH_DEVICE_ON_UACCEBUS(dev) {
+ probed++;
+
+ ret = uacce_probe_all_drivers(dev);
+ if (ret < 0) {
+ UACCE_BUS_LOG(ERR, "Requested device %s cannot be used",
+ dev->name);
+ rte_errno = errno;
+ failed++;
+ }
+ }
+
+ return (probed && probed == failed) ? -1 : 0;
+}
+
+static int
+uacce_cleanup(void)
+{
+ struct rte_uacce_device *dev, *tmp_dev;
+ int error = 0;
+
+ RTE_TAILQ_FOREACH_SAFE(dev, &uacce_bus.device_list, next, tmp_dev) {
+ struct rte_uacce_driver *dr = dev->driver;
+ int ret = 0;
+
+ if (dr == NULL || dr->remove == NULL)
+ goto free;
+
+ ret = dr->remove(dev);
+ if (ret < 0) {
+ rte_errno = errno;
+ error = -1;
+ }
+ dev->driver = NULL;
+ dev->device.driver = NULL;
+
+free:
+ memset(dev, 0, sizeof(*dev));
+ free(dev);
+ }
+
+ return error;
+}
+
+static int
+uacce_plug(struct rte_device *dev)
+{
+ return uacce_probe_all_drivers(RTE_DEV_TO_UACCE_DEV(dev));
+}
+
+static int
+uacce_detach_dev(struct rte_uacce_device *dev)
+{
+ struct rte_uacce_driver *dr;
+ int ret = 0;
+
+ dr = dev->driver;
+
+ UACCE_BUS_DEBUG("detach device %s using driver: %s", dev->device.name, dr->driver.name);
+
+ if (dr->remove) {
+ ret = dr->remove(dev);
+ if (ret < 0)
+ return ret;
+ }
+
+ dev->driver = NULL;
+ dev->device.driver = NULL;
+
+ return 0;
+}
+
+static int
+uacce_unplug(struct rte_device *dev)
+{
+ struct rte_uacce_device *uacce_dev;
+ int ret;
+
+ uacce_dev = RTE_DEV_TO_UACCE_DEV(dev);
+ ret = uacce_detach_dev(uacce_dev);
+ if (ret == 0) {
+ TAILQ_REMOVE(&uacce_bus.device_list, uacce_dev, next);
+ rte_devargs_remove(dev->devargs);
+ free(uacce_dev);
+ }
+
+ return ret;
+}
+
+static struct rte_device *
+uacce_find_device(const struct rte_device *start, rte_dev_cmp_t cmp, const void *data)
+{
+ const struct rte_uacce_device *uacce_start;
+ struct rte_uacce_device *uacce_dev;
+
+ if (start != NULL) {
+ uacce_start = RTE_DEV_TO_UACCE_DEV_CONST(start);
+ uacce_dev = TAILQ_NEXT(uacce_start, next);
+ } else {
+ uacce_dev = TAILQ_FIRST(&uacce_bus.device_list);
+ }
+
+ while (uacce_dev != NULL) {
+ if (cmp(&uacce_dev->device, data) == 0)
+ return &uacce_dev->device;
+ uacce_dev = TAILQ_NEXT(uacce_dev, next);
+ }
+
+ return NULL;
+}
+
+static int
+uacce_parse(const char *name, void *addr)
+{
+ const char **out = addr;
+ int ret;
+
+ ret = strncmp(name, UACCE_DEV_PREFIX, strlen(UACCE_DEV_PREFIX));
+
+ if (ret == 0 && addr)
+ *out = name;
+
+ return ret;
+}
+
+static int
+uacce_dev_match(const struct rte_device *dev, const void *_kvlist)
+{
+ const char *key = uacce_params_keys[RTE_UACCE_PARAM_NAME];
+ const struct rte_kvargs *kvlist = _kvlist;
+ const char *name;
+
+ /* no kvlist arg, all devices match. */
+ if (kvlist == NULL)
+ return 0;
+
+ /* if key is present in kvlist and does not match, filter device. */
+ name = rte_kvargs_get(kvlist, key);
+ if (name != NULL && strcmp(name, dev->name))
+ return -1;
+
+ return 0;
+}
+
+static void *
+uacce_dev_iterate(const void *start, const char *str,
+ const struct rte_dev_iterator *it __rte_unused)
+{
+ rte_bus_find_device_t find_device;
+ struct rte_kvargs *kvargs = NULL;
+ struct rte_device *dev;
+
+ if (str != NULL) {
+ kvargs = rte_kvargs_parse(str, uacce_params_keys);
+ if (kvargs == NULL) {
+ UACCE_BUS_ERR("cannot parse argument list %s", str);
+ return NULL;
+ }
+ }
+ find_device = uacce_bus.bus.find_device;
+ dev = find_device(start, uacce_dev_match, kvargs);
+ rte_kvargs_free(kvargs);
+ return dev;
+}
+
+int
+rte_uacce_avail_queues(struct rte_uacce_device *dev)
+{
+ int avails = 0;
+ int ret;
+
+ ret = uacce_read_attr_int(dev->dev_root, "available_instances", &avails);
+ if (ret == 0)
+ ret = avails;
+
+ return ret;
+}
+
+int
+rte_uacce_queue_alloc(struct rte_uacce_device *dev, struct rte_uacce_qcontex *qctx)
+{
+ memset(qctx, 0, sizeof(*qctx));
+
+ qctx->fd = open(dev->cdev_path, O_RDWR | O_CLOEXEC);
+ if (qctx->fd >= 0) {
+ qctx->dev = dev;
+ return 0;
+ }
+
+ return -EIO;
+}
+
+void
+rte_uacce_queue_free(struct rte_uacce_qcontex *qctx)
+{
+ if (qctx->fd >= 0)
+ close(qctx->fd);
+ memset(qctx, 0, sizeof(*qctx));
+ qctx->fd = -1;
+}
+
+int
+rte_uacce_queue_start(struct rte_uacce_qcontex *qctx)
+{
+#define UACCE_CMD_START_Q _IO('W', 0)
+ return ioctl(qctx->fd, UACCE_CMD_START_Q);
+}
+
+int
+rte_uacce_queue_ioctl(struct rte_uacce_qcontex *qctx, unsigned long cmd, void *arg)
+{
+ if (arg == NULL)
+ return ioctl(qctx->fd, cmd);
+
+ return ioctl(qctx->fd, cmd, arg);
+}
+
+void *
+rte_uacce_queue_mmap(struct rte_uacce_qcontex *qctx, enum rte_uacce_qfrt qfrt)
+{
+ size_t size = qctx->dev->qfrt_sz[qfrt];
+ off_t off = qfrt * getpagesize();
+ void *addr;
+
+ if (size == 0 || qctx->qfrt_base[qfrt] != NULL) {
+ UACCE_BUS_ERR("failed to mmap for %s, size is zero or already mmapped!",
+ qctx->dev->name);
+ return NULL;
+ }
+
+ addr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, qctx->fd, off);
+ if (addr == MAP_FAILED) {
+ UACCE_BUS_ERR("failed to mmap for %s, qfrt %d err %d!",
+ qctx->dev->name, qfrt, -errno);
+ return NULL;
+ }
+ qctx->qfrt_base[qfrt] = addr;
+
+ return addr;
+}
+
+void
+rte_uacce_queue_unmap(struct rte_uacce_qcontex *qctx, enum rte_uacce_qfrt qfrt)
+{
+ if (qctx->qfrt_base[qfrt] != NULL) {
+ munmap(qctx->qfrt_base[qfrt], qctx->dev->qfrt_sz[qfrt]);
+ qctx->qfrt_base[qfrt] = NULL;
+ }
+}
+
+void
+rte_uacce_register(struct rte_uacce_driver *driver)
+{
+ TAILQ_INSERT_TAIL(&uacce_bus.driver_list, driver, next);
+ driver->bus = &uacce_bus;
+}
+
+void
+rte_uacce_unregister(struct rte_uacce_driver *driver)
+{
+ TAILQ_REMOVE(&uacce_bus.driver_list, driver, next);
+ driver->bus = NULL;
+}
+
+static struct rte_uacce_bus uacce_bus = {
+ .bus = {
+ .scan = uacce_scan,
+ .probe = uacce_probe,
+ .cleanup = uacce_cleanup,
+ .plug = uacce_plug,
+ .unplug = uacce_unplug,
+ .find_device = uacce_find_device,
+ .parse = uacce_parse,
+ .dev_iterate = uacce_dev_iterate,
+ },
+ .device_list = TAILQ_HEAD_INITIALIZER(uacce_bus.device_list),
+ .driver_list = TAILQ_HEAD_INITIALIZER(uacce_bus.driver_list),
+};
+
+RTE_REGISTER_BUS(uacce, uacce_bus.bus);
+RTE_LOG_REGISTER_DEFAULT(uacce_bus_logtype, NOTICE);
diff --git a/drivers/bus/uacce/version.map b/drivers/bus/uacce/version.map
new file mode 100644
index 0000000000..533b2ea0d8
--- /dev/null
+++ b/drivers/bus/uacce/version.map
@@ -0,0 +1,15 @@
+INTERNAL {
+ global:
+
+ rte_uacce_avail_queues;
+ rte_uacce_queue_alloc;
+ rte_uacce_queue_free;
+ rte_uacce_queue_ioctl;
+ rte_uacce_queue_mmap;
+ rte_uacce_queue_start;
+ rte_uacce_queue_unmap;
+ rte_uacce_register;
+ rte_uacce_unregister;
+
+ local: *;
+};
--
2.17.1
^ permalink raw reply [relevance 2%]
* [PATCH v5 1/3] net/octeon_ep: optimize Rx and Tx routines
2023-12-07 6:49 3% ` [PATCH v4 " pbhagavatula
@ 2023-12-11 13:43 3% ` pbhagavatula
0 siblings, 0 replies; 200+ results
From: pbhagavatula @ 2023-12-11 13:43 UTC (permalink / raw)
To: jerinj, Vamsi Attunuru; +Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Preset rearm data to avoid writing multiple fields in fastpath,
Increase maximum outstanding Tx instructions from 128 to 256.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
v5 Changes:
- Make release notes more verbose.
v4 Changes:
- Fix checkpatch.
- Update release notes.
v3 Chnages:
- Add more comments to the code.
- Re-enable 32b build to prevent ABI break.
v2 Changes:
- Skip compiling for 32b x86 targets.
doc/guides/rel_notes/release_24_03.rst | 5 +++++
drivers/net/octeon_ep/cnxk_ep_rx.c | 12 ++++++++----
drivers/net/octeon_ep/otx_ep_common.h | 3 +++
drivers/net/octeon_ep/otx_ep_rxtx.c | 27 ++++++++++++++++++++++++++
drivers/net/octeon_ep/otx_ep_rxtx.h | 2 +-
5 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/doc/guides/rel_notes/release_24_03.rst b/doc/guides/rel_notes/release_24_03.rst
index 6f8ad27808..2265814c55 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Updated Marvell Octeon ep driver.**
+
+ * Optimize mbuf rearm sequence.
+ * Updated Tx queue mbuf free thresholds from 128 to 256 for better performance.
+
Removed Items
-------------
diff --git a/drivers/net/octeon_ep/cnxk_ep_rx.c b/drivers/net/octeon_ep/cnxk_ep_rx.c
index 74f0011283..75bb7225d2 100644
--- a/drivers/net/octeon_ep/cnxk_ep_rx.c
+++ b/drivers/net/octeon_ep/cnxk_ep_rx.c
@@ -93,7 +93,7 @@ cnxk_ep_check_rx_pkts(struct otx_ep_droq *droq)
new_pkts = val - droq->pkts_sent_ism_prev;
droq->pkts_sent_ism_prev = val;
- if (val > (uint32_t)(1 << 31)) {
+ if (val > RTE_BIT32(31)) {
/* Only subtract the packet count in the HW counter
* when count above halfway to saturation.
*/
@@ -128,7 +128,6 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
{
struct rte_mbuf **recv_buf_list = droq->recv_buf_list;
uint32_t bytes_rsvd = 0, read_idx = droq->read_idx;
- uint16_t port_id = droq->otx_ep_dev->port_id;
uint16_t nb_desc = droq->nb_desc;
uint16_t pkts;
@@ -137,14 +136,19 @@ cnxk_ep_process_pkts_scalar(struct rte_mbuf **rx_pkts, struct otx_ep_droq *droq,
struct rte_mbuf *mbuf;
uint16_t pkt_len;
+ rte_prefetch0(recv_buf_list[otx_ep_incr_index(read_idx, 2, nb_desc)]);
+ rte_prefetch0(rte_pktmbuf_mtod(recv_buf_list[otx_ep_incr_index(read_idx,
+ 2, nb_desc)],
+ void *));
+
mbuf = recv_buf_list[read_idx];
info = rte_pktmbuf_mtod(mbuf, struct otx_ep_droq_info *);
read_idx = otx_ep_incr_index(read_idx, 1, nb_desc);
pkt_len = rte_bswap16(info->length >> 48);
- mbuf->data_off += OTX_EP_INFO_SIZE;
mbuf->pkt_len = pkt_len;
mbuf->data_len = pkt_len;
- mbuf->port = port_id;
+
+ *(uint64_t *)&mbuf->rearm_data = droq->rearm_data;
rx_pkts[pkts] = mbuf;
bytes_rsvd += pkt_len;
}
diff --git a/drivers/net/octeon_ep/otx_ep_common.h b/drivers/net/octeon_ep/otx_ep_common.h
index 82e57520d3..299b5122d8 100644
--- a/drivers/net/octeon_ep/otx_ep_common.h
+++ b/drivers/net/octeon_ep/otx_ep_common.h
@@ -365,6 +365,9 @@ struct otx_ep_droq {
/* receive buffer list contains mbuf ptr list */
struct rte_mbuf **recv_buf_list;
+ /* Packet re-arm data. */
+ uint64_t rearm_data;
+
/* Packets pending to be processed */
uint64_t pkts_pending;
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c b/drivers/net/octeon_ep/otx_ep_rxtx.c
index c421ef0a1c..40c4a16a38 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -284,6 +284,32 @@ otx_ep_droq_setup_ring_buffers(struct otx_ep_droq *droq)
return 0;
}
+static inline uint64_t
+otx_ep_set_rearm_data(struct otx_ep_device *otx_ep)
+{
+ uint16_t port_id = otx_ep->port_id;
+ struct rte_mbuf mb_def;
+ uint64_t *tmp;
+
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, data_off) % 8 != 0);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, refcnt) - offsetof(struct rte_mbuf, data_off) !=
+ 2);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, nb_segs) - offsetof(struct rte_mbuf, data_off) !=
+ 4);
+ RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, port) - offsetof(struct rte_mbuf, data_off) !=
+ 6);
+ mb_def.nb_segs = 1;
+ mb_def.data_off = RTE_PKTMBUF_HEADROOM + OTX_EP_INFO_SIZE;
+ mb_def.port = port_id;
+ rte_mbuf_refcnt_set(&mb_def, 1);
+
+ /* Prevent compiler reordering: rearm_data covers previous fields */
+ rte_compiler_barrier();
+ tmp = (uint64_t *)&mb_def.rearm_data;
+
+ return *tmp;
+}
+
/* OQ initialization */
static int
otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
@@ -340,6 +366,7 @@ otx_ep_init_droq(struct otx_ep_device *otx_ep, uint32_t q_no,
goto init_droq_fail;
droq->refill_threshold = c_refill_threshold;
+ droq->rearm_data = otx_ep_set_rearm_data(otx_ep);
/* Set up OQ registers */
ret = otx_ep->fn_list.setup_oq_regs(otx_ep, q_no);
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.h b/drivers/net/octeon_ep/otx_ep_rxtx.h
index cb68ef3b41..b159c32cae 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.h
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.h
@@ -17,7 +17,7 @@
#define OTX_EP_FSZ 28
#define OTX2_EP_FSZ 24
-#define OTX_EP_MAX_INSTR 128
+#define OTX_EP_MAX_INSTR 256
/* SDP_LENGTH_S specifies packet length and is of 8-byte size */
#define OTX_EP_INFO_SIZE 8
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH 1/2] eal: fix constraints on stdatomic API
@ 2023-12-15 7:17 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2023-12-15 7:17 UTC (permalink / raw)
To: Jie Hai
Cc: dev, Morten Brørup, Konstantin Ananyev, lihuisong,
fengchengwen, liudongdong3
On Fri, Dec 15, 2023 at 10:47:36AM +0800, Jie Hai wrote:
> On 2023/12/12 2:53, Tyler Retzlaff wrote:
> >On Mon, Dec 11, 2023 at 03:39:03PM +0800, Jie Hai wrote:
> >>The first parameter of rte_atomic_exchange_explicit() must be a
> >>pointer to _Atomic type. If run command "meson setup --werror
> >>-Denable_stdatomic=true build && ninja -C build", error will occur.
> >>Thia patch fixes it.
> >>
> >>Fixes: 1ec6a845b5cb ("eal: use stdatomic API in public headers")
> >>Cc: stable@dpdk.org
> >>
> >>Signed-off-by: Jie Hai <haijie1@huawei.com>
> >>---
> >> app/test/test_atomic.c | 6 +++---
> >> lib/eal/include/generic/rte_atomic.h | 12 ++++++------
> >> 2 files changed, 9 insertions(+), 9 deletions(-)
> >>
> >>diff --git a/app/test/test_atomic.c b/app/test/test_atomic.c
> >>index db07159e81ab..c3cb3ae0ea57 100644
> >>--- a/app/test/test_atomic.c
> >>+++ b/app/test/test_atomic.c
> >>@@ -347,9 +347,9 @@ typedef union {
> >> const uint8_t CRC8_POLY = 0x91;
> >> uint8_t crc8_table[256];
> >>-volatile uint16_t token16;
> >>-volatile uint32_t token32;
> >>-volatile uint64_t token64;
> >>+volatile RTE_ATOMIC(uint16_t) token16;
> >>+volatile RTE_ATOMIC(uint32_t) token32;
> >>+volatile RTE_ATOMIC(uint64_t) token64;
> >
> >subject to my comment below, volatile qualification can be removed.
> >
> >> static void
> >> build_crc8_table(void)
> >>diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
> >>index 0e639dad76a4..38c3b41f9c68 100644
> >>--- a/lib/eal/include/generic/rte_atomic.h
> >>+++ b/lib/eal/include/generic/rte_atomic.h
> >>@@ -207,11 +207,11 @@ rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
> >> * The original value at that location
> >> */
> >> static inline uint16_t
> >>-rte_atomic16_exchange(volatile uint16_t *dst, uint16_t val);
> >>+rte_atomic16_exchange(volatile RTE_ATOMIC(uint16_t) *dst, uint16_t val);
> >
> >the existing rte_atomicNN (the old non-standard ones) are deprecated and will
> >be eventually removed so there isn't a lot of value in churning their
> >signatures to wrap the rte_stdatomic macros.
> >
> >the right thing to do here to just change the calling code to use the generic
> >rte_stdatomic macros directly so we can eventually remove
> >rte_atomicNN_xxx.
> >
> >ty
> >
> Hi, Tyler Retzlaff,
>
> Thank you for your review.
>
> As I understand it, this code is used to test the API
> rte_atomXXX_change, and the call here should not be modified.
>
> Since the current problem affects compilation, I think it can be
> solved first.
okay, i understand the motivation now and see what you mean.
first, sorry for the trouble i did not expect anyone to start using this
option until i had completed full conversion of the tree. drivers and
tests are still on my todo list.
for now would it be reasonable to just stop building this test when
enable_stdatomic=true? the api are still going to be tested by the ci
and builds that do not enable the option.
as for changing the signatures of the existing api i don't strictly
object since the RTE_ATOMIC() macro expands empty for the non stdatomic
builds so isn't technically an api or abi change. but there may still be
some resistance to merging regardless.
wonder if anyone else has any suggestions here?
ty
>
> What do you think?
>
> Thanks,
> Jie Hai
> >.
^ permalink raw reply [relevance 3%]
* [RFC] net/tap: remove kernel side RSS via BPF
@ 2023-12-15 16:31 1% Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-12-15 16:31 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The support of BPF in TAP device was problematic since the
API to BPF in kernel is not stable and keeps changing.
Since the RTE_FLOW_ACTION_TYPE_RSS is the only part using this
remove support for kernel side flow remapping.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/nics/tap.rst | 74 --
drivers/net/tap/bpf/Makefile | 19 -
drivers/net/tap/bpf/bpf_api.h | 276 ----
drivers/net/tap/bpf/bpf_elf.h | 53 -
| 86 --
drivers/net/tap/bpf/tap_bpf_program.c | 255 ----
drivers/net/tap/meson.build | 5 -
drivers/net/tap/rte_eth_tap.h | 5 +-
drivers/net/tap/tap_bpf.h | 121 --
drivers/net/tap/tap_bpf_api.c | 190 ---
drivers/net/tap/tap_bpf_insns.h | 1743 -------------------------
drivers/net/tap/tap_flow.c | 496 +------
drivers/net/tap/tap_flow.h | 12 -
drivers/net/tap/tap_tcmsgs.h | 3 -
14 files changed, 4 insertions(+), 3334 deletions(-)
delete mode 100644 drivers/net/tap/bpf/Makefile
delete mode 100644 drivers/net/tap/bpf/bpf_api.h
delete mode 100644 drivers/net/tap/bpf/bpf_elf.h
delete mode 100644 drivers/net/tap/bpf/bpf_extract.py
delete mode 100644 drivers/net/tap/bpf/tap_bpf_program.c
delete mode 100644 drivers/net/tap/tap_bpf.h
delete mode 100644 drivers/net/tap/tap_bpf_api.c
delete mode 100644 drivers/net/tap/tap_bpf_insns.h
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index d4f45c02a1e5..5779f5d08e31 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -123,7 +123,6 @@ Supported actions:
- DROP
- QUEUE
- PASSTHRU
-- RSS (requires kernel 4.9)
It is generally not possible to provide a "last" item. However, if the "last"
item, once masked, is identical to the masked spec, then it is supported.
@@ -153,10 +152,6 @@ Drop UDP packets in vlan 3::
testpmd> flow create 0 priority 3 ingress pattern eth / vlan vid is 3 / \
ipv4 proto is 17 / end actions drop / end
-Distribute IPv4 TCP packets using RSS to a given MAC address over queues 0-3::
-
- testpmd> flow create 0 priority 4 ingress pattern eth dst is 0a:0b:0c:0d:0e:0f \
- / ipv4 / tcp / end actions rss queues 0 1 2 3 end / end
Multi-process sharing
---------------------
@@ -227,80 +222,11 @@ size of the packets after you stop the traffic. Use pktgen ``help``
command to see a list of all commands. You can also use the ``-f`` option to
load commands at startup in command line or Lua script in pktgen.
-RSS specifics
--------------
-Packet distribution in TAP is done by the kernel which has a default
-distribution. This feature is adding RSS distribution based on eBPF code.
-The default eBPF code calculates RSS hash based on Toeplitz algorithm for
-a fixed RSS key. It is calculated on fixed packet offsets. For IPv4 and IPv6 it
-is calculated over src/dst addresses (8 or 32 bytes for IPv4 or IPv6
-respectively) and src/dst TCP/UDP ports (4 bytes).
-
-The RSS algorithm is written in file ``tap_bpf_program.c`` which
-does not take part in TAP PMD compilation. Instead this file is compiled
-in advance to eBPF object file. The eBPF object file is then parsed and
-translated into eBPF byte code in the format of C arrays of eBPF
-instructions. The C array of eBPF instructions is part of TAP PMD tree and
-is taking part in TAP PMD compilation. At run time the C arrays are uploaded to
-the kernel via BPF system calls and the RSS hash is calculated by the
-kernel.
-
-It is possible to support different RSS hash algorithms by updating file
-``tap_bpf_program.c`` In order to add a new RSS hash algorithm follow these
-steps:
-
-#. Write the new RSS implementation in file ``tap_bpf_program.c``
-
- BPF programs which are uploaded to the kernel correspond to
- C functions under different ELF sections.
-
-#. Install ``LLVM`` library and ``clang`` compiler versions 3.7 and above
-
-#. Use make to compile `tap_bpf_program.c`` via ``LLVM`` into an object file
- and extract the resulting instructions into ``tap_bpf_insn.h``::
-
- cd bpf; make
-
-#. Recompile the TAP PMD.
-
-The C arrays are uploaded to the kernel using BPF system calls.
-
-``tc`` (traffic control) is a well known user space utility program used to
-configure the Linux kernel packet scheduler. It is usually packaged as
-part of the ``iproute2`` package.
-Since commit 11c39b5e9 ("tc: add eBPF support to f_bpf") ``tc`` can be used
-to uploads eBPF code to the kernel and can be patched in order to print the
-C arrays of eBPF instructions just before calling the BPF system call.
-Please refer to ``iproute2`` package file ``lib/bpf.c`` function
-``bpf_prog_load()``.
-
-An example utility for eBPF instruction generation in the format of C arrays will
-be added in next releases
-
-TAP reports on supported RSS functions as part of dev_infos_get callback:
-``RTE_ETH_RSS_IP``, ``RTE_ETH_RSS_UDP`` and ``RTE_ETH_RSS_TCP``.
-**Known limitation:** TAP supports all of the above hash functions together
-and not in partial combinations.
Systems supporting flow API
---------------------------
- "tc flower" classifier requires linux kernel above 4.2
-- eBPF/RSS requires linux kernel above 4.9
-
-+--------------------+-----------------------+
-| RH7.3 | No flow rule support |
-+--------------------+-----------------------+
-| RH7.4 | No RSS action support |
-+--------------------+-----------------------+
-| RH7.5 | No RSS action support |
-+--------------------+-----------------------+
-| SLES 15, | No limitation |
-| kernel 4.12 | |
-+--------------------+-----------------------+
-| Azure Ubuntu 16.04,| No limitation |
-| kernel 4.13 | |
-+--------------------+-----------------------+
Limitations
-----------
diff --git a/drivers/net/tap/bpf/Makefile b/drivers/net/tap/bpf/Makefile
deleted file mode 100644
index 9efeeb1bc704..000000000000
--- a/drivers/net/tap/bpf/Makefile
+++ /dev/null
@@ -1,19 +0,0 @@
-# SPDX-License-Identifier: BSD-3-Clause
-# This file is not built as part of normal DPDK build.
-# It is used to generate the eBPF code for TAP RSS.
-
-CLANG=clang
-CLANG_OPTS=-O2
-TARGET=../tap_bpf_insns.h
-
-all: $(TARGET)
-
-clean:
- rm tap_bpf_program.o $(TARGET)
-
-tap_bpf_program.o: tap_bpf_program.c
- $(CLANG) $(CLANG_OPTS) -emit-llvm -c $< -o - | \
- llc -march=bpf -filetype=obj -o $@
-
-$(TARGET): tap_bpf_program.o
- python3 bpf_extract.py -stap_bpf_program.c -o $@ $<
diff --git a/drivers/net/tap/bpf/bpf_api.h b/drivers/net/tap/bpf/bpf_api.h
deleted file mode 100644
index 2638a8a4ac9a..000000000000
--- a/drivers/net/tap/bpf/bpf_api.h
+++ /dev/null
@@ -1,276 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
-
-#ifndef __BPF_API__
-#define __BPF_API__
-
-/* Note:
- *
- * This file can be included into eBPF kernel programs. It contains
- * a couple of useful helper functions, map/section ABI (bpf_elf.h),
- * misc macros and some eBPF specific LLVM built-ins.
- */
-
-#include <stdint.h>
-
-#include <linux/pkt_cls.h>
-#include <linux/bpf.h>
-#include <linux/filter.h>
-
-#include <asm/byteorder.h>
-
-#include "bpf_elf.h"
-
-/** libbpf pin type. */
-enum libbpf_pin_type {
- LIBBPF_PIN_NONE,
- /* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
- LIBBPF_PIN_BY_NAME,
-};
-
-/** Type helper macros. */
-
-#define __uint(name, val) int (*name)[val]
-#define __type(name, val) typeof(val) *name
-#define __array(name, val) typeof(val) *name[]
-
-/** Misc macros. */
-
-#ifndef __stringify
-# define __stringify(X) #X
-#endif
-
-#ifndef __maybe_unused
-# define __maybe_unused __attribute__((__unused__))
-#endif
-
-#ifndef offsetof
-# define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
-#endif
-
-#ifndef likely
-# define likely(X) __builtin_expect(!!(X), 1)
-#endif
-
-#ifndef unlikely
-# define unlikely(X) __builtin_expect(!!(X), 0)
-#endif
-
-#ifndef htons
-# define htons(X) __constant_htons((X))
-#endif
-
-#ifndef ntohs
-# define ntohs(X) __constant_ntohs((X))
-#endif
-
-#ifndef htonl
-# define htonl(X) __constant_htonl((X))
-#endif
-
-#ifndef ntohl
-# define ntohl(X) __constant_ntohl((X))
-#endif
-
-#ifndef __inline__
-# define __inline__ __attribute__((always_inline))
-#endif
-
-/** Section helper macros. */
-
-#ifndef __section
-# define __section(NAME) \
- __attribute__((section(NAME), used))
-#endif
-
-#ifndef __section_tail
-# define __section_tail(ID, KEY) \
- __section(__stringify(ID) "/" __stringify(KEY))
-#endif
-
-#ifndef __section_xdp_entry
-# define __section_xdp_entry \
- __section(ELF_SECTION_PROG)
-#endif
-
-#ifndef __section_cls_entry
-# define __section_cls_entry \
- __section(ELF_SECTION_CLASSIFIER)
-#endif
-
-#ifndef __section_act_entry
-# define __section_act_entry \
- __section(ELF_SECTION_ACTION)
-#endif
-
-#ifndef __section_lwt_entry
-# define __section_lwt_entry \
- __section(ELF_SECTION_PROG)
-#endif
-
-#ifndef __section_license
-# define __section_license \
- __section(ELF_SECTION_LICENSE)
-#endif
-
-#ifndef __section_maps
-# define __section_maps \
- __section(ELF_SECTION_MAPS)
-#endif
-
-/** Declaration helper macros. */
-
-#ifndef BPF_LICENSE
-# define BPF_LICENSE(NAME) \
- char ____license[] __section_license = NAME
-#endif
-
-/** Classifier helper */
-
-#ifndef BPF_H_DEFAULT
-# define BPF_H_DEFAULT -1
-#endif
-
-/** BPF helper functions for tc. Individual flags are in linux/bpf.h */
-
-#ifndef __BPF_FUNC
-# define __BPF_FUNC(NAME, ...) \
- (* NAME)(__VA_ARGS__) __maybe_unused
-#endif
-
-#ifndef BPF_FUNC
-# define BPF_FUNC(NAME, ...) \
- __BPF_FUNC(NAME, __VA_ARGS__) = (void *) BPF_FUNC_##NAME
-#endif
-
-/* Map access/manipulation */
-static void *BPF_FUNC(map_lookup_elem, void *map, const void *key);
-static int BPF_FUNC(map_update_elem, void *map, const void *key,
- const void *value, uint32_t flags);
-static int BPF_FUNC(map_delete_elem, void *map, const void *key);
-
-/* Time access */
-static uint64_t BPF_FUNC(ktime_get_ns);
-
-/* Debugging */
-
-/* FIXME: __attribute__ ((format(printf, 1, 3))) not possible unless
- * llvm bug https://llvm.org/bugs/show_bug.cgi?id=26243 gets resolved.
- * It would require ____fmt to be made const, which generates a reloc
- * entry (non-map).
- */
-static void BPF_FUNC(trace_printk, const char *fmt, int fmt_size, ...);
-
-#ifndef printt
-# define printt(fmt, ...) \
- ({ \
- char ____fmt[] = fmt; \
- trace_printk(____fmt, sizeof(____fmt), ##__VA_ARGS__); \
- })
-#endif
-
-/* Random numbers */
-static uint32_t BPF_FUNC(get_prandom_u32);
-
-/* Tail calls */
-static void BPF_FUNC(tail_call, struct __sk_buff *skb, void *map,
- uint32_t index);
-
-/* System helpers */
-static uint32_t BPF_FUNC(get_smp_processor_id);
-static uint32_t BPF_FUNC(get_numa_node_id);
-
-/* Packet misc meta data */
-static uint32_t BPF_FUNC(get_cgroup_classid, struct __sk_buff *skb);
-static int BPF_FUNC(skb_under_cgroup, void *map, uint32_t index);
-
-static uint32_t BPF_FUNC(get_route_realm, struct __sk_buff *skb);
-static uint32_t BPF_FUNC(get_hash_recalc, struct __sk_buff *skb);
-static uint32_t BPF_FUNC(set_hash_invalid, struct __sk_buff *skb);
-
-/* Packet redirection */
-static int BPF_FUNC(redirect, int ifindex, uint32_t flags);
-static int BPF_FUNC(clone_redirect, struct __sk_buff *skb, int ifindex,
- uint32_t flags);
-
-/* Packet manipulation */
-static int BPF_FUNC(skb_load_bytes, struct __sk_buff *skb, uint32_t off,
- void *to, uint32_t len);
-static int BPF_FUNC(skb_store_bytes, struct __sk_buff *skb, uint32_t off,
- const void *from, uint32_t len, uint32_t flags);
-
-static int BPF_FUNC(l3_csum_replace, struct __sk_buff *skb, uint32_t off,
- uint32_t from, uint32_t to, uint32_t flags);
-static int BPF_FUNC(l4_csum_replace, struct __sk_buff *skb, uint32_t off,
- uint32_t from, uint32_t to, uint32_t flags);
-static int BPF_FUNC(csum_diff, const void *from, uint32_t from_size,
- const void *to, uint32_t to_size, uint32_t seed);
-static int BPF_FUNC(csum_update, struct __sk_buff *skb, uint32_t wsum);
-
-static int BPF_FUNC(skb_change_type, struct __sk_buff *skb, uint32_t type);
-static int BPF_FUNC(skb_change_proto, struct __sk_buff *skb, uint32_t proto,
- uint32_t flags);
-static int BPF_FUNC(skb_change_tail, struct __sk_buff *skb, uint32_t nlen,
- uint32_t flags);
-
-static int BPF_FUNC(skb_pull_data, struct __sk_buff *skb, uint32_t len);
-
-/* Event notification */
-static int __BPF_FUNC(skb_event_output, struct __sk_buff *skb, void *map,
- uint64_t index, const void *data, uint32_t size) =
- (void *) BPF_FUNC_perf_event_output;
-
-/* Packet vlan encap/decap */
-static int BPF_FUNC(skb_vlan_push, struct __sk_buff *skb, uint16_t proto,
- uint16_t vlan_tci);
-static int BPF_FUNC(skb_vlan_pop, struct __sk_buff *skb);
-
-/* Packet tunnel encap/decap */
-static int BPF_FUNC(skb_get_tunnel_key, struct __sk_buff *skb,
- struct bpf_tunnel_key *to, uint32_t size, uint32_t flags);
-static int BPF_FUNC(skb_set_tunnel_key, struct __sk_buff *skb,
- const struct bpf_tunnel_key *from, uint32_t size,
- uint32_t flags);
-
-static int BPF_FUNC(skb_get_tunnel_opt, struct __sk_buff *skb,
- void *to, uint32_t size);
-static int BPF_FUNC(skb_set_tunnel_opt, struct __sk_buff *skb,
- const void *from, uint32_t size);
-
-/** LLVM built-ins, mem*() routines work for constant size */
-
-#ifndef lock_xadd
-# define lock_xadd(ptr, val) ((void) __sync_fetch_and_add(ptr, val))
-#endif
-
-#ifndef memset
-# define memset(s, c, n) __builtin_memset((s), (c), (n))
-#endif
-
-#ifndef memcpy
-# define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
-#endif
-
-#ifndef memmove
-# define memmove(d, s, n) __builtin_memmove((d), (s), (n))
-#endif
-
-/* FIXME: __builtin_memcmp() is not yet fully usable unless llvm bug
- * https://llvm.org/bugs/show_bug.cgi?id=26218 gets resolved. Also
- * this one would generate a reloc entry (non-map), otherwise.
- */
-#if 0
-#ifndef memcmp
-# define memcmp(a, b, n) __builtin_memcmp((a), (b), (n))
-#endif
-#endif
-
-unsigned long long load_byte(void *skb, unsigned long long off)
- asm ("llvm.bpf.load.byte");
-
-unsigned long long load_half(void *skb, unsigned long long off)
- asm ("llvm.bpf.load.half");
-
-unsigned long long load_word(void *skb, unsigned long long off)
- asm ("llvm.bpf.load.word");
-
-#endif /* __BPF_API__ */
diff --git a/drivers/net/tap/bpf/bpf_elf.h b/drivers/net/tap/bpf/bpf_elf.h
deleted file mode 100644
index ea8a11c95c0f..000000000000
--- a/drivers/net/tap/bpf/bpf_elf.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */
-#ifndef __BPF_ELF__
-#define __BPF_ELF__
-
-#include <asm/types.h>
-
-/* Note:
- *
- * Below ELF section names and bpf_elf_map structure definition
- * are not (!) kernel ABI. It's rather a "contract" between the
- * application and the BPF loader in tc. For compatibility, the
- * section names should stay as-is. Introduction of aliases, if
- * needed, are a possibility, though.
- */
-
-/* ELF section names, etc */
-#define ELF_SECTION_LICENSE "license"
-#define ELF_SECTION_MAPS "maps"
-#define ELF_SECTION_PROG "prog"
-#define ELF_SECTION_CLASSIFIER "classifier"
-#define ELF_SECTION_ACTION "action"
-
-#define ELF_MAX_MAPS 64
-#define ELF_MAX_LICENSE_LEN 128
-
-/* Object pinning settings */
-#define PIN_NONE 0
-#define PIN_OBJECT_NS 1
-#define PIN_GLOBAL_NS 2
-
-/* ELF map definition */
-struct bpf_elf_map {
- __u32 type;
- __u32 size_key;
- __u32 size_value;
- __u32 max_elem;
- __u32 flags;
- __u32 id;
- __u32 pinning;
- __u32 inner_id;
- __u32 inner_idx;
-};
-
-#define BPF_ANNOTATE_KV_PAIR(name, type_key, type_val) \
- struct ____btf_map_##name { \
- type_key key; \
- type_val value; \
- }; \
- struct ____btf_map_##name \
- __attribute__ ((section(".maps." #name), used)) \
- ____btf_map_##name = { }
-
-#endif /* __BPF_ELF__ */
diff --git a/drivers/net/tap/bpf/bpf_extract.py b/drivers/net/tap/bpf/bpf_extract.py
deleted file mode 100644
index b630c42b809f..000000000000
--- a/drivers/net/tap/bpf/bpf_extract.py
+++ /dev/null
@@ -1,86 +0,0 @@
-#!/usr/bin/env python3
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright (c) 2023 Stephen Hemminger <stephen@networkplumber.org>
-
-import argparse
-import sys
-import struct
-from tempfile import TemporaryFile
-from elftools.elf.elffile import ELFFile
-
-
-def load_sections(elffile):
- """Get sections of interest from ELF"""
- result = []
- parts = [("cls_q", "cls_q_insns"), ("l3_l4", "l3_l4_hash_insns")]
- for name, tag in parts:
- section = elffile.get_section_by_name(name)
- if section:
- insns = struct.iter_unpack('<BBhL', section.data())
- result.append([tag, insns])
- return result
-
-
-def dump_section(name, insns, out):
- """Dump the array of BPF instructions"""
- print(f'\nstatic struct bpf_insn {name}[] = {{', file=out)
- for bpf in insns:
- code = bpf[0]
- src = bpf[1] >> 4
- dst = bpf[1] & 0xf
- off = bpf[2]
- imm = bpf[3]
- print(f'\t{{{code:#04x}, {dst:4d}, {src:4d}, {off:8d}, {imm:#010x}}},',
- file=out)
- print('};', file=out)
-
-
-def parse_args():
- """Parse command line arguments"""
- parser = argparse.ArgumentParser()
- parser.add_argument('-s',
- '--source',
- type=str,
- help="original source file")
- parser.add_argument('-o', '--out', type=str, help="output C file path")
- parser.add_argument("file",
- nargs='+',
- help="object file path or '-' for stdin")
- return parser.parse_args()
-
-
-def open_input(path):
- """Open the file or stdin"""
- if path == "-":
- temp = TemporaryFile()
- temp.write(sys.stdin.buffer.read())
- return temp
- return open(path, 'rb')
-
-
-def write_header(out, source):
- """Write file intro header"""
- print("/* SPDX-License-Identifier: BSD-3-Clause", file=out)
- if source:
- print(f' * Auto-generated from {source}', file=out)
- print(" * This not the original source file. Do NOT edit it.", file=out)
- print(" */\n", file=out)
- print("#include <tap_bpf.h>", file=out)
-
-
-def main():
- '''program main function'''
- args = parse_args()
-
- with open(args.out, 'w',
- encoding="utf-8") if args.out else sys.stdout as out:
- write_header(out, args.source)
- for path in args.file:
- elffile = ELFFile(open_input(path))
- sections = load_sections(elffile)
- for name, insns in sections:
- dump_section(name, insns, out)
-
-
-if __name__ == "__main__":
- main()
diff --git a/drivers/net/tap/bpf/tap_bpf_program.c b/drivers/net/tap/bpf/tap_bpf_program.c
deleted file mode 100644
index f05aed021c30..000000000000
--- a/drivers/net/tap/bpf/tap_bpf_program.c
+++ /dev/null
@@ -1,255 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
- * Copyright 2017 Mellanox Technologies, Ltd
- */
-
-#include <stdint.h>
-#include <stdbool.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <asm/types.h>
-#include <linux/in.h>
-#include <linux/if.h>
-#include <linux/if_ether.h>
-#include <linux/ip.h>
-#include <linux/ipv6.h>
-#include <linux/if_tunnel.h>
-#include <linux/filter.h>
-
-#include "bpf_api.h"
-#include "bpf_elf.h"
-#include "../tap_rss.h"
-
-/** Create IPv4 address */
-#define IPv4(a, b, c, d) ((__u32)(((a) & 0xff) << 24) | \
- (((b) & 0xff) << 16) | \
- (((c) & 0xff) << 8) | \
- ((d) & 0xff))
-
-#define PORT(a, b) ((__u16)(((a) & 0xff) << 8) | \
- ((b) & 0xff))
-
-/*
- * The queue number is offset by a unique QUEUE_OFFSET, to distinguish
- * packets that have gone through this rule (skb->cb[1] != 0) from others.
- */
-#define QUEUE_OFFSET 0x7cafe800
-#define PIN_GLOBAL_NS 2
-
-#define KEY_IDX 0
-#define BPF_MAP_ID_KEY 1
-
-struct vlan_hdr {
- __be16 proto;
- __be16 tci;
-};
-
-struct bpf_elf_map __attribute__((section("maps"), used))
-map_keys = {
- .type = BPF_MAP_TYPE_HASH,
- .id = BPF_MAP_ID_KEY,
- .size_key = sizeof(__u32),
- .size_value = sizeof(struct rss_key),
- .max_elem = 256,
- .pinning = PIN_GLOBAL_NS,
-};
-
-__section("cls_q") int
-match_q(struct __sk_buff *skb)
-{
- __u32 queue = skb->cb[1];
- /* queue is set by tap_flow_bpf_cls_q() before load */
- volatile __u32 q = 0xdeadbeef;
- __u32 match_queue = QUEUE_OFFSET + q;
-
- /* printt("match_q$i() queue = %d\n", queue); */
-
- if (queue != match_queue)
- return TC_ACT_OK;
-
- /* queue match */
- skb->cb[1] = 0;
- return TC_ACT_UNSPEC;
-}
-
-
-struct ipv4_l3_l4_tuple {
- __u32 src_addr;
- __u32 dst_addr;
- __u16 dport;
- __u16 sport;
-} __attribute__((packed));
-
-struct ipv6_l3_l4_tuple {
- __u8 src_addr[16];
- __u8 dst_addr[16];
- __u16 dport;
- __u16 sport;
-} __attribute__((packed));
-
-static const __u8 def_rss_key[TAP_RSS_HASH_KEY_SIZE] = {
- 0xd1, 0x81, 0xc6, 0x2c,
- 0xf7, 0xf4, 0xdb, 0x5b,
- 0x19, 0x83, 0xa2, 0xfc,
- 0x94, 0x3e, 0x1a, 0xdb,
- 0xd9, 0x38, 0x9e, 0x6b,
- 0xd1, 0x03, 0x9c, 0x2c,
- 0xa7, 0x44, 0x99, 0xad,
- 0x59, 0x3d, 0x56, 0xd9,
- 0xf3, 0x25, 0x3c, 0x06,
- 0x2a, 0xdc, 0x1f, 0xfc,
-};
-
-static __u32 __attribute__((always_inline))
-rte_softrss_be(const __u32 *input_tuple, const uint8_t *rss_key,
- __u8 input_len)
-{
- __u32 i, j, hash = 0;
-#pragma unroll
- for (j = 0; j < input_len; j++) {
-#pragma unroll
- for (i = 0; i < 32; i++) {
- if (input_tuple[j] & (1U << (31 - i))) {
- hash ^= ((const __u32 *)def_rss_key)[j] << i |
- (__u32)((uint64_t)
- (((const __u32 *)def_rss_key)[j + 1])
- >> (32 - i));
- }
- }
- }
- return hash;
-}
-
-static int __attribute__((always_inline))
-rss_l3_l4(struct __sk_buff *skb)
-{
- void *data_end = (void *)(long)skb->data_end;
- void *data = (void *)(long)skb->data;
- __u16 proto = (__u16)skb->protocol;
- __u32 key_idx = 0xdeadbeef;
- __u32 hash;
- struct rss_key *rsskey;
- __u64 off = ETH_HLEN;
- int j;
- __u8 *key = 0;
- __u32 len;
- __u32 queue = 0;
- bool mf = 0;
- __u16 frag_off = 0;
-
- rsskey = map_lookup_elem(&map_keys, &key_idx);
- if (!rsskey) {
- printt("hash(): rss key is not configured\n");
- return TC_ACT_OK;
- }
- key = (__u8 *)rsskey->key;
-
- /* Get correct proto for 802.1ad */
- if (skb->vlan_present && skb->vlan_proto == htons(ETH_P_8021AD)) {
- if (data + ETH_ALEN * 2 + sizeof(struct vlan_hdr) +
- sizeof(proto) > data_end)
- return TC_ACT_OK;
- proto = *(__u16 *)(data + ETH_ALEN * 2 +
- sizeof(struct vlan_hdr));
- off += sizeof(struct vlan_hdr);
- }
-
- if (proto == htons(ETH_P_IP)) {
- if (data + off + sizeof(struct iphdr) + sizeof(__u32)
- > data_end)
- return TC_ACT_OK;
-
- __u8 *src_dst_addr = data + off + offsetof(struct iphdr, saddr);
- __u8 *frag_off_addr = data + off + offsetof(struct iphdr, frag_off);
- __u8 *prot_addr = data + off + offsetof(struct iphdr, protocol);
- __u8 *src_dst_port = data + off + sizeof(struct iphdr);
- struct ipv4_l3_l4_tuple v4_tuple = {
- .src_addr = IPv4(*(src_dst_addr + 0),
- *(src_dst_addr + 1),
- *(src_dst_addr + 2),
- *(src_dst_addr + 3)),
- .dst_addr = IPv4(*(src_dst_addr + 4),
- *(src_dst_addr + 5),
- *(src_dst_addr + 6),
- *(src_dst_addr + 7)),
- .sport = 0,
- .dport = 0,
- };
- /** Fetch the L4-payer port numbers only in-case of TCP/UDP
- ** and also if the packet is not fragmented. Since fragmented
- ** chunks do not have L4 TCP/UDP header.
- **/
- if (*prot_addr == IPPROTO_UDP || *prot_addr == IPPROTO_TCP) {
- frag_off = PORT(*(frag_off_addr + 0),
- *(frag_off_addr + 1));
- mf = frag_off & 0x2000;
- frag_off = frag_off & 0x1fff;
- if (mf == 0 && frag_off == 0) {
- v4_tuple.sport = PORT(*(src_dst_port + 0),
- *(src_dst_port + 1));
- v4_tuple.dport = PORT(*(src_dst_port + 2),
- *(src_dst_port + 3));
- }
- }
- __u8 input_len = sizeof(v4_tuple) / sizeof(__u32);
- if (rsskey->hash_fields & (1 << HASH_FIELD_IPV4_L3))
- input_len--;
- hash = rte_softrss_be((__u32 *)&v4_tuple, key, 3);
- } else if (proto == htons(ETH_P_IPV6)) {
- if (data + off + sizeof(struct ipv6hdr) +
- sizeof(__u32) > data_end)
- return TC_ACT_OK;
- __u8 *src_dst_addr = data + off +
- offsetof(struct ipv6hdr, saddr);
- __u8 *src_dst_port = data + off +
- sizeof(struct ipv6hdr);
- __u8 *next_hdr = data + off +
- offsetof(struct ipv6hdr, nexthdr);
-
- struct ipv6_l3_l4_tuple v6_tuple;
- for (j = 0; j < 4; j++)
- *((uint32_t *)&v6_tuple.src_addr + j) =
- __builtin_bswap32(*((uint32_t *)
- src_dst_addr + j));
- for (j = 0; j < 4; j++)
- *((uint32_t *)&v6_tuple.dst_addr + j) =
- __builtin_bswap32(*((uint32_t *)
- src_dst_addr + 4 + j));
-
- /** Fetch the L4 header port-numbers only if next-header
- * is TCP/UDP **/
- if (*next_hdr == IPPROTO_UDP || *next_hdr == IPPROTO_TCP) {
- v6_tuple.sport = PORT(*(src_dst_port + 0),
- *(src_dst_port + 1));
- v6_tuple.dport = PORT(*(src_dst_port + 2),
- *(src_dst_port + 3));
- } else {
- v6_tuple.sport = 0;
- v6_tuple.dport = 0;
- }
-
- __u8 input_len = sizeof(v6_tuple) / sizeof(__u32);
- if (rsskey->hash_fields & (1 << HASH_FIELD_IPV6_L3))
- input_len--;
- hash = rte_softrss_be((__u32 *)&v6_tuple, key, 9);
- } else {
- return TC_ACT_PIPE;
- }
-
- queue = rsskey->queues[(hash % rsskey->nb_queues) &
- (TAP_MAX_QUEUES - 1)];
- skb->cb[1] = QUEUE_OFFSET + queue;
- /* printt(">>>>> rss_l3_l4 hash=0x%x queue=%u\n", hash, queue); */
-
- return TC_ACT_RECLASSIFY;
-}
-
-#define RSS(L) \
- __section(#L) int \
- L ## _hash(struct __sk_buff *skb) \
- { \
- return rss_ ## L (skb); \
- }
-
-RSS(l3_l4)
-
-BPF_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/tap/meson.build b/drivers/net/tap/meson.build
index 5099ccdff11b..f83f460a7808 100644
--- a/drivers/net/tap/meson.build
+++ b/drivers/net/tap/meson.build
@@ -7,7 +7,6 @@ if not is_linux
endif
sources = files(
'rte_eth_tap.c',
- 'tap_bpf_api.c',
'tap_flow.c',
'tap_intr.c',
'tap_netlink.c',
@@ -25,10 +24,6 @@ cflags += '-DTAP_MAX_QUEUES=16'
args = [
[ 'HAVE_TC_FLOWER', 'linux/pkt_cls.h', 'TCA_FLOWER_UNSPEC' ],
[ 'HAVE_TC_VLAN_ID', 'linux/pkt_cls.h', 'TCA_FLOWER_KEY_VLAN_PRIO' ],
- [ 'HAVE_TC_BPF', 'linux/pkt_cls.h', 'TCA_BPF_UNSPEC' ],
- [ 'HAVE_TC_BPF_FD', 'linux/pkt_cls.h', 'TCA_BPF_FD' ],
- [ 'HAVE_TC_ACT_BPF', 'linux/tc_act/tc_bpf.h', 'TCA_ACT_BPF_UNSPEC' ],
- [ 'HAVE_TC_ACT_BPF_FD', 'linux/tc_act/tc_bpf.h', 'TCA_ACT_BPF_FD' ],
]
config = configuration_data()
foreach arg:args
diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h
index 5ac93f93e961..e19824583651 100644
--- a/drivers/net/tap/rte_eth_tap.h
+++ b/drivers/net/tap/rte_eth_tap.h
@@ -79,11 +79,8 @@ struct pmd_internals {
int flow_isolate; /* 1 if flow isolation is enabled */
int flower_support; /* 1 if kernel supports, else 0 */
int flower_vlan_support; /* 1 if kernel supports, else 0 */
- int rss_enabled; /* 1 if RSS is enabled, else 0 */
int persist; /* 1 if keep link up, else 0 */
- /* implicit rules set when RSS is enabled */
- int map_fd; /* BPF RSS map fd */
- int bpf_fd[RTE_PMD_TAP_MAX_QUEUES];/* List of bpf fds per queue */
+
LIST_HEAD(tap_rss_flows, rte_flow) rss_flows;
LIST_HEAD(tap_flows, rte_flow) flows; /* rte_flow rules */
/* implicit rte_flow rules set when a remote device is active */
diff --git a/drivers/net/tap/tap_bpf.h b/drivers/net/tap/tap_bpf.h
deleted file mode 100644
index 0d38bc111fe0..000000000000
--- a/drivers/net/tap/tap_bpf.h
+++ /dev/null
@@ -1,121 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
- * Copyright 2017 Mellanox Technologies, Ltd
- */
-
-#ifndef __TAP_BPF_H__
-#define __TAP_BPF_H__
-
-#include <tap_autoconf.h>
-
-/* Do not #include <linux/bpf.h> since eBPF must compile on different
- * distros which may include partial definitions for eBPF (while the
- * kernel itself may support eBPF). Instead define here all that is needed
- */
-
-/* BPF_MAP_UPDATE_ELEM command flags */
-#define BPF_ANY 0 /* create a new element or update an existing */
-
-/* BPF architecture instruction struct */
-struct bpf_insn {
- __u8 code;
- __u8 dst_reg:4;
- __u8 src_reg:4;
- __s16 off;
- __s32 imm; /* immediate value */
-};
-
-/* BPF program types */
-enum bpf_prog_type {
- BPF_PROG_TYPE_UNSPEC,
- BPF_PROG_TYPE_SOCKET_FILTER,
- BPF_PROG_TYPE_KPROBE,
- BPF_PROG_TYPE_SCHED_CLS,
- BPF_PROG_TYPE_SCHED_ACT,
-};
-
-/* BPF commands types */
-enum bpf_cmd {
- BPF_MAP_CREATE,
- BPF_MAP_LOOKUP_ELEM,
- BPF_MAP_UPDATE_ELEM,
- BPF_MAP_DELETE_ELEM,
- BPF_MAP_GET_NEXT_KEY,
- BPF_PROG_LOAD,
-};
-
-/* BPF maps types */
-enum bpf_map_type {
- BPF_MAP_TYPE_UNSPEC,
- BPF_MAP_TYPE_HASH,
-};
-
-/* union of anonymous structs used with TAP BPF commands */
-union bpf_attr {
- /* BPF_MAP_CREATE command */
- struct {
- __u32 map_type;
- __u32 key_size;
- __u32 value_size;
- __u32 max_entries;
- __u32 map_flags;
- __u32 inner_map_fd;
- };
-
- /* BPF_MAP_UPDATE_ELEM, BPF_MAP_DELETE_ELEM commands */
- struct {
- __u32 map_fd;
- __aligned_u64 key;
- union {
- __aligned_u64 value;
- __aligned_u64 next_key;
- };
- __u64 flags;
- };
-
- /* BPF_PROG_LOAD command */
- struct {
- __u32 prog_type;
- __u32 insn_cnt;
- __aligned_u64 insns;
- __aligned_u64 license;
- __u32 log_level;
- __u32 log_size;
- __aligned_u64 log_buf;
- __u32 kern_version;
- __u32 prog_flags;
- };
-} __rte_aligned(8);
-
-#ifndef __NR_bpf
-# if defined(__i386__)
-# define __NR_bpf 357
-# elif defined(__x86_64__)
-# define __NR_bpf 321
-# elif defined(__arm__)
-# define __NR_bpf 386
-# elif defined(__aarch64__)
-# define __NR_bpf 280
-# elif defined(__sparc__)
-# define __NR_bpf 349
-# elif defined(__s390__)
-# define __NR_bpf 351
-# elif defined(__powerpc__)
-# define __NR_bpf 361
-# elif defined(__riscv)
-# define __NR_bpf 280
-# elif defined(__loongarch__)
-# define __NR_bpf 280
-# else
-# error __NR_bpf not defined
-# endif
-#endif
-
-enum {
- BPF_MAP_ID_KEY,
- BPF_MAP_ID_SIMPLE,
-};
-
-static int bpf_load(enum bpf_prog_type type, const struct bpf_insn *insns,
- size_t insns_cnt, const char *license);
-
-#endif /* __TAP_BPF_H__ */
diff --git a/drivers/net/tap/tap_bpf_api.c b/drivers/net/tap/tap_bpf_api.c
deleted file mode 100644
index 15283f8917ed..000000000000
--- a/drivers/net/tap/tap_bpf_api.c
+++ /dev/null
@@ -1,190 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright 2017 Mellanox Technologies, Ltd
- */
-
-#include <errno.h>
-#include <string.h>
-#include <unistd.h>
-#include <sys/queue.h>
-
-#include <rte_malloc.h>
-#include <rte_eth_tap.h>
-#include <tap_flow.h>
-#include <tap_autoconf.h>
-#include <tap_tcmsgs.h>
-#include <tap_bpf.h>
-#include <tap_bpf_insns.h>
-
-/**
- * Load BPF program (section cls_q) into the kernel and return a bpf fd
- *
- * @param queue_idx
- * Queue index matching packet cb
- *
- * @return
- * -1 if the BPF program couldn't be loaded. An fd (int) otherwise.
- */
-int tap_flow_bpf_cls_q(__u32 queue_idx)
-{
- cls_q_insns[1].imm = queue_idx;
-
- return bpf_load(BPF_PROG_TYPE_SCHED_CLS,
- (struct bpf_insn *)cls_q_insns,
- RTE_DIM(cls_q_insns),
- "Dual BSD/GPL");
-}
-
-/**
- * Load BPF program (section l3_l4) into the kernel and return a bpf fd.
- *
- * @param[in] key_idx
- * RSS MAP key index
- *
- * @param[in] map_fd
- * BPF RSS map file descriptor
- *
- * @return
- * -1 if the BPF program couldn't be loaded. An fd (int) otherwise.
- */
-int tap_flow_bpf_calc_l3_l4_hash(__u32 key_idx, int map_fd)
-{
- l3_l4_hash_insns[4].imm = key_idx;
- l3_l4_hash_insns[9].imm = map_fd;
-
- return bpf_load(BPF_PROG_TYPE_SCHED_ACT,
- (struct bpf_insn *)l3_l4_hash_insns,
- RTE_DIM(l3_l4_hash_insns),
- "Dual BSD/GPL");
-}
-
-/**
- * Helper function to convert a pointer to unsigned 64 bits
- *
- * @param[in] ptr
- * pointer to address
- *
- * @return
- * 64 bit unsigned long type of pointer address
- */
-static inline __u64 ptr_to_u64(const void *ptr)
-{
- return (__u64)(unsigned long)ptr;
-}
-
-/**
- * Call BPF system call
- *
- * @param[in] cmd
- * BPF command for program loading, map creation, map entry update, etc
- *
- * @param[in] attr
- * System call attributes relevant to system call command
- *
- * @param[in] size
- * size of attr parameter
- *
- * @return
- * -1 if BPF system call failed, 0 otherwise
- */
-static inline int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr,
- unsigned int size)
-{
- return syscall(__NR_bpf, cmd, attr, size);
-}
-
-/**
- * Load BPF instructions to kernel
- *
- * @param[in] type
- * BPF program type: classifier or action
- *
- * @param[in] insns
- * Array of BPF instructions (equivalent to BPF instructions)
- *
- * @param[in] insns_cnt
- * Number of BPF instructions (size of array)
- *
- * @param[in] license
- * License string that must be acknowledged by the kernel
- *
- * @return
- * -1 if the BPF program couldn't be loaded, fd (file descriptor) otherwise
- */
-static int bpf_load(enum bpf_prog_type type,
- const struct bpf_insn *insns,
- size_t insns_cnt,
- const char *license)
-{
- union bpf_attr attr = {};
-
- bzero(&attr, sizeof(attr));
- attr.prog_type = type;
- attr.insn_cnt = (__u32)insns_cnt;
- attr.insns = ptr_to_u64(insns);
- attr.license = ptr_to_u64(license);
- attr.log_buf = ptr_to_u64(NULL);
- attr.log_level = 0;
- attr.kern_version = 0;
-
- return sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
-}
-
-/**
- * Create BPF map for RSS rules
- *
- * @param[in] key_size
- * map RSS key size
- *
- * @param[in] value_size
- * Map RSS value size
- *
- * @param[in] max_entries
- * Map max number of RSS entries (limit on max RSS rules)
- *
- * @return
- * -1 if BPF map couldn't be created, map fd otherwise
- */
-int tap_flow_bpf_rss_map_create(unsigned int key_size,
- unsigned int value_size,
- unsigned int max_entries)
-{
- union bpf_attr attr = {};
-
- bzero(&attr, sizeof(attr));
- attr.map_type = BPF_MAP_TYPE_HASH;
- attr.key_size = key_size;
- attr.value_size = value_size;
- attr.max_entries = max_entries;
-
- return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
-}
-
-/**
- * Update RSS entry in BPF map
- *
- * @param[in] fd
- * RSS map fd
- *
- * @param[in] key
- * Pointer to RSS key whose entry is updated
- *
- * @param[in] value
- * Pointer to RSS new updated value
- *
- * @return
- * -1 if RSS entry failed to be updated, 0 otherwise
- */
-int tap_flow_bpf_update_rss_elem(int fd, void *key, void *value)
-{
- union bpf_attr attr = {};
-
- bzero(&attr, sizeof(attr));
-
- attr.map_type = BPF_MAP_TYPE_HASH;
- attr.map_fd = fd;
- attr.key = ptr_to_u64(key);
- attr.value = ptr_to_u64(value);
- attr.flags = BPF_ANY;
-
- return sys_bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
-}
diff --git a/drivers/net/tap/tap_bpf_insns.h b/drivers/net/tap/tap_bpf_insns.h
deleted file mode 100644
index 53fa76c4e6b0..000000000000
--- a/drivers/net/tap/tap_bpf_insns.h
+++ /dev/null
@@ -1,1743 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Auto-generated from tap_bpf_program.c
- * This not the original source file. Do NOT edit it.
- */
-
-#include <tap_bpf.h>
-
-static struct bpf_insn cls_q_insns[] = {
- {0x61, 2, 1, 52, 0x00000000},
- {0x18, 3, 0, 0, 0xdeadbeef},
- {0x00, 0, 0, 0, 0x00000000},
- {0x63, 10, 3, -4, 0x00000000},
- {0xb7, 0, 0, 0, 0x00000000},
- {0x61, 3, 10, -4, 0x00000000},
- {0x07, 3, 0, 0, 0x7cafe800},
- {0x67, 3, 0, 0, 0x00000020},
- {0x77, 3, 0, 0, 0x00000020},
- {0x5d, 2, 3, 4, 0x00000000},
- {0xb7, 2, 0, 0, 0x00000000},
- {0x63, 1, 2, 52, 0x00000000},
- {0x18, 0, 0, 0, 0xffffffff},
- {0x00, 0, 0, 0, 0x00000000},
- {0x95, 0, 0, 0, 0x00000000},
-};
-
-static struct bpf_insn l3_l4_hash_insns[] = {
- {0xbf, 7, 1, 0, 0x00000000},
- {0x61, 6, 7, 16, 0x00000000},
- {0x61, 8, 7, 76, 0x00000000},
- {0x61, 9, 7, 80, 0x00000000},
- {0x18, 1, 0, 0, 0xdeadbeef},
- {0x00, 0, 0, 0, 0x00000000},
- {0x63, 10, 1, -4, 0x00000000},
- {0xbf, 2, 10, 0, 0x00000000},
- {0x07, 2, 0, 0, 0xfffffffc},
- {0x18, 1, 0, 0, 0x00000000},
- {0x00, 0, 0, 0, 0x00000000},
- {0x85, 0, 0, 0, 0x00000001},
- {0x55, 0, 0, 21, 0x00000000},
- {0xb7, 1, 0, 0, 0x00000a64},
- {0x6b, 10, 1, -16, 0x00000000},
- {0x18, 1, 0, 0, 0x69666e6f},
- {0x00, 0, 0, 0, 0x65727567},
- {0x7b, 10, 1, -24, 0x00000000},
- {0x18, 1, 0, 0, 0x6e207369},
- {0x00, 0, 0, 0, 0x6320746f},
- {0x7b, 10, 1, -32, 0x00000000},
- {0x18, 1, 0, 0, 0x20737372},
- {0x00, 0, 0, 0, 0x2079656b},
- {0x7b, 10, 1, -40, 0x00000000},
- {0x18, 1, 0, 0, 0x68736168},
- {0x00, 0, 0, 0, 0x203a2928},
- {0x7b, 10, 1, -48, 0x00000000},
- {0xb7, 7, 0, 0, 0x00000000},
- {0x73, 10, 7, -14, 0x00000000},
- {0xbf, 1, 10, 0, 0x00000000},
- {0x07, 1, 0, 0, 0xffffffd0},
- {0xb7, 2, 0, 0, 0x00000023},
- {0x85, 0, 0, 0, 0x00000006},
- {0x05, 0, 0, 1680, 0x00000000},
- {0xb7, 1, 0, 0, 0x0000000e},
- {0x61, 2, 7, 20, 0x00000000},
- {0x15, 2, 0, 10, 0x00000000},
- {0x61, 2, 7, 28, 0x00000000},
- {0x55, 2, 0, 8, 0x0000a888},
- {0xbf, 2, 7, 0, 0x00000000},
- {0xb7, 7, 0, 0, 0x00000000},
- {0xbf, 1, 8, 0, 0x00000000},
- {0x07, 1, 0, 0, 0x00000012},
- {0x2d, 1, 9, 1670, 0x00000000},
- {0xb7, 1, 0, 0, 0x00000012},
- {0x69, 6, 8, 16, 0x00000000},
- {0xbf, 7, 2, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x0000ffff},
- {0x7b, 10, 7, -56, 0x00000000},
- {0x15, 6, 0, 443, 0x0000dd86},
- {0xb7, 7, 0, 0, 0x00000003},
- {0x55, 6, 0, 1662, 0x00000008},
- {0x0f, 8, 1, 0, 0x00000000},
- {0xb7, 7, 0, 0, 0x00000000},
- {0xbf, 1, 8, 0, 0x00000000},
- {0x07, 1, 0, 0, 0x00000018},
- {0x2d, 1, 9, 1657, 0x00000000},
- {0xb7, 1, 0, 0, 0x00000000},
- {0x71, 3, 8, 12, 0x00000000},
- {0x71, 2, 8, 9, 0x00000000},
- {0x15, 2, 0, 1, 0x00000011},
- {0x55, 2, 0, 21, 0x00000006},
- {0x71, 2, 8, 7, 0x00000000},
- {0x71, 4, 8, 6, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x67, 5, 0, 0, 0x00000008},
- {0x57, 5, 0, 0, 0x00001f00},
- {0x4f, 5, 2, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x4f, 4, 5, 0, 0x00000000},
- {0x55, 4, 0, 12, 0x00000000},
- {0xbf, 2, 8, 0, 0x00000000},
- {0x07, 2, 0, 0, 0x00000014},
- {0x71, 4, 2, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000018},
- {0x71, 1, 2, 1, 0x00000000},
- {0x67, 1, 0, 0, 0x00000010},
- {0x4f, 1, 4, 0, 0x00000000},
- {0x71, 4, 2, 3, 0x00000000},
- {0x4f, 1, 4, 0, 0x00000000},
- {0x71, 2, 2, 2, 0x00000000},
- {0x67, 2, 0, 0, 0x00000008},
- {0x4f, 1, 2, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000038},
- {0xc7, 4, 0, 0, 0x00000038},
- {0xb7, 2, 0, 0, 0x00000000},
- {0x65, 4, 0, 1, 0xffffffff},
- {0xb7, 7, 0, 0, 0x2cc681d1},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x598d03a2},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb31a0745},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x66340e8a},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xcc681d15},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000004},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x98d03a2b},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000002},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x31a07456},
- {0x71, 4, 8, 13, 0x00000000},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x6340e8ad},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x67, 3, 0, 0, 0x00000038},
- {0xc7, 3, 0, 0, 0x00000038},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0xc681d15b},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8d03a2b7},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1a07456f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x340e8ade},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x681d15bd},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000004},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd03a2b7b},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000002},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa07456f6},
- {0x71, 3, 8, 14, 0x00000000},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x40e8aded},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000038},
- {0xc7, 4, 0, 0, 0x00000038},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0x81d15bdb},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x03a2b7b7},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x07456f6f},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x0e8adedf},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x1d15bdbf},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000004},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x3a2b7b7e},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000002},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x7456f6fd},
- {0x71, 4, 8, 15, 0x00000000},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xe8adedfa},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x67, 3, 0, 0, 0x00000038},
- {0xc7, 3, 0, 0, 0x00000038},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0xd15bdbf4},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa2b7b7e9},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x456f6fd3},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8adedfa7},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x15bdbf4f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000004},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x2b7b7e9e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000002},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x56f6fd3d},
- {0x71, 3, 8, 16, 0x00000000},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xadedfa7b},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000038},
- {0xc7, 4, 0, 0, 0x00000038},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0x5bdbf4f7},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb7b7e9ef},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x6f6fd3df},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xdedfa7bf},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xbdbf4f7f},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000004},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x7b7e9eff},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000002},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xf6fd3dff},
- {0x71, 4, 8, 17, 0x00000000},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xedfa7bfe},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x67, 3, 0, 0, 0x00000038},
- {0xc7, 3, 0, 0, 0x00000038},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0xdbf4f7fc},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb7e9eff9},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6fd3dff2},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xdfa7bfe5},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xbf4f7fca},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000004},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7e9eff94},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000002},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfd3dff28},
- {0x71, 3, 8, 18, 0x00000000},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfa7bfe51},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x67, 6, 0, 0, 0x00000038},
- {0xc7, 6, 0, 0, 0x00000038},
- {0xbf, 4, 5, 0, 0x00000000},
- {0xa7, 4, 0, 0, 0xf4f7fca2},
- {0x6d, 2, 6, 1, 0x00000000},
- {0xbf, 4, 5, 0, 0x00000000},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000040},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xe9eff945},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000020},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xd3dff28a},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000010},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xa7bfe514},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000008},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x4f7fca28},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x9eff9450},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x3dff28a0},
- {0x71, 5, 8, 19, 0x00000000},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x7bfe5141},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x67, 3, 0, 0, 0x00000038},
- {0xc7, 3, 0, 0, 0x00000038},
- {0xbf, 7, 4, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0xf7fca283},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 7, 4, 0, 0x00000000},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xeff94506},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xdff28a0c},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xbfe51418},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x7fca2831},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000004},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xff945063},
- {0xbf, 3, 5, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000002},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xff28a0c6},
- {0x57, 5, 0, 0, 0x00000001},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xfe51418c},
- {0xbf, 4, 1, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000020},
- {0xc7, 4, 0, 0, 0x00000020},
- {0xbf, 3, 7, 0, 0x00000000},
- {0xa7, 3, 0, 0, 0xfca28319},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 3, 7, 0, 0x00000000},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x40000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xf9450633},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x20000000},
- {0x79, 6, 10, -56, 0x00000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xf28a0c67},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x10000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xe51418ce},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x08000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xca28319d},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x04000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x9450633b},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x02000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x28a0c676},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x01000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x51418ced},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00800000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xa28319db},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00400000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x450633b6},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00200000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x8a0c676c},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00100000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x1418ced8},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00080000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x28319db1},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00040000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x50633b63},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00020000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xa0c676c6},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00010000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x418ced8d},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00008000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x8319db1a},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00004000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x0633b634},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00002000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x0c676c68},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00001000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x18ced8d1},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000800},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x319db1a3},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000400},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x633b6347},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000200},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xc676c68f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000100},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x8ced8d1f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000080},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x19db1a3e},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000040},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x33b6347d},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000020},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x676c68fa},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000010},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xced8d1f4},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000008},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x9db1a3e9},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000004},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x3b6347d2},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000002},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x76c68fa5},
- {0x57, 1, 0, 0, 0x00000001},
- {0x15, 1, 0, 1194, 0x00000000},
- {0xa7, 3, 0, 0, 0xed8d1f4a},
- {0x05, 0, 0, 1192, 0x00000000},
- {0x0f, 8, 1, 0, 0x00000000},
- {0xb7, 7, 0, 0, 0x00000000},
- {0xbf, 1, 8, 0, 0x00000000},
- {0x07, 1, 0, 0, 0x0000002c},
- {0x2d, 1, 9, 1216, 0x00000000},
- {0x61, 2, 8, 8, 0x00000000},
- {0xdc, 2, 0, 0, 0x00000040},
- {0xc7, 2, 0, 0, 0x00000020},
- {0x71, 3, 8, 6, 0x00000000},
- {0x15, 3, 0, 2, 0x00000011},
- {0xb7, 1, 0, 0, 0x00000000},
- {0x55, 3, 0, 12, 0x00000006},
- {0xbf, 3, 8, 0, 0x00000000},
- {0x07, 3, 0, 0, 0x00000028},
- {0x71, 4, 3, 0, 0x00000000},
- {0x67, 4, 0, 0, 0x00000018},
- {0x71, 1, 3, 1, 0x00000000},
- {0x67, 1, 0, 0, 0x00000010},
- {0x4f, 1, 4, 0, 0x00000000},
- {0x71, 4, 3, 3, 0x00000000},
- {0x4f, 1, 4, 0, 0x00000000},
- {0x71, 3, 3, 2, 0x00000000},
- {0x67, 3, 0, 0, 0x00000008},
- {0x4f, 1, 3, 0, 0x00000000},
- {0xbf, 4, 2, 0, 0x00000000},
- {0x77, 4, 0, 0, 0x0000001f},
- {0x57, 4, 0, 0, 0x2cc681d1},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x40000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x598d03a2},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x20000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xb31a0745},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x10000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x66340e8a},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x08000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xcc681d15},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x04000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x98d03a2b},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x02000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x31a07456},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x01000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x6340e8ad},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00800000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xc681d15b},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00400000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x8d03a2b7},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00200000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x1a07456f},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00100000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x340e8ade},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00080000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x681d15bd},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00040000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xd03a2b7b},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00020000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xa07456f6},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00010000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x40e8aded},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00008000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x81d15bdb},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00004000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x03a2b7b7},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00002000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x07456f6f},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00001000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x0e8adedf},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000800},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x1d15bdbf},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000400},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x3a2b7b7e},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000200},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x7456f6fd},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000100},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xe8adedfa},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000080},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xd15bdbf4},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xa2b7b7e9},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x456f6fd3},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x8adedfa7},
- {0xbf, 3, 2, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x15bdbf4f},
- {0x61, 3, 8, 12, 0x00000000},
- {0xbf, 5, 2, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x2b7b7e9e},
- {0xdc, 3, 0, 0, 0x00000040},
- {0xbf, 5, 2, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x56f6fd3d},
- {0xc7, 3, 0, 0, 0x00000020},
- {0x57, 2, 0, 0, 0x00000001},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xadedfa7b},
- {0xb7, 2, 0, 0, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0x5bdbf4f7},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x40000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb7b7e9ef},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x20000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6f6fd3df},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x10000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xdedfa7bf},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x08000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xbdbf4f7f},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x04000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7b7e9eff},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x02000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xf6fd3dff},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x01000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xedfa7bfe},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00800000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xdbf4f7fc},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00400000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb7e9eff9},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00200000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6fd3dff2},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00100000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xdfa7bfe5},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00080000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xbf4f7fca},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00040000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7e9eff94},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00020000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfd3dff28},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00010000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfa7bfe51},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00008000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xf4f7fca2},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00004000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xe9eff945},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00002000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd3dff28a},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00001000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa7bfe514},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000800},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x4f7fca28},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000400},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x9eff9450},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000200},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x3dff28a0},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000100},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7bfe5141},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000080},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xf7fca283},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xeff94506},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xdff28a0c},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xbfe51418},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7fca2831},
- {0x61, 4, 8, 16, 0x00000000},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000004},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xff945063},
- {0xdc, 4, 0, 0, 0x00000040},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000002},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xff28a0c6},
- {0xc7, 4, 0, 0, 0x00000020},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfe51418c},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0xfca28319},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x40000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xf9450633},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x20000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xf28a0c67},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x10000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xe51418ce},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x08000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xca28319d},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x04000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x9450633b},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x02000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x28a0c676},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x01000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x51418ced},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00800000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xa28319db},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00400000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x450633b6},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00200000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x8a0c676c},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00100000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x1418ced8},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00080000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x28319db1},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00040000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x50633b63},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00020000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xa0c676c6},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00010000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x418ced8d},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00008000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x8319db1a},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00004000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x0633b634},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00002000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x0c676c68},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00001000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x18ced8d1},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000800},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x319db1a3},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000400},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x633b6347},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000200},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xc676c68f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000100},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x8ced8d1f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000080},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x19db1a3e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x33b6347d},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x676c68fa},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xced8d1f4},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x9db1a3e9},
- {0x61, 3, 8, 20, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x3b6347d2},
- {0xdc, 3, 0, 0, 0x00000040},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x76c68fa5},
- {0xc7, 3, 0, 0, 0x00000020},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xed8d1f4a},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0xdb1a3e94},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x40000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb6347d28},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x20000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6c68fa51},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x10000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd8d1f4a3},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x08000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb1a3e946},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x04000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6347d28d},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x02000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xc68fa51a},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x01000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8d1f4a35},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00800000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1a3e946b},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00400000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x347d28d7},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00200000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x68fa51ae},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00100000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd1f4a35c},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00080000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa3e946b9},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00040000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x47d28d73},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00020000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8fa51ae7},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00010000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1f4a35cf},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00008000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x3e946b9e},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00004000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7d28d73c},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00002000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xfa51ae78},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00001000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xf4a35cf1},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000800},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xe946b9e3},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000400},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd28d73c7},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000200},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa51ae78e},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000100},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x4a35cf1c},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000080},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x946b9e38},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x28d73c71},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x51ae78e3},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa35cf1c6},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x46b9e38d},
- {0x61, 4, 8, 24, 0x00000000},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000004},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8d73c71b},
- {0xdc, 4, 0, 0, 0x00000040},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000002},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1ae78e36},
- {0xc7, 4, 0, 0, 0x00000020},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x35cf1c6c},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0x6b9e38d9},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x40000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xd73c71b2},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x20000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xae78e364},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x10000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x5cf1c6c9},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x08000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb9e38d92},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x04000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x73c71b25},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x02000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xe78e364b},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x01000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xcf1c6c96},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00800000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x9e38d92c},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00400000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x3c71b259},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00200000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x78e364b2},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00100000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xf1c6c964},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00080000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xe38d92c9},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00040000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xc71b2593},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00020000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x8e364b27},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00010000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x1c6c964e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00008000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x38d92c9c},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00004000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x71b25938},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00002000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xe364b270},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00001000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xc6c964e0},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000800},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x8d92c9c0},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000400},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x1b259380},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000200},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x364b2700},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000100},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x6c964e01},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000080},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xd92c9c03},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb2593807},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x64b2700f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xc964e01e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x92c9c03d},
- {0x61, 3, 8, 28, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x2593807a},
- {0xdc, 3, 0, 0, 0x00000040},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x4b2700f4},
- {0xc7, 3, 0, 0, 0x00000020},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x964e01e8},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xa7, 5, 0, 0, 0x2c9c03d1},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 5, 7, 0, 0x00000000},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x40000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x593807a3},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x20000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xb2700f46},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x10000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x64e01e8d},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x08000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xc9c03d1a},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x04000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x93807a35},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x02000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x2700f46b},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x01000000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x4e01e8d6},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00800000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x9c03d1ad},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00400000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x3807a35b},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00200000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x700f46b6},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00100000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xe01e8d6c},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00080000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xc03d1ad9},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00040000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x807a35b3},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00020000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x00f46b66},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00010000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x01e8d6cc},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00008000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x03d1ad99},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00004000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x07a35b32},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00002000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x0f46b665},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00001000},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1e8d6cca},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000800},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x3d1ad994},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000400},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x7a35b328},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000200},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xf46b6651},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000100},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xe8d6cca2},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000080},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd1ad9944},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000040},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xa35b3289},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000020},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x46b66512},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000010},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x8d6cca25},
- {0xbf, 4, 3, 0, 0x00000000},
- {0x57, 4, 0, 0, 0x00000008},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x1ad9944a},
- {0x61, 4, 8, 32, 0x00000000},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000004},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x35b32894},
- {0xdc, 4, 0, 0, 0x00000040},
- {0xbf, 6, 3, 0, 0x00000000},
- {0x57, 6, 0, 0, 0x00000002},
- {0x15, 6, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0x6b665129},
- {0xc7, 4, 0, 0, 0x00000020},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 5, 0, 0, 0xd6cca253},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xa7, 7, 0, 0, 0xad9944a7},
- {0x6d, 2, 4, 1, 0x00000000},
- {0xbf, 7, 5, 0, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x40000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x5b32894f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x20000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb665129f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x10000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x6cca253e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x08000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xd9944a7d},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x04000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xb32894fb},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x02000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x665129f6},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x01000000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xcca253ec},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00800000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x9944a7d9},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00400000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x32894fb2},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00200000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x65129f65},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00100000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xca253eca},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00080000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x944a7d95},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00040000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x2894fb2a},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00020000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x5129f655},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00010000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xa253ecab},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00008000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x44a7d956},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00004000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x894fb2ac},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00002000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x129f6558},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00001000},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x253ecab1},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000800},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x4a7d9563},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000400},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x94fb2ac7},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000200},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x29f6558f},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000100},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x53ecab1e},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000080},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xa7d9563d},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000040},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x4fb2ac7a},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000020},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x9f6558f5},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000010},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x3ecab1ea},
- {0xbf, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x00000008},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0x7d9563d5},
- {0x61, 3, 8, 36, 0x00000000},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xfb2ac7ab},
- {0xdc, 3, 0, 0, 0x00000040},
- {0xbf, 5, 4, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xf6558f56},
- {0xc7, 3, 0, 0, 0x00000020},
- {0x57, 4, 0, 0, 0x00000001},
- {0x15, 4, 0, 1, 0x00000000},
- {0xa7, 7, 0, 0, 0xecab1eac},
- {0xbf, 4, 7, 0, 0x00000000},
- {0xa7, 4, 0, 0, 0xd9563d59},
- {0x6d, 2, 3, 1, 0x00000000},
- {0xbf, 4, 7, 0, 0x00000000},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x40000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xb2ac7ab2},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x20000000},
- {0x79, 6, 10, -56, 0x00000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x6558f564},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x10000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xcab1eac8},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x08000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x9563d590},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x04000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x2ac7ab20},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x02000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x558f5641},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x01000000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xab1eac83},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00800000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x563d5906},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00400000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xac7ab20c},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00200000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x58f56418},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00100000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xb1eac831},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00080000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x63d59063},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00040000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xc7ab20c7},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00020000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x8f56418f},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00010000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x1eac831e},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00008000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x3d59063c},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00004000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x7ab20c78},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00002000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xf56418f0},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00001000},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xeac831e1},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000800},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xd59063c2},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000400},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xab20c784},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000200},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x56418f09},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000100},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xac831e12},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000080},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x59063c25},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000040},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xb20c784b},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000020},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x6418f097},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000010},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0xc831e12f},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000008},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x9063c25f},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000004},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x20c784be},
- {0xbf, 5, 3, 0, 0x00000000},
- {0x57, 5, 0, 0, 0x00000002},
- {0x15, 5, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x418f097c},
- {0x57, 3, 0, 0, 0x00000001},
- {0x15, 3, 0, 1, 0x00000000},
- {0xa7, 4, 0, 0, 0x831e12f9},
- {0xbf, 5, 1, 0, 0x00000000},
- {0x67, 5, 0, 0, 0x00000020},
- {0xc7, 5, 0, 0, 0x00000020},
- {0xbf, 3, 4, 0, 0x00000000},
- {0xa7, 3, 0, 0, 0x063c25f3},
- {0x6d, 2, 5, 1, 0x00000000},
- {0xbf, 3, 4, 0, 0x00000000},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x40000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x0c784be7},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x20000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x18f097cf},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x10000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x31e12f9f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x08000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x63c25f3f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x04000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xc784be7f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x02000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x8f097cff},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x01000000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x1e12f9fe},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00800000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x3c25f3fc},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00400000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x784be7f8},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00200000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xf097cff0},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00100000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xe12f9fe0},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00080000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xc25f3fc1},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00040000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x84be7f83},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00020000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x097cff07},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00010000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x12f9fe0f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00008000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x25f3fc1f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00004000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x4be7f83f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00002000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x97cff07f},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00001000},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x2f9fe0fe},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000800},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x5f3fc1fd},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000400},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xbe7f83fb},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000200},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x7cff07f7},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000100},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xf9fe0fee},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000080},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xf3fc1fdc},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000040},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xe7f83fb8},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000020},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xcff07f70},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000010},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x9fe0fee1},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000008},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x3fc1fdc2},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000004},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0x7f83fb85},
- {0xbf, 2, 1, 0, 0x00000000},
- {0x57, 2, 0, 0, 0x00000002},
- {0x15, 2, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xff07f70a},
- {0x57, 1, 0, 0, 0x00000001},
- {0x15, 1, 0, 1, 0x00000000},
- {0xa7, 3, 0, 0, 0xfe0fee15},
- {0x71, 1, 0, 201, 0x00000000},
- {0x67, 1, 0, 0, 0x00000008},
- {0x71, 2, 0, 200, 0x00000000},
- {0x4f, 1, 2, 0, 0x00000000},
- {0x71, 2, 0, 202, 0x00000000},
- {0x67, 2, 0, 0, 0x00000010},
- {0x71, 4, 0, 203, 0x00000000},
- {0x67, 4, 0, 0, 0x00000018},
- {0x4f, 4, 2, 0, 0x00000000},
- {0x4f, 4, 1, 0, 0x00000000},
- {0x67, 3, 0, 0, 0x00000020},
- {0x77, 3, 0, 0, 0x00000020},
- {0x9f, 3, 4, 0, 0x00000000},
- {0x57, 3, 0, 0, 0x0000000f},
- {0x67, 3, 0, 0, 0x00000002},
- {0x0f, 0, 3, 0, 0x00000000},
- {0x71, 1, 0, 137, 0x00000000},
- {0x67, 1, 0, 0, 0x00000008},
- {0x71, 2, 0, 136, 0x00000000},
- {0x4f, 1, 2, 0, 0x00000000},
- {0x71, 2, 0, 138, 0x00000000},
- {0x67, 2, 0, 0, 0x00000010},
- {0x71, 3, 0, 139, 0x00000000},
- {0x67, 3, 0, 0, 0x00000018},
- {0x4f, 3, 2, 0, 0x00000000},
- {0x4f, 3, 1, 0, 0x00000000},
- {0x07, 3, 0, 0, 0x7cafe800},
- {0x63, 6, 3, 52, 0x00000000},
- {0xb7, 7, 0, 0, 0x00000001},
- {0xbf, 0, 7, 0, 0x00000000},
- {0x95, 0, 0, 0, 0x00000000},
-};
diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index ed4d42f92f9f..84e816d80043 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -56,71 +56,6 @@ enum {
TCA_FLOWER_KEY_VLAN_ETH_TYPE, /* be16 */
};
#endif
-/*
- * For kernels < 4.2 BPF related enums may not be defined.
- * Runtime checks will be carried out to gracefully report on TC messages that
- * are rejected by the kernel. Rejection reasons may be due to:
- * 1. enum is not defined
- * 2. enum is defined but kernel is not configured to support BPF system calls,
- * BPF classifications or BPF actions.
- */
-#ifndef HAVE_TC_BPF
-enum {
- TCA_BPF_UNSPEC,
- TCA_BPF_ACT,
- TCA_BPF_POLICE,
- TCA_BPF_CLASSID,
- TCA_BPF_OPS_LEN,
- TCA_BPF_OPS,
-};
-#endif
-#ifndef HAVE_TC_BPF_FD
-enum {
- TCA_BPF_FD = TCA_BPF_OPS + 1,
- TCA_BPF_NAME,
-};
-#endif
-#ifndef HAVE_TC_ACT_BPF
-#define tc_gen \
- __u32 index; \
- __u32 capab; \
- int action; \
- int refcnt; \
- int bindcnt
-
-struct tc_act_bpf {
- tc_gen;
-};
-
-enum {
- TCA_ACT_BPF_UNSPEC,
- TCA_ACT_BPF_TM,
- TCA_ACT_BPF_PARMS,
- TCA_ACT_BPF_OPS_LEN,
- TCA_ACT_BPF_OPS,
-};
-
-#endif
-#ifndef HAVE_TC_ACT_BPF_FD
-enum {
- TCA_ACT_BPF_FD = TCA_ACT_BPF_OPS + 1,
- TCA_ACT_BPF_NAME,
-};
-#endif
-
-/* RSS key management */
-enum bpf_rss_key_e {
- KEY_CMD_GET = 1,
- KEY_CMD_RELEASE,
- KEY_CMD_INIT,
- KEY_CMD_DEINIT,
-};
-
-enum key_status_e {
- KEY_STAT_UNSPEC,
- KEY_STAT_USED,
- KEY_STAT_AVAILABLE,
-};
#define ISOLATE_HANDLE 1
#define REMOTE_PROMISCUOUS_HANDLE 2
@@ -128,8 +63,6 @@ enum key_status_e {
struct rte_flow {
LIST_ENTRY(rte_flow) next; /* Pointer to the next rte_flow structure */
struct rte_flow *remote_flow; /* associated remote flow */
- int bpf_fd[SEC_MAX]; /* list of bfs fds per ELF section */
- uint32_t key_idx; /* RSS rule key index into BPF map */
struct nlmsg msg;
};
@@ -157,11 +90,6 @@ struct action_data {
struct tc_skbedit skbedit;
uint16_t queue;
} skbedit;
- struct bpf {
- struct tc_act_bpf bpf;
- int bpf_fd;
- const char *annotation;
- } bpf;
};
};
@@ -185,10 +113,6 @@ tap_flow_create(struct rte_eth_dev *dev,
const struct rte_flow_action actions[],
struct rte_flow_error *error);
-static void
-tap_flow_free(struct pmd_internals *pmd,
- struct rte_flow *flow);
-
static int
tap_flow_destroy(struct rte_eth_dev *dev,
struct rte_flow *flow,
@@ -199,14 +123,6 @@ tap_flow_isolate(struct rte_eth_dev *dev,
int set,
struct rte_flow_error *error);
-static int bpf_rss_key(enum bpf_rss_key_e cmd, __u32 *key_idx);
-static int rss_enable(struct pmd_internals *pmd,
- const struct rte_flow_attr *attr,
- struct rte_flow_error *error);
-static int rss_add_actions(struct rte_flow *flow, struct pmd_internals *pmd,
- const struct rte_flow_action_rss *rss,
- struct rte_flow_error *error);
-
static const struct rte_flow_ops tap_flow_ops = {
.validate = tap_flow_validate,
.create = tap_flow_create,
@@ -901,7 +817,7 @@ tap_flow_item_validate(const struct rte_flow_item *item,
/**
* Configure the kernel with a TC action and its configured parameters
- * Handled actions: "gact", "mirred", "skbedit", "bpf"
+ * Handled actions: "gact", "mirred", "skbedit"
*
* @param[in] flow
* Pointer to rte flow containing the netlink message
@@ -944,14 +860,6 @@ add_action(struct rte_flow *flow, size_t *act_index, struct action_data *adata)
&adata->skbedit.skbedit);
tap_nlattr_add16(&msg->nh, TCA_SKBEDIT_QUEUE_MAPPING,
adata->skbedit.queue);
- } else if (strcmp("bpf", adata->id) == 0) {
- tap_nlattr_add32(&msg->nh, TCA_ACT_BPF_FD, adata->bpf.bpf_fd);
- tap_nlattr_add(&msg->nh, TCA_ACT_BPF_NAME,
- strlen(adata->bpf.annotation) + 1,
- adata->bpf.annotation);
- tap_nlattr_add(&msg->nh, TCA_ACT_BPF_PARMS,
- sizeof(adata->bpf.bpf),
- &adata->bpf.bpf);
} else {
return -1;
}
@@ -1216,21 +1124,6 @@ priv_flow_process(struct pmd_internals *pmd,
err = add_actions(flow, 1, &adata,
TCA_FLOWER_ACT);
}
- } else if (actions->type == RTE_FLOW_ACTION_TYPE_RSS) {
- const struct rte_flow_action_rss *rss =
- (const struct rte_flow_action_rss *)
- actions->conf;
-
- if (action++)
- goto exit_action_not_supported;
-
- if (!pmd->rss_enabled) {
- err = rss_enable(pmd, attr, error);
- if (err)
- goto exit_action_not_supported;
- }
- if (flow)
- err = rss_add_actions(flow, pmd, rss, error);
} else {
goto exit_action_not_supported;
}
@@ -1318,38 +1211,6 @@ tap_flow_set_handle(struct rte_flow *flow)
flow->msg.t.tcm_handle = handle;
}
-/**
- * Free the flow opened file descriptors and allocated memory
- *
- * @param[in] flow
- * Pointer to the flow to free
- *
- */
-static void
-tap_flow_free(struct pmd_internals *pmd, struct rte_flow *flow)
-{
- int i;
-
- if (!flow)
- return;
-
- if (pmd->rss_enabled) {
- /* Close flow BPF file descriptors */
- for (i = 0; i < SEC_MAX; i++)
- if (flow->bpf_fd[i] != 0) {
- close(flow->bpf_fd[i]);
- flow->bpf_fd[i] = 0;
- }
-
- /* Release the map key for this RSS rule */
- bpf_rss_key(KEY_CMD_RELEASE, &flow->key_idx);
- flow->key_idx = 0;
- }
-
- /* Free flow allocated memory */
- rte_free(flow);
-}
-
/**
* Create a flow.
*
@@ -1466,8 +1327,7 @@ tap_flow_create(struct rte_eth_dev *dev,
return flow;
fail:
rte_free(remote_flow);
- if (flow)
- tap_flow_free(pmd, flow);
+ rte_free(flow);
return NULL;
}
@@ -1541,7 +1401,7 @@ tap_flow_destroy_pmd(struct pmd_internals *pmd,
}
end:
rte_free(remote_flow);
- tap_flow_free(pmd, flow);
+ rte_free(flow);
return ret;
}
@@ -1812,356 +1672,6 @@ tap_flow_implicit_flush(struct pmd_internals *pmd, struct rte_flow_error *error)
return 0;
}
-#define MAX_RSS_KEYS 256
-#define KEY_IDX_OFFSET (3 * MAX_RSS_KEYS)
-#define SEC_NAME_CLS_Q "cls_q"
-
-static const char *sec_name[SEC_MAX] = {
- [SEC_L3_L4] = "l3_l4",
-};
-
-/**
- * Enable RSS on tap: create TC rules for queuing.
- *
- * @param[in, out] pmd
- * Pointer to private structure.
- *
- * @param[in] attr
- * Pointer to rte_flow to get flow group
- *
- * @param[out] error
- * Pointer to error reporting if not NULL.
- *
- * @return 0 on success, negative value on failure.
- */
-static int rss_enable(struct pmd_internals *pmd,
- const struct rte_flow_attr *attr,
- struct rte_flow_error *error)
-{
- struct rte_flow *rss_flow = NULL;
- struct nlmsg *msg = NULL;
- /* 4096 is the maximum number of instructions for a BPF program */
- char annotation[64];
- int i;
- int err = 0;
-
- /* unlimit locked memory */
- struct rlimit memlock_limit = {
- .rlim_cur = RLIM_INFINITY,
- .rlim_max = RLIM_INFINITY,
- };
- setrlimit(RLIMIT_MEMLOCK, &memlock_limit);
-
- /* Get a new map key for a new RSS rule */
- err = bpf_rss_key(KEY_CMD_INIT, NULL);
- if (err < 0) {
- rte_flow_error_set(
- error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Failed to initialize BPF RSS keys");
-
- return -1;
- }
-
- /*
- * Create BPF RSS MAP
- */
- pmd->map_fd = tap_flow_bpf_rss_map_create(sizeof(__u32), /* key size */
- sizeof(struct rss_key),
- MAX_RSS_KEYS);
- if (pmd->map_fd < 0) {
- TAP_LOG(ERR,
- "Failed to create BPF map (%d): %s",
- errno, strerror(errno));
- rte_flow_error_set(
- error, ENOTSUP, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Kernel too old or not configured "
- "to support BPF maps");
-
- return -ENOTSUP;
- }
-
- /*
- * Add a rule per queue to match reclassified packets and direct them to
- * the correct queue.
- */
- for (i = 0; i < pmd->dev->data->nb_rx_queues; i++) {
- pmd->bpf_fd[i] = tap_flow_bpf_cls_q(i);
- if (pmd->bpf_fd[i] < 0) {
- TAP_LOG(ERR,
- "Failed to load BPF section %s for queue %d",
- SEC_NAME_CLS_Q, i);
- rte_flow_error_set(
- error, ENOTSUP, RTE_FLOW_ERROR_TYPE_HANDLE,
- NULL,
- "Kernel too old or not configured "
- "to support BPF programs loading");
-
- return -ENOTSUP;
- }
-
- rss_flow = rte_zmalloc(__func__, sizeof(struct rte_flow), 0);
- if (!rss_flow) {
- TAP_LOG(ERR,
- "Cannot allocate memory for rte_flow");
- return -1;
- }
- msg = &rss_flow->msg;
- tc_init_msg(msg, pmd->if_index, RTM_NEWTFILTER, NLM_F_REQUEST |
- NLM_F_ACK | NLM_F_EXCL | NLM_F_CREATE);
- msg->t.tcm_info = TC_H_MAKE(0, htons(ETH_P_ALL));
- tap_flow_set_handle(rss_flow);
- uint16_t group = attr->group << GROUP_SHIFT;
- uint16_t prio = group | (i + PRIORITY_OFFSET);
- msg->t.tcm_info = TC_H_MAKE(prio << 16, msg->t.tcm_info);
- msg->t.tcm_parent = TC_H_MAKE(MULTIQ_MAJOR_HANDLE, 0);
-
- tap_nlattr_add(&msg->nh, TCA_KIND, sizeof("bpf"), "bpf");
- if (tap_nlattr_nested_start(msg, TCA_OPTIONS) < 0)
- return -1;
- tap_nlattr_add32(&msg->nh, TCA_BPF_FD, pmd->bpf_fd[i]);
- snprintf(annotation, sizeof(annotation), "[%s%d]",
- SEC_NAME_CLS_Q, i);
- tap_nlattr_add(&msg->nh, TCA_BPF_NAME, strlen(annotation) + 1,
- annotation);
- /* Actions */
- {
- struct action_data adata = {
- .id = "skbedit",
- .skbedit = {
- .skbedit = {
- .action = TC_ACT_PIPE,
- },
- .queue = i,
- },
- };
- if (add_actions(rss_flow, 1, &adata, TCA_BPF_ACT) < 0)
- return -1;
- }
- tap_nlattr_nested_finish(msg); /* nested TCA_OPTIONS */
-
- /* Netlink message is now ready to be sent */
- if (tap_nl_send(pmd->nlsk_fd, &msg->nh) < 0)
- return -1;
- err = tap_nl_recv_ack(pmd->nlsk_fd);
- if (err < 0) {
- TAP_LOG(ERR,
- "Kernel refused TC filter rule creation (%d): %s",
- errno, strerror(errno));
- return err;
- }
- LIST_INSERT_HEAD(&pmd->rss_flows, rss_flow, next);
- }
-
- pmd->rss_enabled = 1;
- return err;
-}
-
-/**
- * Manage bpf RSS keys repository with operations: init, get, release
- *
- * @param[in] cmd
- * Command on RSS keys: init, get, release
- *
- * @param[in, out] key_idx
- * Pointer to RSS Key index (out for get command, in for release command)
- *
- * @return -1 if couldn't get, release or init the RSS keys, 0 otherwise.
- */
-static int bpf_rss_key(enum bpf_rss_key_e cmd, __u32 *key_idx)
-{
- __u32 i;
- int err = 0;
- static __u32 num_used_keys;
- static __u32 rss_keys[MAX_RSS_KEYS] = {KEY_STAT_UNSPEC};
- static __u32 rss_keys_initialized;
- __u32 key;
-
- switch (cmd) {
- case KEY_CMD_GET:
- if (!rss_keys_initialized) {
- err = -1;
- break;
- }
-
- if (num_used_keys == RTE_DIM(rss_keys)) {
- err = -1;
- break;
- }
-
- *key_idx = num_used_keys % RTE_DIM(rss_keys);
- while (rss_keys[*key_idx] == KEY_STAT_USED)
- *key_idx = (*key_idx + 1) % RTE_DIM(rss_keys);
-
- rss_keys[*key_idx] = KEY_STAT_USED;
-
- /*
- * Add an offset to key_idx in order to handle a case of
- * RSS and non RSS flows mixture.
- * If a non RSS flow is destroyed it has an eBPF map
- * index 0 (initialized on flow creation) and might
- * unintentionally remove RSS entry 0 from eBPF map.
- * To avoid this issue, add an offset to the real index
- * during a KEY_CMD_GET operation and subtract this offset
- * during a KEY_CMD_RELEASE operation in order to restore
- * the real index.
- */
- *key_idx += KEY_IDX_OFFSET;
- num_used_keys++;
- break;
-
- case KEY_CMD_RELEASE:
- if (!rss_keys_initialized)
- break;
-
- /*
- * Subtract offset to restore real key index
- * If a non RSS flow is falsely trying to release map
- * entry 0 - the offset subtraction will calculate the real
- * map index as an out-of-range value and the release operation
- * will be silently ignored.
- */
- key = *key_idx - KEY_IDX_OFFSET;
- if (key >= RTE_DIM(rss_keys))
- break;
-
- if (rss_keys[key] == KEY_STAT_USED) {
- rss_keys[key] = KEY_STAT_AVAILABLE;
- num_used_keys--;
- }
- break;
-
- case KEY_CMD_INIT:
- for (i = 0; i < RTE_DIM(rss_keys); i++)
- rss_keys[i] = KEY_STAT_AVAILABLE;
-
- rss_keys_initialized = 1;
- num_used_keys = 0;
- break;
-
- case KEY_CMD_DEINIT:
- for (i = 0; i < RTE_DIM(rss_keys); i++)
- rss_keys[i] = KEY_STAT_UNSPEC;
-
- rss_keys_initialized = 0;
- num_used_keys = 0;
- break;
-
- default:
- break;
- }
-
- return err;
-}
-
-/**
- * Add RSS hash calculations and queue selection
- *
- * @param[in, out] pmd
- * Pointer to internal structure. Used to set/get RSS map fd
- *
- * @param[in] rss
- * Pointer to RSS flow actions
- *
- * @param[out] error
- * Pointer to error reporting if not NULL.
- *
- * @return 0 on success, negative value on failure
- */
-static int rss_add_actions(struct rte_flow *flow, struct pmd_internals *pmd,
- const struct rte_flow_action_rss *rss,
- struct rte_flow_error *error)
-{
- /* 4096 is the maximum number of instructions for a BPF program */
- unsigned int i;
- int err;
- struct rss_key rss_entry = { .hash_fields = 0,
- .key_size = 0 };
-
- /* Check supported RSS features */
- if (rss->func != RTE_ETH_HASH_FUNCTION_DEFAULT)
- return rte_flow_error_set
- (error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
- "non-default RSS hash functions are not supported");
- if (rss->level)
- return rte_flow_error_set
- (error, ENOTSUP, RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
- "a nonzero RSS encapsulation level is not supported");
-
- /* Get a new map key for a new RSS rule */
- err = bpf_rss_key(KEY_CMD_GET, &flow->key_idx);
- if (err < 0) {
- rte_flow_error_set(
- error, EINVAL, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Failed to get BPF RSS key");
-
- return -1;
- }
-
- /* Update RSS map entry with queues */
- rss_entry.nb_queues = rss->queue_num;
- for (i = 0; i < rss->queue_num; i++)
- rss_entry.queues[i] = rss->queue[i];
- rss_entry.hash_fields =
- (1 << HASH_FIELD_IPV4_L3_L4) | (1 << HASH_FIELD_IPV6_L3_L4);
-
- /* Add this RSS entry to map */
- err = tap_flow_bpf_update_rss_elem(pmd->map_fd,
- &flow->key_idx, &rss_entry);
-
- if (err) {
- TAP_LOG(ERR,
- "Failed to update BPF map entry #%u (%d): %s",
- flow->key_idx, errno, strerror(errno));
- rte_flow_error_set(
- error, ENOTSUP, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Kernel too old or not configured "
- "to support BPF maps updates");
-
- return -ENOTSUP;
- }
-
-
- /*
- * Load bpf rules to calculate hash for this key_idx
- */
-
- flow->bpf_fd[SEC_L3_L4] =
- tap_flow_bpf_calc_l3_l4_hash(flow->key_idx, pmd->map_fd);
- if (flow->bpf_fd[SEC_L3_L4] < 0) {
- TAP_LOG(ERR,
- "Failed to load BPF section %s (%d): %s",
- sec_name[SEC_L3_L4], errno, strerror(errno));
- rte_flow_error_set(
- error, ENOTSUP, RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
- "Kernel too old or not configured "
- "to support BPF program loading");
-
- return -ENOTSUP;
- }
-
- /* Actions */
- {
- struct action_data adata[] = {
- {
- .id = "bpf",
- .bpf = {
- .bpf_fd = flow->bpf_fd[SEC_L3_L4],
- .annotation = sec_name[SEC_L3_L4],
- .bpf = {
- .action = TC_ACT_PIPE,
- },
- },
- },
- };
-
- if (add_actions(flow, RTE_DIM(adata), adata,
- TCA_FLOWER_ACT) < 0)
- return -1;
- }
-
- return 0;
-}
-
/**
* Get rte_flow operations.
*
diff --git a/drivers/net/tap/tap_flow.h b/drivers/net/tap/tap_flow.h
index 240fbc3dfaef..099704437b2f 100644
--- a/drivers/net/tap/tap_flow.h
+++ b/drivers/net/tap/tap_flow.h
@@ -41,11 +41,6 @@ enum implicit_rule_index {
TAP_REMOTE_MAX_IDX,
};
-enum bpf_fd_idx {
- SEC_L3_L4,
- SEC_MAX,
-};
-
int tap_dev_flow_ops_get(struct rte_eth_dev *dev,
const struct rte_flow_ops **ops);
int tap_flow_flush(struct rte_eth_dev *dev, struct rte_flow_error *error);
@@ -56,11 +51,4 @@ int tap_flow_implicit_destroy(struct pmd_internals *pmd,
enum implicit_rule_index idx);
int tap_flow_implicit_flush(struct pmd_internals *pmd,
struct rte_flow_error *error);
-
-int tap_flow_bpf_cls_q(__u32 queue_idx);
-int tap_flow_bpf_calc_l3_l4_hash(__u32 key_idx, int map_fd);
-int tap_flow_bpf_rss_map_create(unsigned int key_size, unsigned int value_size,
- unsigned int max_entries);
-int tap_flow_bpf_update_rss_elem(int fd, void *key, void *value);
-
#endif /* _TAP_FLOW_H_ */
diff --git a/drivers/net/tap/tap_tcmsgs.h b/drivers/net/tap/tap_tcmsgs.h
index a64cb29d6fa8..4b0413579749 100644
--- a/drivers/net/tap/tap_tcmsgs.h
+++ b/drivers/net/tap/tap_tcmsgs.h
@@ -14,9 +14,6 @@
#include <linux/tc_act/tc_mirred.h>
#include <linux/tc_act/tc_gact.h>
#include <linux/tc_act/tc_skbedit.h>
-#ifdef HAVE_TC_ACT_BPF
-#include <linux/tc_act/tc_bpf.h>
-#endif
#include <inttypes.h>
#include <rte_ether.h>
--
2.43.0
^ permalink raw reply [relevance 1%]
* Re: [RFC] ethdev: fast path async flow API
@ 2023-12-27 17:39 3% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-12-27 17:39 UTC (permalink / raw)
To: Dariusz Sosnowski
Cc: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko, Ori Kam, dev
On Wed, 27 Dec 2023 12:57:09 +0200
Dariusz Sosnowski <dsosnowski@nvidia.com> wrote:
> **Future considerations**
>
> A case can be made about converting some of the existing
> stable API functions to fast path versions in future LTS releases.
> I don't have any hard data on how such changes would affect performance of
> these APIs, but I assume that the improvement would be noticeable.
The problem is that inline functions create future ABI problems.
Usually, there are other ways to get the same performance benefit.
Often batching updates to hardware will do the trick.
^ permalink raw reply [relevance 3%]
* RE: [RFC] ethdev: fast path async flow API
@ 2023-12-28 13:53 3% ` Dariusz Sosnowski
2023-12-28 14:10 0% ` Ivan Malov
0 siblings, 1 reply; 200+ results
From: Dariusz Sosnowski @ 2023-12-28 13:53 UTC (permalink / raw)
To: Stephen Hemminger
Cc: NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, Ori Kam, dev
Hi Stephen,
> > +/**
> > + * @internal
> > + *
> > + * Fast path async flow functions and related data are held in a flat array,
> one entry per ethdev.
> > + * It is assumed that each entry is read-only and cache aligned.
> > + */
> > +struct rte_flow_fp_ops {
> > + void *ctx;
> > + rte_flow_async_create_t async_create;
> > + rte_flow_async_create_by_index_t async_create_by_index;
> > + rte_flow_async_actions_update_t async_actions_update;
> > + rte_flow_async_destroy_t async_destroy;
> > + rte_flow_push_t push;
> > + rte_flow_pull_t pull;
> > + rte_flow_async_action_handle_create_t async_action_handle_create;
> > + rte_flow_async_action_handle_destroy_t async_action_handle_destroy;
> > + rte_flow_async_action_handle_update_t async_action_handle_update;
> > + rte_flow_async_action_handle_query_t async_action_handle_query;
> > + rte_flow_async_action_handle_query_update_t
> async_action_handle_query_update;
> > + rte_flow_async_action_list_handle_create_t
> async_action_list_handle_create;
> > + rte_flow_async_action_list_handle_destroy_t
> async_action_list_handle_destroy;
> > + rte_flow_async_action_list_handle_query_update_t
> async_action_list_handle_query_update;
> > +} __rte_cache_aligned;
>
> If you go ahead with this then all usage should be const pointer.
> Still think it is bad idea and creates even more technical debt.
Could you please elaborate a bit more on why do you think it is a bad idea and why it creates technical debt?
> > **Future considerations**
> >
> > A case can be made about converting some of the existing stable API
> > functions to fast path versions in future LTS releases.
> > I don't have any hard data on how such changes would affect
> > performance of these APIs, but I assume that the improvement would be noticeable.
>
> The problem is that inline functions create future ABI problems.
Agreed, this is why such a change can only be introduced when a new major ABI version is released.
However, even though inlining could reduce function call overhead, I'm not sure if such a change is needed for synchronous flow API.
I mentioned it here as a thing to consider.
> Usually, there are other ways to get the same performance benefit.
> Often batching updates to hardware will do the trick.
This is true, but we still have some library-level overhead.
To elaborate more, the current state of flow API is as follows:
- With sync flow API:
- Applications cannot batch flow operations.
- With async flow APIs:
- Applications can enqueue multiple flow operations and PMDs can issue batches to HW.
- But there is still one function call per enqueued flow operation.
The overall API overhead in datapath may be nonnegligible if we consider that applications may enqueue a flow rule creation operation for every packet received in SW.
This proposal specifically aims at reducing API overhead for async flow API in a case mentioned above.
As a side note, we plan to push changes to mlx5 PMD in 24.03 which will reduce PMD overhead in such scenarios.
This proposal's goal is to reduce overhead of async flow API at library level.
Best regards,
Dariusz Sosnowski
^ permalink raw reply [relevance 3%]
* RE: [RFC] ethdev: fast path async flow API
2023-12-28 13:53 3% ` Dariusz Sosnowski
@ 2023-12-28 14:10 0% ` Ivan Malov
0 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2023-12-28 14:10 UTC (permalink / raw)
To: Dariusz Sosnowski
Cc: Stephen Hemminger, NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, Ori Kam, dev
Hi Dariusz,
I appreciate the proposal. You say that a reference PMD implementation
will be made available for 24.03 release. What about the applications?
Is this supposed to go to upstream code of some applications?
Thank you.
On Thu, 28 Dec 2023, Dariusz Sosnowski wrote:
> Hi Stephen,
>
>>> +/**
>>> + * @internal
>>> + *
>>> + * Fast path async flow functions and related data are held in a flat array,
>> one entry per ethdev.
>>> + * It is assumed that each entry is read-only and cache aligned.
>>> + */
>>> +struct rte_flow_fp_ops {
>>> + void *ctx;
>>> + rte_flow_async_create_t async_create;
>>> + rte_flow_async_create_by_index_t async_create_by_index;
>>> + rte_flow_async_actions_update_t async_actions_update;
>>> + rte_flow_async_destroy_t async_destroy;
>>> + rte_flow_push_t push;
>>> + rte_flow_pull_t pull;
>>> + rte_flow_async_action_handle_create_t async_action_handle_create;
>>> + rte_flow_async_action_handle_destroy_t async_action_handle_destroy;
>>> + rte_flow_async_action_handle_update_t async_action_handle_update;
>>> + rte_flow_async_action_handle_query_t async_action_handle_query;
>>> + rte_flow_async_action_handle_query_update_t
>> async_action_handle_query_update;
>>> + rte_flow_async_action_list_handle_create_t
>> async_action_list_handle_create;
>>> + rte_flow_async_action_list_handle_destroy_t
>> async_action_list_handle_destroy;
>>> + rte_flow_async_action_list_handle_query_update_t
>> async_action_list_handle_query_update;
>>> +} __rte_cache_aligned;
>>
>> If you go ahead with this then all usage should be const pointer.
>> Still think it is bad idea and creates even more technical debt.
> Could you please elaborate a bit more on why do you think it is a bad idea and why it creates technical debt?
>
>>> **Future considerations**
>>>
>>> A case can be made about converting some of the existing stable API
>>> functions to fast path versions in future LTS releases.
>>> I don't have any hard data on how such changes would affect
>>> performance of these APIs, but I assume that the improvement would be noticeable.
>>
>> The problem is that inline functions create future ABI problems.
> Agreed, this is why such a change can only be introduced when a new major ABI version is released.
> However, even though inlining could reduce function call overhead, I'm not sure if such a change is needed for synchronous flow API.
> I mentioned it here as a thing to consider.
>
>> Usually, there are other ways to get the same performance benefit.
>> Often batching updates to hardware will do the trick.
> This is true, but we still have some library-level overhead.
> To elaborate more, the current state of flow API is as follows:
> - With sync flow API:
> - Applications cannot batch flow operations.
> - With async flow APIs:
> - Applications can enqueue multiple flow operations and PMDs can issue batches to HW.
> - But there is still one function call per enqueued flow operation.
> The overall API overhead in datapath may be nonnegligible if we consider that applications may enqueue a flow rule creation operation for every packet received in SW.
> This proposal specifically aims at reducing API overhead for async flow API in a case mentioned above.
>
> As a side note, we plan to push changes to mlx5 PMD in 24.03 which will reduce PMD overhead in such scenarios.
> This proposal's goal is to reduce overhead of async flow API at library level.
>
> Best regards,
> Dariusz Sosnowski
>
^ permalink raw reply [relevance 0%]
* Issues around packet capture when secondary process is doing rx/tx
@ 2024-01-08 1:59 3% Stephen Hemminger
2024-01-08 10:41 0% ` Morten Brørup
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Stephen Hemminger @ 2024-01-08 1:59 UTC (permalink / raw)
To: dev; +Cc: arshdeep.kaur, Gowda, Sandesh, Reshma Pattan
I have been looking at a problem reported by Sandesh
where packet capture does not work if rx/tx burst is done in secondary process.
The root cause is that existing rx/tx callback model just doesn't work
unless the process doing the rx/tx burst calls is the same one that
registered the callbacks.
An example sequence would be:
1. dumpcap (or pdump) as secondary tells pdump in primary to register callback
2. secondary process calls rx_burst.
3. rx_burst sees the callback but it has pointer pdump_rx which is not necessarily
at same location in primary and secondary process.
4. indirect function call in secondary to bad location likely causes crash.
Some possible workarounds.
1. Keep callback list per-process: messy, but won't crash. Capture won't work
without other changes. In this primary would register callback, but secondaries
would not use them in rx/tx burst.
2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have
a capture flag. (i.e. don't use indirection). Likely ABI problems.
Basically, ignore the rx/tx callback mechanism. This is my preferred
solution.
3. Some fix up mechanism (in EAL mp support?) to have each process fixup
its callback mechanism.
4. Do something in pdump_init to register the callback in same process context
(probably need callbacks to be per-process). Would mean callback is always
on independent of capture being enabled.
5. Get rid of indirect function call pointer, and replace it by index into
a static table of callback functions. Every process would have same code
(in this case pdump_rx) but at different address. Requires all callbacks
to be statically defined at build time.
The existing rx/tx callback is not safe id rx/tx burst is called from different process
than where callback is registered.
^ permalink raw reply [relevance 3%]
* RE: Issues around packet capture when secondary process is doing rx/tx
2024-01-08 1:59 3% Issues around packet capture when secondary process is doing rx/tx Stephen Hemminger
@ 2024-01-08 10:41 0% ` Morten Brørup
2024-01-08 15:13 0% ` Konstantin Ananyev
2024-01-09 1:30 0% ` Honnappa Nagarahalli
2 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2024-01-08 10:41 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: arshdeep.kaur, Gowda, Sandesh, Reshma Pattan
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, 8 January 2024 02.59
>
> I have been looking at a problem reported by Sandesh
> where packet capture does not work if rx/tx burst is done in secondary
> process.
>
> The root cause is that existing rx/tx callback model just doesn't work
> unless the process doing the rx/tx burst calls is the same one that
> registered the callbacks.
So, callbacks don't work across processes, because code might differ across processes.
If process A is running, and RX'ing and TX'ing, and process B wants to install its own callbacks (e.g. packet capture) on RX and RX, we basically want process A to execute code residing in process B, which is impossible.
An alternative could be to pass the packets through a ring in shared memory. However, this method would add the ring processing latency of process B to the RX/TX latency of process A.
I think we can conclude that callbacks are one of the things that don't work with secondary processes.
With this decided, we can then consider how to best add packet capture. The concept of passing "data" (instead of calling functions) across processes obviously applies to this use case.
>
> An example sequence would be:
> 1. dumpcap (or pdump) as secondary tells pdump in primary to
> register callback
> 2. secondary process calls rx_burst.
> 3. rx_burst sees the callback but it has pointer pdump_rx which
> is not necessarily
> at same location in primary and secondary process.
> 4. indirect function call in secondary to bad location likely
> causes crash.
>
> Some possible workarounds.
> 1. Keep callback list per-process: messy, but won't crash.
> Capture won't work
> without other changes. In this primary would register
> callback, but secondaries
> would not use them in rx/tx burst.
>
> 2. Replace use of rx/tx callback in pdump with change to
> rte_ethdev to have
> a capture flag. (i.e. don't use indirection). Likely ABI
> problems.
> Basically, ignore the rx/tx callback mechanism. This is my
> preferred
> solution.
>
> 3. Some fix up mechanism (in EAL mp support?) to have each
> process fixup
> its callback mechanism.
>
> 4. Do something in pdump_init to register the callback in same
> process context
> (probably need callbacks to be per-process). Would mean
> callback is always
> on independent of capture being enabled.
>
> 5. Get rid of indirect function call pointer, and replace it by
> index into
> a static table of callback functions. Every process would
> have same code
> (in this case pdump_rx) but at different address. Requires
> all callbacks
> to be statically defined at build time.
>
> The existing rx/tx callback is not safe id rx/tx burst is called from
> different process
> than where callback is registered.
>
^ permalink raw reply [relevance 0%]
* RE: Issues around packet capture when secondary process is doing rx/tx
2024-01-08 1:59 3% Issues around packet capture when secondary process is doing rx/tx Stephen Hemminger
2024-01-08 10:41 0% ` Morten Brørup
@ 2024-01-08 15:13 0% ` Konstantin Ananyev
2024-01-08 17:02 0% ` Stephen Hemminger
2024-01-09 1:30 0% ` Honnappa Nagarahalli
2 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2024-01-08 15:13 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: arshdeep.kaur, Gowda, Sandesh, Reshma Pattan
> I have been looking at a problem reported by Sandesh
> where packet capture does not work if rx/tx burst is done in secondary process.
>
> The root cause is that existing rx/tx callback model just doesn't work
> unless the process doing the rx/tx burst calls is the same one that
> registered the callbacks.
>
> An example sequence would be:
> 1. dumpcap (or pdump) as secondary tells pdump in primary to register callback
> 2. secondary process calls rx_burst.
> 3. rx_burst sees the callback but it has pointer pdump_rx which is not necessarily
> at same location in primary and secondary process.
> 4. indirect function call in secondary to bad location likely causes crash.
As I remember, RX/TX callbacks were never intended to work over multiple processes.
Right now RX/TX callbacks are private for the process, different process simply should not
see/execute them.
I.E. it callbacks list is part of 'struct rte_eth_dev' itself, not the rte_eth_dev.data that is shared
between processes.
It should be normal, wehn for the same port/queue you will end-up with different list of callbacks
for different processes.
So, unless I am missing something, I don't see how we can end-up with 3) and 4) from above:
From my understanding secondary process will never see/call primary's callbacks.
About pdump itself, it was a while when I looked at it last time, but as I remember to start it to work,
server process has to call rte_pdump_init() which in terns register PDUMP_MP handler.
I suppose for the secondary process to act as a 'pdump server' it needs to call rte_pdump_init() itself,
though I am not sure such option is supported right now.
>
> Some possible workarounds.
> 1. Keep callback list per-process: messy, but won't crash. Capture won't work
> without other changes. In this primary would register callback, but secondaries
> would not use them in rx/tx burst.
>
> 2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have
> a capture flag. (i.e. don't use indirection). Likely ABI problems.
> Basically, ignore the rx/tx callback mechanism. This is my preferred
> solution.
It is not only the capture flag, it is also what to do with the captured packets
(copy? If yes, then where to? examine? drop?, do something else?).
It is probably not the best choice to add all these things into ethdev API.
> 3. Some fix up mechanism (in EAL mp support?) to have each process fixup
> its callback mechanism.
Probably the easiest way to fix that - pass to rte_pdump_enable() extra information
that would allow it to distinguish on what exact process (local, remote)
we want to enable pdump functionality. Then it could act accordingly.
>
> 4. Do something in pdump_init to register the callback in same process context
> (probably need callbacks to be per-process). Would mean callback is always
> on independent of capture being enabled.
>
> 5. Get rid of indirect function call pointer, and replace it by index into
> a static table of callback functions. Every process would have same code
> (in this case pdump_rx) but at different address. Requires all callbacks
> to be statically defined at build time.
Doesn't look like a good approach - it will break many things.
> The existing rx/tx callback is not safe id rx/tx burst is called from different process
> than where callback is registered.
^ permalink raw reply [relevance 0%]
* Re: Issues around packet capture when secondary process is doing rx/tx
2024-01-08 15:13 0% ` Konstantin Ananyev
@ 2024-01-08 17:02 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2024-01-08 17:02 UTC (permalink / raw)
To: Konstantin Ananyev; +Cc: dev, arshdeep.kaur, Gowda, Sandesh, Reshma Pattan
On Mon, 8 Jan 2024 15:13:25 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:
> >
> > 2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have
> > a capture flag. (i.e. don't use indirection). Likely ABI problems.
> > Basically, ignore the rx/tx callback mechanism. This is my preferred
> > solution.
>
> It is not only the capture flag, it is also what to do with the captured packets
> (copy? If yes, then where to? examine? drop?, do something else?).
> It is probably not the best choice to add all these things into ethdev API.
The part that pdump does is trivial, it just copies and puts in ring.
This will work from any process.
^ permalink raw reply [relevance 0%]
* rte_eth_dev_data reorganization needed
@ 2024-01-08 17:14 3% Stephen Hemminger
2024-01-09 16:58 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2024-01-08 17:14 UTC (permalink / raw)
To: dev
While looking at ethdev (for pdump issues) noticed.
The rte_eth_dev_data structure layout is unorganized.
Lots of holes, fields not arranged in logical groups
and usage could be localized for better cache access.
Obviously, any reorg is ABI break. We should do this for 24.11
^ permalink raw reply [relevance 3%]
* RE: Issues around packet capture when secondary process is doing rx/tx
2024-01-08 1:59 3% Issues around packet capture when secondary process is doing rx/tx Stephen Hemminger
2024-01-08 10:41 0% ` Morten Brørup
2024-01-08 15:13 0% ` Konstantin Ananyev
@ 2024-01-09 1:30 0% ` Honnappa Nagarahalli
2 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2024-01-09 1:30 UTC (permalink / raw)
To: Stephen Hemminger, dev
Cc: arshdeep.kaur, Gowda, Sandesh, Reshma Pattan, nd, nd
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, January 7, 2024 7:59 PM
> To: dev@dpdk.org
> Cc: arshdeep.kaur@intel.com; Gowda, Sandesh <sandesh.gowda@intel.com>;
> Reshma Pattan <reshma.pattan@intel.com>
> Subject: Issues around packet capture when secondary process is doing rx/tx
>
> I have been looking at a problem reported by Sandesh where packet capture
> does not work if rx/tx burst is done in secondary process.
>
> The root cause is that existing rx/tx callback model just doesn't work unless the
> process doing the rx/tx burst calls is the same one that registered the callbacks.
This is not specific to packet capture. This is a generic problem and we should look to solve it generically.
>
> An example sequence would be:
> 1. dumpcap (or pdump) as secondary tells pdump in primary to register
> callback
> 2. secondary process calls rx_burst.
> 3. rx_burst sees the callback but it has pointer pdump_rx which is not
> necessarily
> at same location in primary and secondary process.
> 4. indirect function call in secondary to bad location likely causes crash.
>
> Some possible workarounds.
> 1. Keep callback list per-process: messy, but won't crash. Capture won't
> work
> without other changes. In this primary would register callback, but
> secondaries
> would not use them in rx/tx burst.
>
> 2. Replace use of rx/tx callback in pdump with change to rte_ethdev to
> have
> a capture flag. (i.e. don't use indirection). Likely ABI problems.
> Basically, ignore the rx/tx callback mechanism. This is my preferred
> solution.
>
> 3. Some fix up mechanism (in EAL mp support?) to have each process
> fixup
> its callback mechanism.
Yes, would prefer this. Let the application call additional APIs to register the call backs in secondary process.
>
> 4. Do something in pdump_init to register the callback in same process
> context
> (probably need callbacks to be per-process). Would mean callback is
> always
> on independent of capture being enabled.
>
> 5. Get rid of indirect function call pointer, and replace it by index into
> a static table of callback functions. Every process would have same code
> (in this case pdump_rx) but at different address. Requires all callbacks
> to be statically defined at build time.
>
> The existing rx/tx callback is not safe id rx/tx burst is called from different
> process than where callback is registered.
>
^ permalink raw reply [relevance 0%]
* Re: rte_eth_dev_data reorganization needed
2024-01-08 17:14 3% rte_eth_dev_data reorganization needed Stephen Hemminger
@ 2024-01-09 16:58 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2024-01-09 16:58 UTC (permalink / raw)
To: Stephen Hemminger, dev
Cc: Thomas Monjalon, Jerin Jacob Kollanukkaran, Qi Z Zhang
On 1/8/2024 5:14 PM, Stephen Hemminger wrote:
> While looking at ethdev (for pdump issues) noticed.
> The rte_eth_dev_data structure layout is unorganized.
> Lots of holes, fields not arranged in logical groups
> and usage could be localized for better cache access.
>
For reference following is structure layout [1].
Agree that it can benefit from reorganization.
> Obviously, any reorg is ABI break. We should do this for 24.11
>
It may not be an ABI break, since structure moved to ethdev_driver.h
with recent changes, it is not exposed to user directly anymore.
eth_dev_data is device data and it is not directly involved in the
datapath, although I can see 'rx_mbuf_alloc_failed' stats is updated in
datapath, and some drivers access 'dev_private' in datapath, most of
other fields are configuration related.
So, although I expect changes in eth_dev_data doesn't impact the
performance it needs to be tested and verified.
As this release looks mostly quite, perhaps it can be good time to try
this kind of change, what do you think to start reorg in this release?
[1]
struct rte_eth_dev_data {
char name[64]; /* 0 64 */
/* --- cacheline 1 boundary (64 bytes) --- */
void * * rx_queues; /* 64 8 */
void * * tx_queues; /* 72 8 */
uint16_t nb_rx_queues; /* 80 2 */
uint16_t nb_tx_queues; /* 82 2 */
struct rte_eth_dev_sriov sriov; /* 84 6 */
/* XXX 6 bytes hole, try to pack */
void * dev_private; /* 96 8 */
struct rte_eth_link dev_link __attribute__((__aligned__(8))); /*
104 8 */
/* XXX last struct has 2 bytes of padding */
struct rte_eth_conf dev_conf; /* 112 2280 */
/* XXX last struct has 4 bytes of padding */
/* --- cacheline 37 boundary (2368 bytes) was 24 bytes ago --- */
uint16_t mtu; /* 2392 2 */
/* XXX 2 bytes hole, try to pack */
uint32_t min_rx_buf_size; /* 2396 4 */
uint64_t rx_mbuf_alloc_failed; /* 2400 8 */
struct rte_ether_addr * mac_addrs; /* 2408 8 */
uint64_t mac_pool_sel[128]; /* 2416 1024 */
/* --- cacheline 53 boundary (3392 bytes) was 48 bytes ago --- */
struct rte_ether_addr * hash_mac_addrs; /* 3440 8 */
uint16_t port_id; /* 3448 2 */
uint8_t promiscuous:1; /* 3450: 0 1 */
uint8_t scattered_rx:1; /* 3450: 1 1 */
uint8_t all_multicast:1; /* 3450: 2 1 */
uint8_t dev_started:1; /* 3450: 3 1 */
uint8_t lro:1; /* 3450: 4 1 */
uint8_t dev_configured:1; /* 3450: 5 1 */
uint8_t flow_configured:1; /* 3450: 6 1 */
/* XXX 1 bit hole, try to pack */
uint8_t rx_queue_state[1024]; /* 3451 1024 */
/* --- cacheline 69 boundary (4416 bytes) was 59 bytes ago --- */
uint8_t tx_queue_state[1024]; /* 4475 1024 */
/* XXX 1 byte hole, try to pack */
/* --- cacheline 85 boundary (5440 bytes) was 60 bytes ago --- */
uint32_t dev_flags; /* 5500 4 */
/* --- cacheline 86 boundary (5504 bytes) --- */
int numa_node; /* 5504 4 */
/* XXX 4 bytes hole, try to pack */
struct rte_vlan_filter_conf vlan_filter_conf; /* 5512 512 */
/* --- cacheline 94 boundary (6016 bytes) was 8 bytes ago --- */
struct rte_eth_dev_owner owner; /* 6024 72 */
/* --- cacheline 95 boundary (6080 bytes) was 16 bytes ago --- */
uint16_t representor_id; /* 6096 2 */
uint16_t backer_port_id; /* 6098 2 */
/* XXX 4 bytes hole, try to pack */
pthread_mutex_t flow_ops_mutex; /* 6104 40 */
/* size: 6144, cachelines: 96, members: 32 */
/* sum members: 6126, holes: 5, sum holes: 17 */
/* sum bitfield members: 7 bits, bit holes: 1, sum bit holes: 1 bits */
/* paddings: 2, sum paddings: 6 */
/* forced alignments: 1 */
} __attribute__((__aligned__(64)));
^ permalink raw reply [relevance 3%]
* Re: [PATCH] build: fix linker warnings about undefined symbols
@ 2024-01-11 9:48 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2024-01-11 9:48 UTC (permalink / raw)
To: Morten Brørup; +Cc: Tyler Retzlaff, dev
On Thu, Jan 11, 2024 at 10:38:05AM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Wednesday, 10 January 2024 17.58
> >
> > On Wed, Jan 10, 2024 at 03:01:03PM +0000, Bruce Richardson wrote:
> > > The default behaviour of "ld.lld" has changed, so it now prints out
> > > warnings about entries in the version.map file which don't exist in
> > > the current build. Since we use our version.map file simply to filter
> > > out the functions we don't want made public, we include in it all
> > > functions across all OS's and builds that we want public if present.
> > > This causes these ld warnings to be emitted, e.g. on BSD, which is
> > > missing functionality found on Linux. For example:
> > >
> > > * hpet functions in EAL
> > > * regexdev enqueue and dequeue burst
> > > * eventdev event_timer functions
> > >
> > > Easiest solution, without major rework of how we use our version.map
> > > files, and without dynamically generating them per-build, is to pass
> > > the --undefined-version flag to the linker, to restore the old
> > > behaviour.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > ---
> >
> > Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >
> > i don't know if has ever been discussed but a way to achieve a similar
> > outcome would be to introduce a visibility macro allowing the data and
> > function symbols to be explicitly made visible while making the build
> > default hidden.
> >
> > https://gcc.gnu.org/wiki/Visibility
>
> This looks interesting!
> Declaring a function "public" directly in its header seems much simpler to manage than having to add it to the version.map file too.
>
> I wonder if function versioning is still supported if using this instead of version.map files?
> Of if there are other relevant reasons for continuing to use the version.map files instead of this?
>
I don't see in that wiki page and details of how to mark symbols with
different ABI versions. For example, as well as listing what functions are
public, our version.map files also identify the ABI version (e.g. DPDK_24)
they belong to, or whether they are experimental or internal. Having them
all in the version file also makes it easy to see how many experimental
functions we have in each component.
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s
@ 2024-01-11 11:35 3% ` Ferruh Yigit
2024-01-11 12:21 0% ` Maryam Tahhan
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2024-01-11 11:35 UTC (permalink / raw)
To: Maryam Tahhan, stephen, lihuisong, fengchengwen, liuyonglong,
david.marchand
Cc: dev, Ciara Loftus, Shibin Koikkara Reeny, Kevin Traynor, Luca Boccassi
On 1/11/2024 9:01 AM, Maryam Tahhan wrote:
> On 10/01/2024 15:21, Ferruh Yigit wrote:
>> On 1/10/2024 2:58 PM, Maryam Tahhan wrote:
>>> Hi folks
>>>
>>> Just wondering if there's any other comments re this patch after all the
>>> review comments were addressed?
>>>
>> Hi Maryam,
>>
>> There was a request from David, to the previous version, that fixes
>> (either to code or document) should be separated into its own patch, so
>> that they can be merged to our LTS (say 21.11.x) releases, to make sure
>> LTS release has correct info/code. On top of it your changes can be
>> another patch.
>>
>> As document completely changed, it is not easy for me to say, can you
>> please confirm that there is no fix to the documentation unrelated with
>> your code change?
>>
> Hey Ferruh
>
> Yes - I should've clarified. I took David's comments into consideration.
> The old use_cni implementation is broken (so if a DPDK pod wants
> multiple AF_XDP interfaces it will not work). So IMHO it doesn't make
> sense to patch documentation for something that is broken. The whole
> change would need to be back ported to LTS.
>
Devarg is user interface, changing it impacts the user.
Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
when user upgrades DPDK to '22.11.4', which is not expected.
dev_arg is not API/ABI but as it impacts the user, it is in the gray
area to backport to the LTS release.
Current patch doesn't have Fixes tag or stable tag, so it doesn't
request to be backported to LTS release. I took this as an improvement,
more than a fix.
As far as I understand existing code (that use 'use_cni' dev_arg)
supports only single netdev, this patch adds support for multiple netdevs.
So what do you think keep LTS with 'use_cni' dev_arg, is there a
requirement to update LTS release?
If so, can it be an option to keep 'use_cni' for backward compatibility
but add only add 'uds_path' and remove 'use_cni' in next LTS?
>
> However, I have a second change to apply on top of this - so I will send
> a series. So please hold off merging for now.
>
> BR
> Maryam
>
^ permalink raw reply [relevance 3%]
* Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s
2024-01-11 11:35 3% ` Ferruh Yigit
@ 2024-01-11 12:21 0% ` Maryam Tahhan
2024-01-11 13:28 0% ` Kevin Traynor
2024-01-11 14:21 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Maryam Tahhan @ 2024-01-11 12:21 UTC (permalink / raw)
To: Ferruh Yigit, stephen, lihuisong, fengchengwen, liuyonglong,
david.marchand
Cc: dev, Ciara Loftus, Shibin Koikkara Reeny, Kevin Traynor, Luca Boccassi
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
On 11/01/2024 11:35, Ferruh Yigit wrote:
> Devarg is user interface, changing it impacts the user.
>
> Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
> when user upgrades DPDK to '22.11.4', which is not expected.
>
> dev_arg is not API/ABI but as it impacts the user, it is in the gray
> area to backport to the LTS release.
Fair enough
>
>
> Current patch doesn't have Fixes tag or stable tag, so it doesn't
> request to be backported to LTS release. I took this as an improvement,
> more than a fix.
This was overlooked by me apologies. It's been a while since I've
contributed to DPDK and I must've missed this detail in the contribution
guide.
> As far as I understand existing code (that use 'use_cni' dev_arg)
> supports only single netdev, this patch adds support for multiple netdevs.
The use_cni implementation will no longer work with the AF_XDP DP as the
use_cni was originally implemented as it has hard coded what's now an
incorrect path for the UDS.
>
> So what do you think keep LTS with 'use_cni' dev_arg, is there a
> requirement to update LTS release?
> If so, can it be an option to keep 'use_cni' for backward compatibility
> but add only add 'uds_path' and remove 'use_cni' in next LTS?
Yeah we can go back to the version of the patch that had the 'use_cni'
flag that was used in combination with the path argument. We can add
better documentation re the "use_cni" misnomer... What we can then do is
if no path argument is set by the user assume their intent and and
generate the path internally in the AF_XDP PMD (which was suggested by
Shibin at some stage). That way there should be no surprises to the End
User.
Long term I would like to keep a (renamed) path argument (in case the
path does ever change from the AF_XDP DP POV) and use it also in
combination with another (maybe boolean) param for passing pinned bpf
maps rather than another separate path.
WDYT? Would this work for the LTS release?
[-- Attachment #2: Type: text/html, Size: 2825 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s
2024-01-11 12:21 0% ` Maryam Tahhan
@ 2024-01-11 13:28 0% ` Kevin Traynor
2024-01-11 14:21 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2024-01-11 13:28 UTC (permalink / raw)
To: Maryam Tahhan, Ferruh Yigit, stephen, lihuisong, fengchengwen,
liuyonglong, david.marchand
Cc: dev, Ciara Loftus, Shibin Koikkara Reeny, Luca Boccassi
On 11/01/2024 12:21, Maryam Tahhan wrote:
> On 11/01/2024 11:35, Ferruh Yigit wrote:
>> Devarg is user interface, changing it impacts the user.
>>
>> Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
>> when user upgrades DPDK to '22.11.4', which is not expected.
>>
>> dev_arg is not API/ABI but as it impacts the user, it is in the gray
>> area to backport to the LTS release.
> Fair enough
>>
>>
>> Current patch doesn't have Fixes tag or stable tag, so it doesn't
>> request to be backported to LTS release. I took this as an improvement,
>> more than a fix.
>
> This was overlooked by me apologies. It's been a while since I've
> contributed to DPDK and I must've missed this detail in the contribution
> guide.
>> As far as I understand existing code (that use 'use_cni' dev_arg)
>> supports only single netdev, this patch adds support for multiple netdevs.
>
> The use_cni implementation will no longer work with the AF_XDP DP as the
> use_cni was originally implemented as it has hard coded what's now an
> incorrect path for the UDS.
>
>>
>> So what do you think keep LTS with 'use_cni' dev_arg, is there a
>> requirement to update LTS release?
>> If so, can it be an option to keep 'use_cni' for backward compatibility
>> but add only add 'uds_path' and remove 'use_cni' in next LTS?
>
>
> Yeah we can go back to the version of the patch that had the 'use_cni'
> flag that was used in combination with the path argument. We can add
> better documentation re the "use_cni" misnomer... What we can then do is
> if no path argument is set by the user assume their intent and and
> generate the path internally in the AF_XDP PMD (which was suggested by
> Shibin at some stage). That way there should be no surprises to the End
> User.
>
That plan sounds like it wouldn't impact a user upgrading from 23.11.0
to 23.11.X which is always the main concern.
> Long term I would like to keep a (renamed) path argument (in case the
> path does ever change from the AF_XDP DP POV) and use it also in
> combination with another (maybe boolean) param for passing pinned bpf
> maps rather than another separate path.
>
> WDYT? Would this work for the LTS release?
>
>
Is it needed on LTS branch? If the current limitation was an oversight
or it's not really usable as intended, then I'd say yes. If not, then
please consider the questions in
http://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-be-backported
Seems like it's for
Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
so it would be only relevant for 23.11 only, so 23.11 maintainer (TBC)
should ack.
I suggest if you feel it should be backported, add the Fixes: and stable
tags, and 23.11 maintainer can review at some point before backport.
thanks,
Kevin.
^ permalink raw reply [relevance 0%]
* Re: [v7 1/1] net/af_xdp: fix multi interface support for K8s
2024-01-11 12:21 0% ` Maryam Tahhan
2024-01-11 13:28 0% ` Kevin Traynor
@ 2024-01-11 14:21 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2024-01-11 14:21 UTC (permalink / raw)
To: Maryam Tahhan, stephen, lihuisong, fengchengwen, liuyonglong,
david.marchand
Cc: dev, Ciara Loftus, Shibin Koikkara Reeny, Kevin Traynor, Luca Boccassi
On 1/11/2024 12:21 PM, Maryam Tahhan wrote:
> On 11/01/2024 11:35, Ferruh Yigit wrote:
>> Devarg is user interface, changing it impacts the user.
>>
>> Assume that user of '22.11.3' using 'use_cni' dev_arg, it will be broken
>> when user upgrades DPDK to '22.11.4', which is not expected.
>>
>> dev_arg is not API/ABI but as it impacts the user, it is in the gray
>> area to backport to the LTS release.
> Fair enough
>> Current patch doesn't have Fixes tag or stable tag, so it doesn't
>> request to be backported to LTS release. I took this as an improvement,
>> more than a fix.
>
> This was overlooked by me apologies. It's been a while since I've
> contributed to DPDK and I must've missed this detail in the contribution
> guide.
>> As far as I understand existing code (that use 'use_cni' dev_arg)
>> supports only single netdev, this patch adds support for multiple netdevs.
>
> The use_cni implementation will no longer work with the AF_XDP DP as the
> use_cni was originally implemented as it has hard coded what's now an
> incorrect path for the UDS.
>
>> So what do you think keep LTS with 'use_cni' dev_arg, is there a
>> requirement to update LTS release?
>> If so, can it be an option to keep 'use_cni' for backward compatibility
>> but add only add 'uds_path' and remove 'use_cni' in next LTS?
>
>
> Yeah we can go back to the version of the patch that had the 'use_cni'
> flag that was used in combination with the path argument. We can add
> better documentation re the "use_cni" misnomer... What we can then do is
> if no path argument is set by the user assume their intent and and
> generate the path internally in the AF_XDP PMD (which was suggested by
> Shibin at some stage). That way there should be no surprises to the End
> User.
>
Ack, this keeps backward compatibility,
BUT if 'use_cni' is already broken in v23.11 (that is what I understand
from your above comment), means there is no user of it in LTS, and we
can be more pragmatic and replace the dev_args, by backporting this
patch, assuming LTS maintainer is also OK with it.
> Long term I would like to keep a (renamed) path argument (in case the
> path does ever change from the AF_XDP DP POV) and use it also in
> combination with another (maybe boolean) param for passing pinned bpf
> maps rather than another separate path.
>
> WDYT? Would this work for the LTS release?
>
>
^ permalink raw reply [relevance 0%]
Results 12801-13000 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2022-04-20 8:16 [PATCH v1 0/5] Direct re-arming of buffers on receive side Feifei Wang
2023-09-25 3:19 ` [PATCH v13 0/4] Recycle mbufs from Tx queue into Rx queue Feifei Wang
2023-09-25 3:19 3% ` [PATCH v13 1/4] ethdev: add API for mbufs recycle mode Feifei Wang
2022-08-29 15:18 [RFC PATCH 0/3] Split logging out of EAL Bruce Richardson
2023-08-09 13:35 ` [PATCH v8 0/3] Split logging functionality " Bruce Richardson
2023-08-11 12:46 ` David Marchand
2023-10-23 7:37 0% ` David Marchand
2023-01-17 9:10 [PATCH 0/2] add ring telemetry cmds Jie Hai
2023-11-09 10:20 3% ` [RESEND v7 0/3] add telemetry cmds for ring Jie Hai
2023-11-09 10:20 3% ` [RESEND v7 1/3] ring: fix unmatched type definition and usage Jie Hai
2023-11-09 12:26 0% ` lihuisong (C)
2023-03-09 8:56 [RFC 1/2] security: introduce out of place support for inline ingress Nithin Dabilpuram
2023-09-21 2:15 4% ` [PATCH v2 1/3] " Nithin Dabilpuram
2023-03-14 12:48 [PATCH 0/5] fix segment fault when parse args Chengwen Feng
2023-11-05 5:45 ` [PATCH v4 " Chengwen Feng
2023-11-05 5:45 ` [PATCH v4 1/5] kvargs: add one new process API Chengwen Feng
2023-11-06 3:18 4% ` Stephen Hemminger
2023-11-06 7:13 0% ` fengchengwen
2023-11-06 16:19 0% ` Stephen Hemminger
2023-11-07 3:21 0% ` fengchengwen
2023-03-15 11:00 [PATCH 0/5] support setting and querying RSS algorithms Dongdong Liu
2023-11-01 7:40 3% ` [PATCH v8 00/10] " Jie Hai
2023-11-01 7:40 4% ` [PATCH v8 03/10] ethdev: support setting and querying RSS algorithm Jie Hai
2023-11-01 13:36 3% ` Ferruh Yigit
2023-11-02 6:58 0% ` Jie Hai
2023-11-01 9:44 0% ` [PATCH v8 00/10] support setting and querying RSS algorithms fengchengwen
2023-11-02 8:20 3% ` [PATCH v9 0/9] " Jie Hai
2023-11-02 8:20 3% ` [PATCH v9 1/9] ethdev: overwrite some comment related to RSS Jie Hai
2023-11-02 8:20 4% ` [PATCH v9 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-11-02 13:11 0% ` [PATCH v9 0/9] support setting and querying RSS algorithms Ferruh Yigit
2023-03-29 23:40 [PATCH v12 00/22] Covert static log types in libraries to dynamic Stephen Hemminger
2023-08-21 16:09 ` [PATCH v13 00/21] Convert static log types in libraries to dynamic types Stephen Hemminger
2023-12-04 12:32 0% ` David Marchand
2023-12-05 2:09 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic Stephen Hemminger
2023-12-05 2:09 2% ` [PATCH 17/18] hash: move rte_hash_set_alg out of header file Stephen Hemminger
2023-12-06 10:08 3% ` [PATCH 00/18] Convert static log types in libraries to dynamic David Marchand
2023-04-19 9:54 [RFC PATCH 1/5] eventdev: add power monitoring API on event port Sivaprasad Tummala
2023-10-16 20:57 ` [PATCH v1 1/6] " Sivaprasad Tummala
2023-10-16 20:57 ` [PATCH v1 5/6] power: add eventdev support for power management Sivaprasad Tummala
2023-10-17 3:22 ` Jerin Jacob
2023-10-18 7:08 3% ` Tummala, Sivaprasad
2023-10-18 7:13 0% ` Jerin Jacob
2023-05-09 9:24 [PATCH v6 0/3] add telemetry cmds for ring Jie Hai
2023-07-04 9:04 ` [PATCH v7 " Jie Hai
2023-10-10 2:25 0% ` Jie Hai
2023-10-25 1:22 0% ` Jie Hai
2023-10-28 9:50 0% ` Jie Hai
2023-11-08 2:55 0% ` lihuisong (C)
2023-05-25 20:39 [PATCH] ethdev: validate reserved fields Stephen Hemminger
2023-05-26 8:15 ` Bruce Richardson
2023-09-21 15:12 0% ` Ferruh Yigit
2023-09-21 16:33 0% ` Ferruh Yigit
2023-09-22 15:23 0% ` Ferruh Yigit
2023-06-07 21:00 [PATCH v1] event/dlb2: add support for disabling PASID Abdullah Sevincer
2023-10-30 21:12 ` [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2 Abdullah Sevincer
2023-10-31 8:21 ` Jerin Jacob
2023-10-31 15:13 ` Sevincer, Abdullah
2023-10-31 17:06 ` Jerin Jacob
2023-10-31 17:15 ` Bruce Richardson
2023-10-31 18:42 ` Jerin Jacob
2023-10-31 20:44 ` Bruce Richardson
2023-11-01 4:51 ` Jerin Jacob
2023-11-01 19:05 ` Sevincer, Abdullah
2023-11-02 10:23 4% ` Bruce Richardson
2023-11-02 10:48 0% ` Thomas Monjalon
2023-06-15 16:48 [PATCH v2 0/5] bbdev: API extension for 23.11 Nicolas Chautru
2023-06-15 16:48 ` [PATCH v2 2/5] bbdev: add new capabilities for FFT processing Nicolas Chautru
2023-09-18 15:08 ` Maxime Coquelin
2023-09-18 15:42 0% ` Maxime Coquelin
2023-09-18 20:50 0% ` Chautru, Nicolas
2023-06-15 16:49 ` [PATCH v2 5/5] devtools: ignore changes into bbdev experimental API Nicolas Chautru
2023-09-18 15:22 0% ` Maxime Coquelin
2023-09-21 7:35 0% ` [PATCH v2 0/5] bbdev: API extension for 23.11 Maxime Coquelin
2023-07-05 6:52 [PATCH v2] bus/cdx: provide driver flag for optional resource mapping Abhijit Gangurde
2023-07-11 5:51 ` [PATCH v3] " Abhijit Gangurde
2023-09-29 15:17 3% ` David Marchand
2023-10-04 10:06 0% ` Gangurde, Abhijit
2023-10-04 12:54 0% ` David Marchand
2023-10-13 11:51 0% ` Gangurde, Abhijit
2023-10-13 12:15 0% ` David Marchand
2023-07-16 21:25 [RFC] MAINTAINERS: add status information Stephen Hemminger
2023-10-31 22:08 ` [PATCH 0/3] net/tap: update and fix the BPF program Stephen Hemminger
2023-10-31 22:08 4% ` [PATCH 1/3] net/tap: support infrastructure to build the BPF filter Stephen Hemminger
2023-10-31 22:42 ` [PATCH v5 0/3] net/tap: build and fix for BPF program Stephen Hemminger
2023-10-31 22:42 4% ` [PATCH v5 1/3] net/tap: support infrastructure to build the BPF filter Stephen Hemminger
2023-11-01 18:02 ` [PATCH v6 0/3] net/tap: build and fix for BPF program Stephen Hemminger
2023-11-01 18:02 4% ` [PATCH v6 1/3] net/tap: support infrastructure to build the BPF filter Stephen Hemminger
2023-08-02 21:11 [PATCH 1/2] eal: remove RTE_CPUFLAG_NUMFLAGS Sivaprasad Tummala
2023-08-11 6:07 ` [PATCH v2 1/2] test/cpuflags: removed test for NUMFLAGS Sivaprasad Tummala
2023-08-11 6:07 ` [PATCH v2 2/2] eal: remove NUMFLAGS enumeration Sivaprasad Tummala
2023-08-15 6:10 ` Stanisław Kardach
2023-09-19 14:47 0% ` David Marchand
2023-09-20 6:00 4% ` Stanisław Kardach
2023-09-20 7:34 0% ` David Marchand
2023-09-21 13:18 4% ` Tummala, Sivaprasad
2023-09-21 14:49 4% ` Stanisław Kardach
2023-09-27 11:55 5% ` Ferruh Yigit
2023-09-27 13:48 4% ` Stanisław Kardach
2023-09-27 14:09 0% ` Ferruh Yigit
2023-09-27 15:03 0% ` Stanisław Kardach
2023-09-27 16:13 0% ` Ferruh Yigit
2023-09-27 13:13 0% ` Ferruh Yigit
2023-09-28 9:31 0% ` Tummala, Sivaprasad
2023-10-06 8:27 3% ` David Marchand
2023-10-06 11:19 0% ` Ferruh Yigit
2023-08-02 23:25 [PATCH v4 00/19] replace use of term "sanity check" Stephen Hemminger
2023-11-29 17:25 ` [PATCH v5 00/19] remove use of the " Stephen Hemminger
2023-11-29 17:25 2% ` [PATCH v5 01/19] mbuf: replace term sanity check Stephen Hemminger
2023-08-04 8:28 [PATCH] app/test-pmd: fix L4 checksum with padding data Kaiwen Deng
2023-11-02 19:20 ` Ferruh Yigit
2023-11-16 22:58 ` Stephen Hemminger
2023-11-17 0:50 3% ` Ferruh Yigit
2023-11-17 3:28 0% ` Stephen Hemminger
2023-11-17 9:29 0% ` Ferruh Yigit
2023-11-17 12:11 0% ` Morten Brørup
2023-11-17 16:22 0% ` Stephen Hemminger
2023-11-20 10:47 0% ` Ferruh Yigit
2023-11-20 9:21 0% ` Deng, KaiwenX
2023-11-20 10:46 3% ` Ferruh Yigit
2023-11-22 3:04 0% ` Deng, KaiwenX
2023-08-08 17:35 [PATCH 00/20] remove experimental flag from some API's Stephen Hemminger
2023-08-09 0:09 ` [PATCH v2 00/29] promote many API's to stable Stephen Hemminger
2023-10-18 19:14 0% ` David Marchand
2023-10-18 19:41 3% ` David Marchand
2023-10-19 16:55 3% ` [PATCH v3 00/29] Promote experimental " Stephen Hemminger
2023-10-19 16:55 2% ` [PATCH v3 25/29] compressdev: remove experimental flag Stephen Hemminger
2023-10-19 19:09 3% ` [PATCH v4 00/28] Promote many experimental API's to stable Stephen Hemminger
2023-10-19 19:10 2% ` [PATCH v4 24/28] compressdev: remove experimental flag Stephen Hemminger
2023-10-20 20:57 3% ` [PATCH v5 00/26] Promote many experimental API's to stable Stephen Hemminger
2023-10-20 20:57 2% ` [PATCH v5 22/26] compressdev: remove experimental flag Stephen Hemminger
2023-10-23 9:12 0% ` Bruce Richardson
2023-10-24 2:39 3% ` [PATCH v6 00/25] Promite many experimental API's to stable Stephen Hemminger
2023-10-24 2:53 3% ` [PATCH v7 00/25] Promote 22.11 and older " Stephen Hemminger
2023-10-24 2:54 2% ` [PATCH v7 22/25] compressdev: remove experimental flag Stephen Hemminger
2023-11-13 15:45 0% ` [PATCH v7 00/25] Promote 22.11 and older API's to stable David Marchand
2023-10-24 7:20 0% ` [PATCH 00/20] remove experimental flag from some API's Maxime Coquelin
2023-08-11 1:31 [PATCH 0/6] RFC optional rte optional stdatomics API Tyler Retzlaff
2023-08-22 21:00 ` [PATCH v6 0/6] rte atomics API for optional stdatomic Tyler Retzlaff
2023-09-29 14:09 0% ` David Marchand
2023-08-11 7:17 [RFC PATCH 0/3] add TLS record processing security offload Anoob Joseph
2023-08-11 7:17 ` [RFC PATCH 2/3] security: add TLS record processing Anoob Joseph
2023-09-20 9:23 3% ` Van Haaren, Harry
2023-09-20 11:51 0% ` Anoob Joseph
2023-09-21 8:38 0% ` Van Haaren, Harry
2023-08-11 15:49 [PATCH] devtools: list symbols by version David Marchand
2023-11-15 10:42 3% ` [PATCH v5 1/2] devtools: add check on symbol maps format David Marchand
2023-08-17 10:58 [RFC PATCH] app/test: add support for skipping tests Bruce Richardson
2023-09-14 15:16 ` [PATCH v4] " Bruce Richardson
2023-09-25 16:26 ` Aaron Conole
2023-10-02 9:20 ` David Marchand
2023-10-03 20:22 ` Patrick Robb
2023-10-04 15:13 ` Aaron Conole
2023-10-09 20:03 ` Patrick Robb
2023-10-20 15:02 ` Patrick Robb
2023-10-20 15:08 3% ` Bruce Richardson
2023-08-30 15:52 [PATCH v1 0/3] Spec changes to support multi I/O models Srikanth Yalavarthi
2023-09-27 18:11 ` [PATCH v3 0/4] " Srikanth Yalavarthi
2023-09-27 18:11 4% ` [PATCH v3 4/4] mldev: update release notes for 23.11 Srikanth Yalavarthi
2023-10-02 9:58 ` [PATCH v4 0/3] Spec changes to support multi I/O models Srikanth Yalavarthi
2023-10-02 9:58 2% ` [PATCH v4 1/3] mldev: add support for arbitrary shape dimensions Srikanth Yalavarthi
2023-10-02 9:58 1% ` [PATCH v4 2/3] mldev: introduce support for IO layout Srikanth Yalavarthi
2023-08-30 15:58 [PATCH v1 00/34] Implemenation of revised ml/cnxk driver Srikanth Yalavarthi
2023-10-18 13:53 ` [PATCH v6 00/34] Implementation " Srikanth Yalavarthi
2023-10-18 13:54 ` [PATCH v6 18/34] ml/cnxk: support config and close of tvmdp library Srikanth Yalavarthi
2023-10-18 18:34 5% ` Jerin Jacob
2023-10-19 6:44 0% ` [EXT] " Srikanth Yalavarthi
2023-09-04 7:28 [PATCH 0/5] support setting and querying RSS algorithms Jie Hai
2023-09-08 8:00 ` [PATCH v4 0/7] " Jie Hai
2023-09-08 8:00 ` [PATCH v4 2/7] ethdev: support setting and querying RSS algorithm Jie Hai
2023-09-20 16:39 3% ` Ferruh Yigit
2023-09-26 13:23 0% ` Jie Hai
2023-10-11 9:27 2% ` [PATCH v5 00/40] support setting and querying RSS algorithms Jie Hai
2023-10-11 9:27 4% ` [PATCH v5 02/40] ethdev: support setting and querying RSS algorithm Jie Hai
2023-10-11 17:39 4% ` Stephen Hemminger
2023-10-12 2:21 0% ` fengchengwen
2023-10-12 15:23 0% ` Stephen Hemminger
2023-10-24 12:54 0% ` Jie Hai
2023-10-11 18:19 0% ` [PATCH v5 00/40] support setting and querying RSS algorithms Ferruh Yigit
2023-10-12 16:49 0% ` Stephen Hemminger
2023-10-17 14:06 ` Thomas Monjalon
2023-10-17 14:26 ` Ferruh Yigit
2023-10-24 12:57 3% ` lihuisong (C)
2023-10-26 8:53 0% ` Thomas Monjalon
2023-10-27 9:28 3% ` [PATCH 0/9] " Jie Hai
2023-10-27 9:28 4% ` [PATCH 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-10-28 1:46 3% ` [PATCH v7 0/9] support setting and querying RSS algorithms Jie Hai
2023-10-28 1:46 4% ` [PATCH v7 2/9] ethdev: support setting and querying RSS algorithm Jie Hai
2023-10-28 3:01 3% ` lihuisong (C)
2023-11-01 12:55 5% ` Ferruh Yigit
2023-11-01 2:04 0% ` [PATCH v7 0/9] support setting and querying RSS algorithms Ferruh Yigit
2023-09-04 13:03 [PATCH v3 1/3] lib: introduce dispatcher library Mattias Rönnblom
2023-09-22 7:38 ` [PATCH v4 0/3] Add " Mattias Rönnblom
2023-09-22 7:38 ` [PATCH v4 1/3] lib: introduce " Mattias Rönnblom
2023-09-25 7:11 ` Mattias Rönnblom
2023-09-26 18:28 ` Jerin Jacob
2023-09-27 8:13 3% ` Bruce Richardson
2023-09-28 7:44 0% ` Mattias Rönnblom
2023-10-03 17:31 0% ` Jerin Jacob
2023-09-28 7:30 ` [PATCH v5 0/3] Add " Mattias Rönnblom
2023-09-28 7:30 ` [PATCH v5 1/3] lib: introduce " Mattias Rönnblom
2023-10-05 8:36 ` David Marchand
2023-10-05 10:08 ` Mattias Rönnblom
2023-10-06 8:46 ` David Marchand
2023-10-09 16:49 ` Mattias Rönnblom
2023-10-11 14:57 ` David Marchand
2023-10-11 20:51 3% ` Mattias Rönnblom
2023-09-18 2:45 [PATCH v4 00/26] refact the nfpcore module Chaoyong He
2023-09-19 9:54 ` [PATCH v5 " Chaoyong He
2023-09-19 9:54 1% ` [PATCH v5 02/26] net/nfp: unify the indent coding style Chaoyong He
2023-09-19 9:54 3% ` [PATCH v5 05/26] net/nfp: standard the local variable " Chaoyong He
2023-09-19 9:54 1% ` [PATCH v5 07/26] net/nfp: standard the comment style Chaoyong He
2023-09-19 9:54 5% ` [PATCH v5 18/26] net/nfp: refact the nsp module Chaoyong He
2023-09-20 10:40 [PATCH v2] security: hide security context Akhil Goyal
2023-09-26 7:19 2% ` [PATCH v3] " Akhil Goyal
2023-09-26 8:08 1% ` [PATCH v4] " Akhil Goyal
2023-09-21 4:23 [PATCH 0/4] pcapng fixes Stephen Hemminger
2023-09-21 4:23 ` [PATCH 4/4] pcapng: move timestamp calculation into pdump Stephen Hemminger
2023-10-02 8:15 ` David Marchand
2023-10-04 17:13 ` Stephen Hemminger
2023-10-06 9:10 3% ` David Marchand
2023-10-06 14:59 0% ` Kevin Traynor
2023-09-29 14:15 [PATCH] ci: test stdatomic API David Marchand
2023-10-17 7:15 4% ` [PATCH v2] " David Marchand
2023-10-04 12:59 3% [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code Nithin Dabilpuram
2023-10-10 13:10 0% ` Ferruh Yigit
2023-10-10 14:48 0% ` [EXT] " Akhil Goyal
2023-10-12 9:32 0% ` Ferruh Yigit
2023-10-10 14:50 0% ` Anoob Joseph
2023-10-04 15:11 4% Minutes of Technical Board Meeting, 2023-05-31 Aaron Conole
2023-10-05 11:51 [RFC PATCH] eventdev: ensure 16-byte alignment for events Bruce Richardson
2023-10-05 12:06 3% ` Bruce Richardson
2023-10-05 13:11 0% ` Jerin Jacob
2023-10-05 13:15 ` Bruce Richardson
2023-10-06 7:19 3% ` Jerin Jacob
2023-10-06 9:37 5% ` [PATCH v2] " Bruce Richardson
2023-10-06 9:45 8% ` [PATCH v3] " Bruce Richardson
2023-10-06 10:29 8% ` [PATCH v4] " Bruce Richardson
[not found] <20220825024425.10534-1-lihuisong@huawei.com>
2023-08-02 3:15 ` [PATCH RESEND v6 0/5] app/testpmd: support multiple process attach and detach port Huisong Li
2023-10-09 10:34 0% ` lihuisong (C)
2023-10-30 12:17 0% ` lihuisong (C)
2023-12-08 2:25 0% ` lihuisong (C)
2023-10-13 4:27 [PATCH v2 0/3] example/l3fwd: relax l3fwd rx RSS/Offload if needed Trevor Tao
2023-10-13 4:27 9% ` [PATCH v2 3/3] doc: add a relax rx mode requirement option Trevor Tao
2023-10-17 12:35 3% [PATCH] event/cnxk: fix symbol map David Marchand
2023-10-17 12:38 0% ` [EXT] " Pavan Nikhilesh Bhagavatula
2023-10-17 20:36 4% release candidate 23.11-rc1 Thomas Monjalon
[not found] ` <MW4PR11MB5912D298978501DAC2092EA49FD4A@MW4PR11MB5912.namprd11.prod.outlook.com>
2023-10-27 9:19 0% ` Xu, HailinX
2023-10-31 23:15 0% ` Thinh Tran
2023-10-20 14:19 7% [PATCH] docs: add note about experimental API in LTS Kevin Traynor
2023-11-02 2:23 [PATCH 00/11] Add the support of multiple PF Chaoyong He
2023-11-02 2:23 9% ` [PATCH 04/11] net/nfp: add flag to indicate multiple PFs support Chaoyong He
2023-11-02 18:19 [RFC] eal: RFC to refactor rte_eal_init into sub-functions Rahul Gupta
2023-11-02 18:37 3% ` Stephen Hemminger
2023-11-07 17:33 0% ` rahul gupta
2023-11-08 4:38 0% ` Rahul Gupta
2023-11-15 17:39 [PATCH] RFC: use C11 alignas instead of GCC attribute aligned Tyler Retzlaff
2023-11-15 17:39 ` [PATCH] eal: " Tyler Retzlaff
2023-11-15 20:08 3% ` Morten Brørup
2023-11-15 21:03 0% ` Tyler Retzlaff
2023-11-15 22:43 0% ` Stanisław Kardach
2023-11-15 21:16 [PATCH] eal: fix alignment of RISCV xmm vector type Tyler Retzlaff
2023-11-15 21:31 3% ` Morten Brørup
2023-11-15 23:20 0% ` Stanisław Kardach
2023-11-16 7:45 3% ` Morten Brørup
2023-11-17 10:54 3% ` Bruce Richardson
2023-11-17 11:18 0% ` Morten Brørup
2023-11-18 8:04 3% ` Thomas Monjalon
2023-11-23 8:58 9% [PATCH 1/2] devtools: remove ABI exception for baseband FFT David Marchand
2023-11-23 8:58 9% ` [PATCH 2/2] devtools: remove ABI exception for crypto asym operations David Marchand
2023-11-24 19:39 4% ` [EXT] " Akhil Goyal
2023-11-27 7:35 4% ` David Marchand
2023-11-23 9:36 4% ` [PATCH 1/2] devtools: remove ABI exception for baseband FFT Maxime Coquelin
2023-11-25 16:03 [PATCH v2 1/3] net/octeon_ep: optimize Rx and Tx routines pbhagavatula
2023-12-06 12:12 3% ` Jerin Jacob
2023-12-06 17:24 3% ` [PATCH v3 " pbhagavatula
2023-12-07 6:49 3% ` [PATCH v4 " pbhagavatula
2023-12-11 13:43 3% ` [PATCH v5 " pbhagavatula
2023-11-28 16:15 4% DPDK 23.11 released David Marchand
2023-11-29 15:27 4% [PATCH] doc: add sunset clause for experimental tag Stephen Hemminger
2023-11-29 15:46 0% ` Bruce Richardson
2023-11-29 16:18 11% [PATCH] version: 24.03-rc0 David Marchand
2023-11-30 9:23 3% ` David Marchand
2023-11-30 9:30 0% ` Ferruh Yigit
2023-11-30 9:32 0% ` David Marchand
2023-11-30 18:33 0% ` Patrick Robb
2023-12-06 11:29 [PATCH] cfgfile: increase value length Vipin Varghese
2023-12-06 13:21 ` Bruce Richardson
2023-12-06 13:34 ` Dumitrescu, Cristian
2023-12-06 15:22 3% ` Varghese, Vipin
2023-12-06 15:50 3% ` Bruce Richardson
2023-12-06 16:46 3% ` Varghese, Vipin
2023-12-08 6:18 2% [PATCH] bus/uacce: introduce UACCE bus Chengwen Feng
2023-12-11 7:39 [PATCH 0/2] bugfix and replace on use of stdatomic API Jie Hai
2023-12-11 7:39 ` [PATCH 1/2] eal: fix constraints on " Jie Hai
2023-12-11 18:53 ` Tyler Retzlaff
2023-12-15 2:47 ` Jie Hai
2023-12-15 7:17 3% ` Tyler Retzlaff
2023-12-15 16:31 1% [RFC] net/tap: remove kernel side RSS via BPF Stephen Hemminger
2023-12-22 11:04 [v7 1/1] net/af_xdp: fix multi interface support for K8s Maryam Tahhan
2024-01-10 14:58 ` Maryam Tahhan
2024-01-10 15:21 ` Ferruh Yigit
2024-01-11 9:01 ` Maryam Tahhan
2024-01-11 11:35 3% ` Ferruh Yigit
2024-01-11 12:21 0% ` Maryam Tahhan
2024-01-11 13:28 0% ` Kevin Traynor
2024-01-11 14:21 0% ` Ferruh Yigit
2023-12-27 10:57 [RFC] ethdev: fast path async flow API Dariusz Sosnowski
2023-12-27 17:39 3% ` Stephen Hemminger
2023-12-27 17:41 ` Stephen Hemminger
2023-12-28 13:53 3% ` Dariusz Sosnowski
2023-12-28 14:10 0% ` Ivan Malov
2024-01-08 1:59 3% Issues around packet capture when secondary process is doing rx/tx Stephen Hemminger
2024-01-08 10:41 0% ` Morten Brørup
2024-01-08 15:13 0% ` Konstantin Ananyev
2024-01-08 17:02 0% ` Stephen Hemminger
2024-01-09 1:30 0% ` Honnappa Nagarahalli
2024-01-08 17:14 3% rte_eth_dev_data reorganization needed Stephen Hemminger
2024-01-09 16:58 3% ` Ferruh Yigit
2024-01-10 15:01 [PATCH] build: fix linker warnings about undefined symbols Bruce Richardson
2024-01-10 16:58 ` Tyler Retzlaff
2024-01-11 9:38 ` Morten Brørup
2024-01-11 9:48 4% ` Bruce Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).