[dpdk-users] x710 (i40e) hash set up questions

[dpdk-users] x710 (i40e) hash set up questions

[A-three Mpt]

Hi,
I am having trouble to understand x710 hash setup. Is my following understanding right?
   
   - Q1: We select a generic flow type and it will be convert to NIC-dependent pctype, right?
   -    
Q2: What is the hash_inset? e.g., in the document: For example, to use only 48bit prefix for IPv6 src address for IPv6 TCP RSS:
   testpmd> port config 0 pctype 43 hash_inset clear all
testpmd> port config 0 pctype 43 hash_inset set field 13
testpmd> port config 0 pctype 43 hash_inset set field 14
testpmd> port config 0 pctype 43 hash_inset set field 15
   
I found pctype 43 is NonFIPV6, TCP from the data sheet, but how are the field 13, 14, 15 related to the 48 bit prefix of src address?

   - Q3: There are generic functions like rte_eth_dev_filter_ctrl() and i40e-specific ones like rte_pmd_i40e_inset_set. Do I need both of them to work? Any relations between them?
   - Q4: If I want to hash based on the new pctype added (22 to 25 for GTPU and GTPC), how can I do that?
   - If I config 4 queues on a port, how can I set up the RSS to distribute pctype 22 and 23 to these 4 queues?
Thanks very much,Athree
From fiona.trahe@intel.com  Mon Jan 21 19:52:06 2019
Return-Path: <fiona.trahe@intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 5DED15B40
 for <users@dpdk.org>; Mon, 21 Jan 2019 19:52:06 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 21 Jan 2019 10:52:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.56,503,1539673200"; d="scan'208";a="129557222"
Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75])
 by orsmga001.jf.intel.com with ESMTP; 21 Jan 2019 10:52:04 -0800
Received: from irsmsx101.ger.corp.intel.com ([169.254.1.213]) by
 IRSMSX153.ger.corp.intel.com ([169.254.9.115]) with mapi id 14.03.0415.000;
 Mon, 21 Jan 2019 18:52:03 +0000
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Changchun Zhang <changchun.zhang@oracle.com>, "Pathak, Pravin"
 <pravin.pathak@intel.com>, "users@dpdk.org" <users@dpdk.org>
CC: "Trahe, Fiona" <fiona.trahe@intel.com>
Thread-Topic: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK
Thread-Index: AQHUrriXjo1+JKJBjkaH5GQU9xCtbKW0/cFQgAAZIACAABUogIAACJIwgAAHYoCAAAGjsIAAExAAgAADhJCAAAxnAIAABH9Q
Date: Mon, 21 Jan 2019 18:52:02 +0000
Message-ID: <348A99DA5F5B7549AA880327E580B435896CEEE9@IRSMSX101.ger.corp.intel.com>
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>
 <400475b7-869e-4281-9d31-058f96957fe1@default>
 <348A99DA5F5B7549AA880327E580B435896CD61A@IRSMSX101.ger.corp.intel.com>
 <b10c91a1-9341-402d-bcd9-9fc7570af464@default>
 <348A99DA5F5B7549AA880327E580B435896CD7E0@IRSMSX101.ger.corp.intel.com>
 <ab36faa8-2d86-4831-b988-bb08641e9468@default>
In-Reply-To: <ab36faa8-2d86-4831-b988-bb08641e9468@default>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTRmMzBlYjMtNzdlMi00NWE3LTk5M2MtYTAzMTk3OWM2NWExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiczA1NDUxVkRzZTV1bndTTlBWQkhSYUU2SnkzYkFlbjZRYkw2R2UrXC9DU1NEXC9Lb2Ywa0xpU1I4R29BM3NDWjN3In0x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [163.33.239.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 18:52:06 -0000



> -----Original Message-----
> From: Changchun Zhang [mailto:changchun.zhang@oracle.com]
> Sent: Friday, January 18, 2019 6:53 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Pathak, Pravin <pravin.pathak@intel.com>;
> users@dpdk.org
> Subject: RE: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK
> 
> HI Fiona,
> 
> Thanks!
> Changchun (Alex)
> 
> 
> -----Original Message-----
> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
> Sent: Friday, January 18, 2019 1:21 PM
> To: Changchun Zhang <changchun.zhang@oracle.com>; Pathak, Pravin <pravin.pathak@intel.com>;
> users@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [dpdk-users] Run-to-completion or Pipe-line for QAT PMD in DPDK
> 
> Hi Alex,
> 
> >  [changchun] Many thanks! So from this limitation, we can conclude
> > that Lcore can only dequeue the QAT queue which was enqueued by
> > itself, right. If so, then the Crypto device lib doc may be a little misleading, at least some notes
> should be put there.
> [Fiona] Limitations are generally on the device documentation - it wouldn't make sense to pollute the
> lib with the limitations of individual devices. (though I understand it's easy to miss the limitations) As
> mentioned before, if this is an important use-case for you we would be interested in hearing about it,
> and we could investigate performant ways to remove the limitation.
> 
>  [changchun] Currently we don't see if it is necessary to remove this limitation or not. But we do need
> to confirm what the relationship between logical core, queue pair, and crypto device. As my
> understanding, no matter pipe line or current limitation, the QAT accepts the request from the RX
> queue of a queue pair and after the processing, the data will be put the TX queue on the same queue
> pair, it is right? Say enqueue data to the RX queue of Queue pair 1, the return data would always be
> put to the TX queue of Queue pair 1, not possible to other Queue pair's TX queue, right? Let me know
> if you did not get my question.

[Fiona] well, we use names tx and rx the opposite way you named them - but this doesn't matter as neither
tx nor rx names are visible on the API. Just qp_id. So whatever qp_id you enqueue to, you will get the response
on the same qp_id in a subsequent dequeue operation. And they will be dequeued in same order as you enqueued.