From: sys_stv@intel.com
To: test-report@dpdk.org, anatoly.burakov@intel.com
Cc: daxuex.gao@intel.com
Subject: |FAILURE|dpdk|8a8c02d2bb| intel-Functional
Date: 06 Nov 2025 01:03:55 -0800 [thread overview]
Message-ID: <0b0228$5nu5kr@orviesa005-auth.jf.intel.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5567 bytes --]
Test-Label: intel-Functional
Test-Status: FAILURE
_Functional issues_
DPDK git repo: dpdk
commit 8a8c02d2bb224ebbe60e8e1ce6edcfb481b46151
Author: Anatoly Burakov <anatoly.burakov@intel.com>
Date: Tue Oct 21 14:19:42 2025 +0100
vfio: fix custom containers in multiprocess
Currently, the API regarding handling custom (non-default) containers has
a problem with how it behaves in secondary process. The expected flow for
using custom containers is to:
1) create a new container using rte_vfio_container_create()
2) look up IOMMU group with rte_vfio_get_group_num()
3) bind group to that container using rte_vfio_group_bind()
4) setup device with rte_vfio_setup_device()
When called from secondary process, rte_vfio_container_create() will check
if there's space in local VFIO config, and if there is, it will call
rte_vfio_get_container_fd() which, in secondary process, will call into a
multiprocess code to request primary process to open container fd, and then
pass it back to the requester. Primary process does not store this fd
anywhere, in fact it closes it immediately after responding to the request.
Following that, when we call rte_vfio_group_bind(), we check if the group
is open locally, and if not, we will call into multiprocess code again, to
request primary process to open the group fd for us, but since primary did
not store any information about the new container in step 1, it will store
the group in local config for default container, and return it to the
secondary, who will add it to its own config for a different container.
To address these issues, the following changes are made:
1) Clarify meaning of rte_vfio_get_container_fd() to only return the
default container, and always pick it up from process-local config
2) Avoid calling into multiprocess on rte_vfio_container_create()
3) Avoid calling into multiprocess in group-related code, except when
dealing with groups associated with default container
As a consequence, SOCKET_REQ_DEFAULT_CONTAINER can be removed and
consolidated with SOCKET_REQ_CONTAINER, which now only handles the
default container.
Fixes: ea2dc1066870 ("vfio: add multi container support")
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Smoke-Testing Summary : 31 Case Done, 30 Successful, 1 Failures
OS : Ubuntu 22.04.5 LTS
Kernel : 5.15.0-161-generic
GCC : 11.4.0-1ubuntu1~22.04.2
NIC : Ethernet Controller XL710 for 40GbE QSFP+
Target : x86_64-native-linuxapp-gcc
Test result details:
+-----------------+---------------------------------------------------+-------+
| suite | case | status|
+-----------------+---------------------------------------------------+-------+
| checksum_offload| test_do_not_insert_checksum_on_the_transmit_packet| passed|
| checksum_offload| test_hardware_checksum_check_ip_rx | passed|
| checksum_offload| test_hardware_checksum_check_ip_tx | passed|
| checksum_offload| test_hardware_checksum_check_l4_rx | passed|
| checksum_offload| test_insert_checksum_on_the_transmit_packet | passed|
| checksum_offload| test_rx_checksum_valid_flags | passed|
| checksum_offload| test_checksum_offload_with_vlan | FAILED|
| checksum_offload| test_hardware_checksum_check_l4_tx | n/a |
| dual_vlan | test_dual_vlan_priority_rxtx | passed|
| dual_vlan | test_vlan_filter_config | passed|
| dual_vlan | test_vlan_filter_table | passed|
| dual_vlan | test_vlan_insert_config | passed|
| dual_vlan | test_vlan_random_test | passed|
| dual_vlan | test_vlan_strip_config | passed|
| dual_vlan | test_vlan_synthetic_test | passed|
| dual_vlan | test_vlan_tpid_config | passed|
| dual_vlan | test_vlan_stripq_config | n/a |
| jumboframes | test_jumboframes_bigger_jumbo | passed|
| jumboframes | test_jumboframes_jumbo_jumbo | passed|
| jumboframes | test_jumboframes_jumbo_nojumbo | passed|
| jumboframes | test_jumboframes_normal_jumbo | passed|
| jumboframes | test_jumboframes_normal_nojumbo | passed|
| rxtx_offload | test_rxoffload_port_all | passed|
| rxtx_offload | test_rxoffload_port_cmdline | passed|
| rxtx_offload | test_txoffload_port | passed|
| rxtx_offload | test_txoffload_port_all | passed|
| rxtx_offload | test_txoffload_port_checksum | passed|
| rxtx_offload | test_txoffload_port_cmdline | passed|
| rxtx_offload | test_rxoffload_queue | n/a |
| rxtx_offload | test_txoffload_port_multi_segs | n/a |
| rxtx_offload | test_txoffload_queue | n/a |
+-----------------+---------------------------------------------------+-------+
DPDK STV team
reply other threads:[~2025-11-06 9:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='0b0228$5nu5kr@orviesa005-auth.jf.intel.com' \
--to=sys_stv@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=daxuex.gao@intel.com \
--cc=test-report@dpdk.org \
/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).