From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by dpdk.org (Postfix) with ESMTP id C8A39DE3 for ; Fri, 18 Jan 2019 17:42:05 +0100 (CET) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0IGXptu165656; Fri, 18 Jan 2019 16:42:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=aMBi3r1vxwy2XfFTTfNDezU16hpSqROQzh+2WkeJGeA=; b=kaSHo7Vhpfl/icA1V4GQRpz4GEHaJcdAUWbslzywhcPBdhdzz9W6l6p6Q2/qxGLUJkVj bHFl3oJZkO7BoZFjAfa2hzykO0hX8dHrN5IWXiIAF/5rhcekgV+z/na4O3Pi9irXQTr5 ZXktpdCSgNWYQo6g2r99qzOxO6UdgpOWJlsZJ8GcBPCbfNEOzuZLC8A45oIdTfK42Jx/ C4XjPlQnSdf2/ZP5qyqzHcP0EnJ9k63f7gY2CJXBxftsJRFCq0z4Kfy+EwwaM9tqiTPM xmmX3ExEvG23KR55oNKfI/+rcphFG3ba32jk3hPPLm8bYLcDp5HEDjiye+XwyGv4/Zuo Og== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2pybjspm3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Jan 2019 16:42:04 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x0IGfx49023447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Jan 2019 16:41:59 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0IGfwlE010142; Fri, 18 Jan 2019 16:41:58 GMT MIME-Version: 1.0 Message-ID: <400475b7-869e-4281-9d31-058f96957fe1@default> Date: Fri, 18 Jan 2019 08:41:53 -0800 (PST) From: Changchun Zhang Sender: Changchun Zhang To: "Trahe, Fiona" , "Pathak, Pravin" , users@dpdk.org References: <03fd164b-112b-4e44-a5b0-15c6e3703662@default> <348A99DA5F5B7549AA880327E580B435896CD08F@IRSMSX101.ger.corp.intel.com> <168A68C163D584429EF02A476D5274424DEA9B7C@FMSMSX108.amr.corp.intel.com> <5e87ae90-94b9-4e85-9172-46b95365ec36@default> <348A99DA5F5B7549AA880327E580B435896CD528@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435896CD528@IRSMSX101.ger.corp.intel.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.5093.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9140 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=925 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180119 Subject: Re: [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: Fri, 18 Jan 2019 16:42:06 -0000 Thanks! Changchun (Alex) -----Original Message----- From: Trahe, Fiona [mailto:fiona.trahe@intel.com]=20 Sent: Friday, January 18, 2019 11:26 AM To: Changchun Zhang ; Pathak, Pravin ; users@dpdk.org Cc: Trahe, Fiona Subject: RE: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPD= K Hi Alex, > [changchun] In the same thread, but how about to dequeuer at the=20 > beginning of the thread each time, if data presents then processing=20 > them, if no data just do other work, and equeue the packets at some time = but does not wait. > For example: > While(1) > { > =09Nb_ops =3D dequeuer(); > =09If(nb_ops > ) > { > process_dequeued_data(); > continue; > } >=20 > Other_work(); > If(ipsec) > Enqueuer(); > } > Does it make sense? [Fiona] It can, though on the first loop ro after a queit time youll proabl= y get very few back on first and second dequeue as It'll be called immediat= ely after the enqueue. Once it gets busy that could be ok though [changchun] Thank you Fiona. One more question, as you said, enqueuer/deque= ue should be called within the same thread. Why? Is it because the other th= read(lcore 1) cannot dequeuer the processed data from other thread(lcore 2)= ? But as the cryptograph device lib doc says, "it is howerver possible to u= se a different logical core to dequeuer an operation on a queue pair from t= he logical core which it was enqueued on". Looking forward to more details.