From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) by dpdk.org (Postfix) with ESMTP id 90FF42904 for ; Fri, 18 Jan 2019 00:00:58 +0100 (CET) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0HMsDxF163681 for ; Thu, 17 Jan 2019 23:00:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type; s=corp-2018-07-02; bh=ZtaQZoARZLCtYKvynfBTLvIRxfOaZDJygANlhqMyjik=; b=oIQ+p1yKoUHqzHzcOSmT7V91IWnrNv7wyC9OQg/I7qmF15gtRgQhinAlCEHlmJRPapww Zci3+wqMjXMVZ4UxY+MqaR0UdqxKNXbsmA9tDyUs4xUQB6UB7zh+vm0aDxIMdFu3Xf8f mmZ1BtERzx4RFuRg7QZ+eukV90e/qGgUTC6gCKlWGG8bVnvQTxt+Od/3z6mPUtbb1h0n GMUp7zclVmfRk2J0+thlnKh6ERneFZ+Bsu6iQIO6s43SLv5lNMtKJUdCIX/3UOB41Rex +VBPVIlm9gzYdM7BdVVfetYaIhYz/E2/m+wCRo7QUGOGtZWZJufm8fZ5a0NbowWMXQCw FQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2pybjp2qvm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 17 Jan 2019 23:00:57 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0HN0p1A028741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 17 Jan 2019 23:00:51 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0HN0p7b014987 for ; Thu, 17 Jan 2019 23:00:51 GMT MIME-Version: 1.0 Message-ID: <03fd164b-112b-4e44-a5b0-15c6e3703662@default> Date: Thu, 17 Jan 2019 15:00:51 -0800 (PST) From: Changchun Zhang Sender: Changchun Zhang To: users@dpdk.org X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.5093.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9139 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=985 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901170159 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 23:00:58 -0000 Hi, =20 I have user question on using the QAT device in the DPDK.=20 In the real design, after calling enqueuer_burst() on the specified queue p= air at one of the lcore, usually which one is usually done? 1. should we do run-to-completion to call dequeuer_burst() waiting for = the device finishing the crypto operation,=20 2. or should we do pipe-line, in which we return right after enqueuer_b= urst() and release the CPU. And call dequeuer_burst() on other thread funct= ion? Option 1 is more like synchronous and can be seen on all the DPDK crypto ex= amples, while option 2 is asynchronous which I have never seen in any refer= ence design if I missed anything. =20 Thanks, Alex