From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7FC22425C5 for ; Sun, 17 Sep 2023 21:37:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A5F740272; Sun, 17 Sep 2023 21:37:44 +0200 (CEST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [152.66.248.44]) by mails.dpdk.org (Postfix) with ESMTP id D206B4025E for ; Sun, 17 Sep 2023 21:37:42 +0200 (CEST) Received: from [192.168.0.104] (host-79-121-41-203.kabelnet.hu [79.121.41.203]) (authenticated bits=0) by frogstar.hit.bme.hu (8.17.1/8.17.1) with ESMTPSA id 38HJbZWM060071 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 17 Sep 2023 21:37:41 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-203.kabelnet.hu [79.121.41.203] claimed to be [192.168.0.104] Content-Type: multipart/alternative; boundary="------------js7RkYcj6ykcvbEhf1GuDBtU" Message-ID: <930f2885-caec-7297-65f7-0959dd6d550c@hit.bme.hu> Date: Sun, 17 Sep 2023 21:37:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 From: Gabor LENCSE Subject: Re: rte_exit() does not terminate the program -- is it a bug or a new feature? To: Stephen Hemminger Cc: users@dpdk.org References: <3ef90e53-c28b-09e8-e3f3-2b78727114ff@hit.bme.hu> <20230915080608.724f0102@hermes.local> <35b55d11-bb67-2363-6f0a-0fb9667ebe6d@hit.bme.hu> <20230915143305.0ac313c6@hermes.local> Content-Language: en-US In-Reply-To: <20230915143305.0ac313c6@hermes.local> X-Virus-Scanned: clamav-milter 0.103.8 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.203; helo=[192.168.0.104]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.11; X-DCC-wuwien-Metrics: frogstar.hit.bme.hu; whitelist X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED, AWL, HTML_MESSAGE, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6-frogstar X-Spam-Checker-Version: SpamAssassin 3.4.6-frogstar (2021-04-09) on frogstar.hit.bme.hu X-Scanned-By: MIMEDefang 2.86 on 152.66.248.44 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org This is a multi-part message in MIME format. --------------js7RkYcj6ykcvbEhf1GuDBtU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Stephen, Thank you very much for your answer. Please see my answers inline. > Not sure what the tx and rx polling loops look like in your application. In short: they surely finish. In more details: - The receivers finish due to timeout. In my case the receiving threads finished OK. (Their CPU cores became idle.) - The sender threads check if sending happened within timeout time only AFTER all test frames were sent, that is, the sending loop finished. (It is done so to spare 1 branch instruction in the innermost sending loop.) So the sending loop is already finished when the rte_exit() is called. *My problem is that calling the rte_exit() function does not terminate the application.* > But they need to have some way of forcing exit, and you need to set that > flag before calling rte_exit(). > > See l2fwd and force_quit flag for an example. I have looked into its source code. I understand that it sets the "force_quit" flag when it receives a SIGINT or SIGTERM signal, and the nonzero value of the  "force_quit" flag causes to finish the while cycle of the "l2fwd_main_loop(void)". However, l2fwd also uses the "rte_exit()" function to terminate the program. The only difference is that it calls the "rte_exit()" function from the main program, and I do so in a thread started by the "rte_eal_remote_launch()" function. Is there any constraint for usage the "rte_eal_remote_launch()" function? (E.g., it may be called only from the main thread? I did not see anything like that int the documentation.) Best regards, Gábor --------------js7RkYcj6ykcvbEhf1GuDBtU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear Stephen,

Thank you very much for your answer. Please see my answers inline.

Not sure what the tx and rx polling loops look like in your application.

In short: they surely finish.

In more details:
- The receivers finish due to timeout. In my case the receiving threads finished OK. (Their CPU cores became idle.)
- The sender threads check if sending happened within timeout time only AFTER all test frames were sent, that is, the sending loop finished. (It is done so to spare 1 branch instruction in the innermost sending loop.) So the sending loop is already finished when the rte_exit() is called. My problem is that calling the rte_exit() function does not terminate the application. 

But they need to have some way of forcing exit, and you need to set that
flag before calling rte_exit().

See l2fwd and force_quit flag for an example.

I have looked into its source code. I understand that it sets the "force_quit" flag when it receives a SIGINT or SIGTERM signal, and the nonzero value of the  "force_quit" flag causes to finish the while cycle of the "l2fwd_main_loop(void)".

However, l2fwd also uses the "rte_exit()" function to terminate the program. The only difference is that it calls the "rte_exit()" function from the main program, and I do so in a thread started by the "rte_eal_remote_launch()" function.

Is there any constraint for usage the "rte_eal_remote_launch()" function? (E.g., it may be called only from the main thread? I did not see anything like that int the documentation.)

Best regards,

Gábor

--------------js7RkYcj6ykcvbEhf1GuDBtU--