On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
Lijun can you please send a new version with 'libabigail.abignore' update?
Thanks, ferruh
15/04/2021 14:45, Ferruh Yigit:
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
This is how you can check the struct sizes (in 32 and 64-bit builds):
for lib in ethdev ; do for struct in rte_eth_{r,t}xq_info ; do for build in dpdk-build/build-{32b,x86-generic} ; do basename $build ; pahole -sC $struct $build/lib/librte_$lib.a ; done ; done ; done
I confirm the additions are not changing the ABI. And because they are provided as output infos, there is no issue like using potentially unitialized holes.
It must be explicited in libabigail with this syntax: https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppress-t...
; Ignore fields inserted in alignment hole of rte_eth_rxq_info [suppress_type] name = rte_eth_rxq_info has_data_member_inserted_at = offset_after(scattered_rx)
; Ignore fields inserted in cacheline boundary of rte_eth_txq_info [suppress_type] name = rte_eth_txq_info has_data_member_inserted_between = {offset_after(nb_desc), end}
在 2021/4/15 20:45, Ferruh Yigit 写道:
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
Lijun can you please send a new version with 'libabigail.abignore' update?
Yes, I can do that. But at the moment I don't know how to update libabigil.abinore. I don't know where to modify Is there any relevant documentation?
Thanks, ferruh _______________________________________________ Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an email to linuxarm-leave@openeuler.org
On 4/16/2021 1:58 AM, oulijun wrote:
在 2021/4/15 20:45, Ferruh Yigit 写道:
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
Lijun can you please send a new version with 'libabigail.abignore' update?
Yes, I can do that. But at the moment I don't know how to update libabigil.abinore. I don't know where to modify Is there any relevant documentation?
Please check Thomas' response, he already described what needs to be changed.
And for documentation David & Ray may know better.
在 2021/4/15 21:34, Thomas Monjalon 写道:
15/04/2021 14:45, Ferruh Yigit:
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
This is how you can check the struct sizes (in 32 and 64-bit builds):
for lib in ethdev ; do for struct in rte_eth_{r,t}xq_info ; do for build in dpdk-build/build-{32b,x86-generic} ; do basename $build ; pahole -sC $struct $build/lib/librte_$lib.a ; done ; done ; done
I confirm the additions are not changing the ABI. And because they are provided as output infos, there is no issue like using potentially unitialized holes.
It must be explicited in libabigail with this syntax: https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppress-t...
; Ignore fields inserted in alignment hole of rte_eth_rxq_info [suppress_type] name = rte_eth_rxq_info has_data_member_inserted_at = offset_after(scattered_rx)
; Ignore fields inserted in cacheline boundary of rte_eth_txq_info [suppress_type] name = rte_eth_txq_info has_data_member_inserted_between = {offset_after(nb_desc), end}
Hi, Thomas Where am I supposed to join these. I can't find libabigail.bignore under dpdk-next
Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an email to linuxarm-leave@openeuler.org
On 4/16/2021 9:38 AM, oulijun wrote:
在 2021/4/15 21:34, Thomas Monjalon 写道:
15/04/2021 14:45, Ferruh Yigit:
On 4/15/2021 1:36 PM, Thomas Monjalon wrote:
15/04/2021 14:33, Ferruh Yigit:
On 4/15/2021 3:40 AM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only through pointers such as dev->data->tx_queue_state[queue_id], this is not the recommended way to access it. So this patch add get queue state when call rte_eth_rx_queue_info_get and rte_eth_tx_queue_info_get API.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so it could be ABI compatible.
Signed-off-by: Chengwen Feng fengchengwen@huawei.com Signed-off-by: Lijun Ou oulijun@huawei.com
Looks good to me, but it is causing an ABI error as we already discussed before as that is false positive.
Ray, David,
Should we add any exception to libabigail.abignore for this?
We do not tolerate any ABI warning. If we are sure the ABI change is false positive, it must be suppressed in libabigail.abignore in the same patch.
A new field is added to public structs, but struct size or the location of the existing fields are not changing (struct is cache aligned).
Can you please support how this can be added to 'libabigail.abignore'?
This is how you can check the struct sizes (in 32 and 64-bit builds):
for lib in ethdev ; do for struct in rte_eth_{r,t}xq_info ; do for build in dpdk-build/build-{32b,x86-generic} ; do basename $build ; pahole -sC $struct $build/lib/librte_$lib.a ; done ; done ; done
I confirm the additions are not changing the ABI. And because they are provided as output infos, there is no issue like using potentially unitialized holes.
It must be explicited in libabigail with this syntax: https://sourceware.org/libabigail/manual/libabigail-concepts.html#suppress-t...
; Ignore fields inserted in alignment hole of rte_eth_rxq_info [suppress_type] name = rte_eth_rxq_info has_data_member_inserted_at = offset_after(scattered_rx)
; Ignore fields inserted in cacheline boundary of rte_eth_txq_info [suppress_type] name = rte_eth_txq_info has_data_member_inserted_between = {offset_after(nb_desc), end}
Hi, Thomas Where am I supposed to join these. I can't find libabigail.bignore under dpdk-next
it should be in './devtools/libabigail.abignore'
-
Ferruh Yigit -
oulijun -
Thomas Monjalon