From: Ferruh Yigit <ferruh.yigit@amd.com>
To: "Chautru, Nicolas" <nicolas.chautru@intel.com>,
Akhil Goyal <gakhil@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
"ferruh.yigit@xilinx.com" <ferruh.yigit@xilinx.com>,
Ray Kinsella <mdr@ashroe.eu>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
"trix@redhat.com" <trix@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"Zhang, Mingshan" <mingshan.zhang@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>
Subject: Re: [EXT] [PATCH v7 6/7] bbdev: add queue related warning and status information
Date: Tue, 27 Sep 2022 10:43:31 +0100 [thread overview]
Message-ID: <17bacfdd-1326-36e2-5644-bf9dc1938c42@amd.com> (raw)
In-Reply-To: <BY5PR11MB4451BF20D14FB8FC929FF3ACF8509@BY5PR11MB4451.namprd11.prod.outlook.com>
On 9/24/2022 5:34 PM, Chautru, Nicolas wrote:
> Hi Ferruh, Ray, Akhil,
>
>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>>> Sent: Friday, September 23, 2022 4:28 PM
>>> To: Akhil Goyal <gakhil@marvell.com>; Nicolas Chautru
>>> <nicolas.chautru@intel.com>; dev@dpdk.org; thomas@monjalon.net;
>>> hemant.agrawal@nxp.com; Ray Kinsella <mdr@ashroe.eu>
>>> Cc: maxime.coquelin@redhat.com; trix@redhat.com;
>>> bruce.richardson@intel.com; david.marchand@redhat.com;
>>> stephen@networkplumber.org; mingshan.zhang@intel.com
>>> Subject: Re: [EXT] [PATCH v7 6/7] bbdev: add queue related warning and
>>> status information
>>>
>>> On 9/21/2022 8:21 PM, Akhil Goyal wrote:
>>>>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
>>>>> ed528b8..b7ecf94 100644
>>>>> --- a/lib/bbdev/rte_bbdev.h
>>>>> +++ b/lib/bbdev/rte_bbdev.h
>>>>> @@ -224,6 +224,19 @@ struct rte_bbdev_queue_conf {
>>>>> rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id);
>>>>>
>>>>> /**
>>>>> + * Flags indicate the reason why a previous enqueue may not have
>>>>> + * consumed all requested operations
>>>>> + * In case of multiple reasons the latter superdes a previous one
>>>> Spell check - supersedes.
>>>>
>>>>> + */
>>>>> +enum rte_bbdev_enqueue_status {
>>>>> + RTE_BBDEV_ENQ_STATUS_NONE, /**< Nothing to report */
>>>>> + RTE_BBDEV_ENQ_STATUS_QUEUE_FULL, /**< Not enough room
>> in
>>>>> queue */
>>>>> + RTE_BBDEV_ENQ_STATUS_RING_FULL, /**< Not enough room
>> in
>>>>> ring */
>>>>> + RTE_BBDEV_ENQ_STATUS_INVALID_OP, /**< Operation was
>>>>> rejected as invalid */
>>>>> + RTE_BBDEV_ENQ_STATUS_PADDED_MAX = 6, /**< Maximum enq
>>>>> status number including padding */
>>>>
>>>> Are we ok to have this kind of padding across DPDK for all the enums
>>>> to avoid
>>> ABI issues?
>>>> @Ray, @Thomas: any thoughts?
>>>>
>>>>
>>>
>>> This kind of usage can prevent ABI tool warning, and can fix issues
>>> caused by application using returned enum as index [1].
>>>
>>> But I think it is still problematic in case application tries to walk
>>> through till MAX, that is a common usage [2], user may miss that this
>>> is PADDED.
>
> Hi Ferruh,
> I don’t believe that case can happen here. Even if application was using an undefined index, the related functions are protected for that :
> See rte_bbdev_enqueue_status_str(enum rte_bbdev_enqueue_status status)
It doesn't have to use undefined index for DPDK API, application can
iterate until MAX enum for application specific array or function.
> The reason for having padded max, is that the application may use this for array sizing if required without concern, we will never return a value that would exceeds this.
> In the other direction that is not a problem either since application (even it needs to store thigs in array) can used the padded version.
> Note that this discussed with Ray notably as a BKM.
>
I can see usage is more for size, that is why I think it is better to
have a #define that has SIZE_MAX in name, instead of enum with
PADDED_MAX name.
As said above, since you will never return value exceeds PADDED_MAX it
solves the issue that application using returned enum as index [1]. So,
this usage is not that problematic.
But my concern was if user assumes all values valid until PADDED_MAX and
tries to iterate array until that value [2].
>>>
>>> Overall exchanging enum values between library and application is
>>> possible trouble for binary compatibility. If application and library
>>> uses enum values independently, this is OK.
>>> Since enum cases not deleted but added in new version of the
>>> libraries, more problematic usage is passing enum value from library
>>> to application, and bbdev seems doing this in a few places.
>
> I don’t see a case where it is a genuine issue.
> An enum is being reported from library, even if due to future enum insertion there is a new enum reported between 2 ABI changes, that would still be within bounds.
>
Passing enum case from library to application has problem [1], other
issue can be application may miss that library added new enum cases and
application code needs updating.
Overall I think it is not good idea for library to exchange enum values
in APIs, specially if there is an intention to have ABI compatibility.
>>>
>>> With current approach PADDED_MAX usage is more like #define usage, it
>>> is not dynamic but a hardcoded value that is used as array size value.
>>>
>>> Not providing a MAX enum case restricts the application, application
>>> can't use it as size of an array or can't use it walk through related
>>> array, usage reduces to if/switch comparisons.
>
> It can use the padded_max to size application array. Even if application was walking through these, there is no adverse effect.
>
>>> Although this may not be most convenient for application, it can
>>> provide safer usage for binary compatibility.
>>>
>>>
>>> @Nic, what do you think provide these PADDED_MAX as #define SIZE_MAX
>>> macros?
>>> With this application still can allocate a relevant array with correct
>>> size, or know the size of library provided array, but can't use it to
>>> iterate on these arrays.
>>>
>
> That would be back to how it was done before which made things very inflexible and prevented to change these enums between ABIs versions.
>
It would be same, the problem was MAX enum value changing. Removing MAX
enum but introduce #define SIZE_MAX will be same for application.
Only it would be more clear.
> This change was highlighted and discussed many months ago and flagged in the deprecation notice in previous release for that very reason.
>
As far as I remember the deprecation notice was to remove MAX enum
values, now you are introducing PADDED_MAX enum value.
> Ray, can you please chime in since you know best.
>
I think this PADDED_MAX solution is not too problematic, but I prefer
SIZE_MAX define, I hope my reasoning above is clear.
This is a comment from me, not a blocker, I am OK to go with whatever
consensus is.
> Thanks Ferruh,
> Nic
>
>
>
>>>
>>>
>>>
>>> [1]
>>> --------------- library old version ---------------------------- enum
>>> type {
>>> CASE_A,
>>> CASE_B,
>>> CASE_MAX,
>>> };
>>>
>>> struct data {
>>> enum type type;
>>> union {
>>> type specific struct
>>> };
>>> };
>>>
>>> int api_get(struct data *data);
>>>
>>>
>>> --------------- application ----------------------------
>>>
>>> struct data data;
>>> int array[CASE_MAX];
>>>
>>> api_get(&data);
>>> foo(array[data.type]);
>>>
>>>
>>> --------------- library NEW version ----------------------------
>>>
>>> enum type {
>>> CASE_A,
>>> CASE_B,
>>> CASE_C,
>>> CASE_D,
>>> CASE_MAX,
>>> };
>>>
>>>
>>> When application is NOT recompiled but using new version of the
>>> library, values 'CASE_C' & 'CASE_D' will crash application, so this
>>> will create a ABI compatibility issue.
>>>
>>> Note: In the past I have claimed that application should check
>>> 'CASE_MAX', instead of using returned value directly as index, but
>>> this is refused by argument that we can't control the application and
>>> should play safe assuming application behaves wrong.
>>>
>>>
>>>
>>>
>>> [2]
>>>
>>> --------------- library ----------------------------
>>>
>>> enum type {
>>> CASE_NONE,
>>> CASE_A,
>>> CASE_B,
>>> CASE_C,
>>> CASE_D,
>>> CASE_PADDED_MAX = 666,
>>> };
>>>
>>> --------------- application ----------------------------
>>>
>>> for (int i = CASE_NONE; i < CASE_PADDED_MAX; i++)
>>> fragile_init(i);
>>>
>>> ---
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
next prev parent reply other threads:[~2022-09-27 9:43 UTC|newest]
Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 0:22 [PATCH v1 0/2] bbdev: add device info on queue topology Nicolas Chautru
2022-03-09 0:22 ` [PATCH v1 1/2] " Nicolas Chautru
2022-03-09 1:28 ` Stephen Hemminger
2022-03-09 0:22 ` [PATCH v1 2/2] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 0/5] bbdev changes for 22.11 Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 1/5] bbdev: allow operation type enum for growth Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 2/5] bbdev: add device status info Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 3/5] bbdev: add device info on queue topology Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 4/5] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-06-17 18:37 ` [PATCH v2 5/5] bbdev: add new operation for FFT processing Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 2/7] bbdev: add device status info Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-06-28 1:35 ` [PATCH v3 7/7] bbdev: add a lock option for enqueue/dequeue operation Nicolas Chautru
2022-07-06 0:23 ` [PATCH v4 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 0:23 ` [PATCH v4 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-07-06 12:50 ` Tom Rix
2022-07-06 21:20 ` Chautru, Nicolas
2022-07-06 0:23 ` [PATCH v4 2/7] bbdev: add device status info Nicolas Chautru
2022-07-06 15:38 ` Tom Rix
2022-07-06 21:16 ` Chautru, Nicolas
2022-07-07 13:37 ` Tom Rix
2022-07-07 17:15 ` Chautru, Nicolas
2022-07-18 13:09 ` Tom Rix
2022-08-25 14:08 ` Maxime Coquelin
2022-07-06 0:23 ` [PATCH v4 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-07-06 16:06 ` Tom Rix
2022-07-06 21:12 ` Chautru, Nicolas
2022-07-07 13:34 ` Tom Rix
2022-07-07 17:13 ` Chautru, Nicolas
2022-07-18 13:04 ` Tom Rix
2022-07-06 0:23 ` [PATCH v4 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-07-06 16:15 ` Tom Rix
2022-07-06 21:10 ` Chautru, Nicolas
2022-07-07 13:20 ` Tom Rix
2022-07-07 17:19 ` Chautru, Nicolas
2022-07-18 13:21 ` Tom Rix
2022-08-15 17:28 ` Chautru, Nicolas
2022-07-06 0:23 ` [PATCH v4 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-07-06 18:47 ` Tom Rix
2022-07-06 21:04 ` Chautru, Nicolas
2022-07-07 13:09 ` Tom Rix
2022-07-07 16:57 ` Chautru, Nicolas
2022-07-18 22:38 ` Tom Rix
2022-07-06 0:23 ` [PATCH v4 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-07-06 18:57 ` Tom Rix
2022-07-06 20:34 ` Chautru, Nicolas
2022-07-06 0:23 ` [PATCH v4 7/7] bbdev: add a lock option for enqueue/dequeue operation Nicolas Chautru
2022-07-06 19:01 ` Tom Rix
2022-07-06 19:20 ` Stephen Hemminger
2022-07-06 20:21 ` Chautru, Nicolas
2022-07-07 12:47 ` Tom Rix
2022-07-06 23:28 ` [PATCH v5 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-07-06 23:28 ` [PATCH v5 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-08-25 13:54 ` Maxime Coquelin
2022-07-06 23:28 ` [PATCH v5 2/7] bbdev: add device status info Nicolas Chautru
2022-08-25 14:18 ` Maxime Coquelin
2022-08-25 18:30 ` Chautru, Nicolas
2022-08-26 10:12 ` Maxime Coquelin
2022-08-29 16:10 ` Chautru, Nicolas
2022-08-30 7:08 ` Maxime Coquelin
2022-08-30 19:38 ` Chautru, Nicolas
2022-07-06 23:28 ` [PATCH v5 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-08-25 15:23 ` Maxime Coquelin
2022-07-06 23:28 ` [PATCH v5 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-07-06 23:28 ` [PATCH v5 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-07-06 23:28 ` [PATCH v5 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-07-06 23:28 ` [PATCH v5 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-08-15 17:54 ` [PATCH v5 0/7] bbdev changes for 22.11 Chautru, Nicolas
2022-08-25 18:24 ` [PATCH v6 " Nicolas Chautru
2022-08-25 18:24 ` [PATCH v6 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-08-25 18:24 ` [PATCH v6 2/7] bbdev: add device status info Nicolas Chautru
2022-08-25 18:24 ` [PATCH v6 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-08-25 18:24 ` [PATCH v6 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-08-26 11:53 ` Maxime Coquelin
2022-08-25 18:24 ` [PATCH v6 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-08-26 12:07 ` Maxime Coquelin
2022-08-29 18:18 ` Chautru, Nicolas
2022-08-25 18:24 ` [PATCH v6 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-08-26 19:51 ` Maxime Coquelin
2022-08-25 18:24 ` [PATCH v6 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-08-26 19:52 ` Maxime Coquelin
2022-08-29 18:07 ` [PATCH v7 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-08-29 18:07 ` [PATCH v7 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-08-29 18:07 ` [PATCH v7 2/7] bbdev: add device status info Nicolas Chautru
2022-08-30 2:19 ` Zhang, Mingshan
2022-08-30 4:43 ` Hemant Agrawal
2022-09-21 18:54 ` [EXT] " Akhil Goyal
2022-09-21 20:53 ` Chautru, Nicolas
2022-08-29 18:07 ` [PATCH v7 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-08-29 18:07 ` [PATCH v7 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-08-30 4:44 ` Hemant Agrawal
2022-09-21 19:00 ` [EXT] " Akhil Goyal
2022-09-21 20:53 ` Chautru, Nicolas
2022-08-29 18:07 ` [PATCH v7 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-09-21 19:14 ` [EXT] " Akhil Goyal
2022-09-21 20:56 ` Chautru, Nicolas
2022-09-22 14:19 ` Akhil Goyal
2022-09-22 16:39 ` Chautru, Nicolas
2022-09-22 16:48 ` Akhil Goyal
2022-09-22 17:25 ` Chautru, Nicolas
2022-08-29 18:07 ` [PATCH v7 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-09-21 19:21 ` [EXT] " Akhil Goyal
2022-09-21 20:57 ` Chautru, Nicolas
2022-09-23 10:57 ` Ferruh Yigit
[not found] ` <CO6PR18MB44848717BA4EA2FF8967D7CBD8509@CO6PR18MB4484.namprd18.prod.outlook.com>
2022-09-24 16:34 ` Chautru, Nicolas
2022-09-27 9:43 ` Ferruh Yigit [this message]
2022-09-27 20:59 ` Chautru, Nicolas
2022-09-29 18:10 ` Ferruh Yigit
2022-09-29 18:32 ` Akhil Goyal
2022-09-29 19:48 ` Chautru, Nicolas
2022-09-30 7:54 ` Maxime Coquelin
2022-08-29 18:07 ` [PATCH v7 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-09-21 19:25 ` [EXT] " Akhil Goyal
2022-09-21 20:58 ` Chautru, Nicolas
2022-08-30 4:45 ` [PATCH v7 0/7] bbdev changes for 22.11 Hemant Agrawal
2022-09-06 16:47 ` Chautru, Nicolas
2022-09-21 21:02 ` [PATCH v8 " Nic Chautru
2022-09-21 21:02 ` [PATCH v8 1/7] bbdev: allow operation type enum for growth Nic Chautru
2022-09-21 21:02 ` [PATCH v8 2/7] bbdev: add device status info Nic Chautru
2022-09-21 21:02 ` [PATCH v8 3/7] bbdev: add device info on queue topology Nic Chautru
2022-09-21 21:02 ` [PATCH v8 4/7] drivers/baseband: update PMDs to expose queue per operation Nic Chautru
2022-09-21 21:02 ` [PATCH v8 5/7] bbdev: add new operation for FFT processing Nic Chautru
2022-09-21 21:02 ` [PATCH v8 6/7] bbdev: add queue related warning and status information Nic Chautru
2022-09-21 21:02 ` [PATCH v8 7/7] bbdev: remove unnecessary if-check Nic Chautru
2022-09-22 17:45 ` [PATCH v9 0/7] bbdev changes for 22.11 Nic Chautru
2022-09-22 17:45 ` [PATCH v9 1/7] bbdev: allow operation type enum for growth Nic Chautru
2022-09-22 17:45 ` [PATCH v9 2/7] bbdev: add device status info Nic Chautru
2022-09-22 17:45 ` [PATCH v9 3/7] bbdev: add device info on queue topology Nic Chautru
2022-09-22 17:45 ` [PATCH v9 4/7] drivers/baseband: update PMDs to expose queue per operation Nic Chautru
2022-09-22 17:45 ` [PATCH v9 5/7] bbdev: add new operation for FFT processing Nic Chautru
2022-09-22 17:45 ` [PATCH v9 6/7] bbdev: add queue related warning and status information Nic Chautru
2022-09-22 17:45 ` [PATCH v9 7/7] bbdev: remove unnecessary if-check Nic Chautru
2022-09-22 18:17 ` [EXT] [PATCH v9 0/7] bbdev changes for 22.11 Akhil Goyal
2022-09-22 20:59 ` Chautru, Nicolas
2022-09-30 18:45 ` [PATCH v10 " Nicolas Chautru
2022-09-30 18:45 ` [PATCH v10 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-09-30 18:46 ` [PATCH v10 2/7] bbdev: add device status info Nicolas Chautru
2022-09-30 18:46 ` [PATCH v10 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-09-30 18:46 ` [PATCH v10 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-09-30 18:46 ` [PATCH v10 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-09-30 18:46 ` [PATCH v10 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-10-03 8:28 ` Thomas Monjalon
2022-10-03 16:39 ` Chautru, Nicolas
2022-10-03 17:21 ` Thomas Monjalon
2022-09-30 18:46 ` [PATCH v10 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-09-30 20:38 ` [EXT] [PATCH v10 0/7] bbdev changes for 22.11 Akhil Goyal
2022-10-03 18:00 ` [PATCH v11 " Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 2/7] bbdev: add device status info Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-10-03 18:00 ` [PATCH v11 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 0/7] bbdev changes for 22.11 Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 1/7] bbdev: allow operation type enum for growth Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 2/7] bbdev: add device status info Nicolas Chautru
2022-10-05 7:16 ` Maxime Coquelin
2022-10-04 17:16 ` [PATCH v12 3/7] bbdev: add device info on queue topology Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 4/7] drivers/baseband: update PMDs to expose queue per operation Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 5/7] bbdev: add new operation for FFT processing Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 6/7] bbdev: add queue related warning and status information Nicolas Chautru
2022-10-04 17:16 ` [PATCH v12 7/7] bbdev: remove unnecessary if-check Nicolas Chautru
2022-10-06 17:31 ` [EXT] [PATCH v12 0/7] bbdev changes for 22.11 Akhil Goyal
2022-10-06 22:28 ` Chautru, Nicolas
2022-10-07 4:46 ` Akhil Goyal
2022-10-10 7:35 ` Thomas Monjalon
2022-10-10 17:07 ` Chautru, Nicolas
2022-06-06 16:15 ` [PATCH v1 0/2] bbdev: add device info on queue topology Chautru, Nicolas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17bacfdd-1326-36e2-5644-bf9dc1938c42@amd.com \
--to=ferruh.yigit@amd.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=gakhil@marvell.com \
--cc=hemant.agrawal@nxp.com \
--cc=maxime.coquelin@redhat.com \
--cc=mdr@ashroe.eu \
--cc=mingshan.zhang@intel.com \
--cc=nicolas.chautru@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).