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 25427A0542; Sun, 9 Oct 2022 19:07:35 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 993BE410D7; Sun, 9 Oct 2022 19:07:30 +0200 (CEST) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by mails.dpdk.org (Postfix) with ESMTP id 05C3A40042 for ; Fri, 7 Oct 2022 11:37:52 +0200 (CEST) Received: by mail-qt1-f170.google.com with SMTP id y20so2472081qtv.5 for ; Fri, 07 Oct 2022 02:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=bYALE3PFzolVDx91jDh8VRxKwSjHg2EJ6Ho8l7bVgqs=; b=RTy2r4jiir8ojfXpfKKeL0PaNw9Q45AsJSiQKi9kGVATq4RNoLfcgjQ9Oxc4l966sS RoQmVNeCViHptFmY3gE2mMfHcR/LJrjeLmWvBYMSA/en2BiINZDqMIkZLFTJhLjtbGSY J9P42NhjUDF974hYsB0b5ZhrfRhXQM0V4dZqbXHeUzty/WdQ2royCTLOAyoXa2BNumZW UgS+WBY16jpkL4Ms4tP25aQ3K3EjQjbRbQ+pBXPLjtGqnvVDs9udw88oJE/X63E8u9a/ KggdeiMqJ35p4E/ng/tjWcixr3RCwDscvl2YGxa1G8E4vcoTPqnL97fuaMntpbRxAHNm cbJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bYALE3PFzolVDx91jDh8VRxKwSjHg2EJ6Ho8l7bVgqs=; b=ciCy3okc0TYvvM6jMe8MsYlxzMhmkoza71WW71gsV8fdJATQAiFrZSeQwXUkE1+2Rc cjgj7cmzqJ+OGvZzvda/3b9NXBPeROjvtFINGgz2d1rrIVSd52+9OGlcnl9ninxJcB/H IfuScXrG2qsLSKu3zMuj+b5KI+aWP2Yp8x6aC+2wsx2dTBZAOhHbOMMRH0fMcCGy8D9m HVuSeTsq5WJrCJoe1cTTk+MVJF+uQe5JViVaOfjWfZhn8G4ZxMb3l+NLSAykTH88EYgy nc/VTxBXlAz83f3WHwqKV8CBKOtkkoFdqc2wQmX0alMPIjTNvbQZzuG2QYPMmC7Poas8 w04Q== X-Gm-Message-State: ACrzQf09cfD1jWEbYx7ExZTs1EsW5Kq4REtKJ5+Kl2+pnZYIlMNcr7pz HsOQkFLULqK5DjpS8/+V47s+xqneAuL6gmHgNIU= X-Google-Smtp-Source: AMsMyM701gMT6lqmDIuRZ/yDqP4A9YKmK82rW8qwJBDjkjc8yacYX4bdV6TkjmR2rlTz94ixfFq/UA== X-Received: by 2002:ac8:578d:0:b0:35d:20d6:979f with SMTP id v13-20020ac8578d000000b0035d20d6979fmr3468177qta.15.1665135472208; Fri, 07 Oct 2022 02:37:52 -0700 (PDT) Received: from [10.249.158.231] (nat-216-240-30-11.netapp.com. [216.240.30.11]) by smtp.gmail.com with ESMTPSA id x19-20020a05620a0b5300b006e99290e83fsm167048qkg.107.2022.10.07.02.37.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Oct 2022 02:37:51 -0700 (PDT) Message-ID: Date: Fri, 7 Oct 2022 10:37:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [EXT] [dpdk-dev v5] lib/cryptodev: multi-process IPC request handler Content-Language: en-US To: Akhil Goyal , Kai Ji , "dev@dpdk.org" Cc: Ray Kinsella , Anatoly Burakov , "john.mcnamara@intel.com" References: <20221006081646.81901-1-kai.ji@intel.com> <20221006170612.94392-1-kai.ji@intel.com> From: "Zhang, Fan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 09 Oct 2022 19:07:28 +0200 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Akhil, On 06/10/2022 19:49, Akhil Goyal wrote: >> As some cryptode PMDs have multiprocess support, the secondary >> process needs queue-pair to be configured by the primary process before >> to use. This patch adds an IPC register function to help the primary >> process to register IPC action that allow secondary process to configure >> cryptodev queue-pair via IPC messages during the runtime. > Why are we forcing user another alternate API for secondary process to work? > Can we not register the IPC inside rte_cryptodev_queue_pair_setup() ? > > As I understand till now, > You have introduced another API rte_cryptodev_mp_request_register(), > Which will be called by application if primary-secondary communication is required. > And if it is registered, rte_cryptodev_ipc_request() will be called from somewhere(not sure when this will be called). > And the call to rte_cryptodev_queue_pair_setup() from the secondary will do nothing. > > Is this a correct understanding? If it is correct, then it is an unnecessary overhead for the application. > We should update the rte_cryptodev_queue_pair_setup instead to handle primary and secondary configuration. > IMO, you do not need to change anything in the library. > Everything can be handled in the PMD. When the queue_pair_setup is called for particular qp_id, > Store the getpid() of the calling process into the priv data of queue pair if it is not already configured > And if configured return failure. > And in case of release you can also check the same. > > The configuration of queues for multi process is specific to PMDs. > There may be PMDs which may support same queue pair to be used by different processes. > Rx queue from the qp by one process and Tx queue from the qp by another process. > This will be needed if one process is doing only enqueue and the other only dequeue on the same qp. > So in that case, your implementation will not work. This is a question we didn't think as comprehensive as you did. With the change Kai did at least all Intel PMDs will support that. I assume we need some feature flag to state that? >> After setup, a new "qp_in_used_pid" param stores the PID to provide >> the ownership of the queue-pair so that only the PID matched queue-pair >> free request is allowed in the future. >> > qp_in_used_pid looks very cryptic, I believe this should be part of queue pair private data of PMD. > Adding this in cryptodev data is not justified. This property is per queue and not per crypto device. > Hence adding in device data does not make sense to me. > Agreed. The PID storage is not mandatory for every PMD but only for some (ipsec-mb for example) so we should store the PID info inside the PMD queue pair data instead. Regards, Fan