From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by dpdk.org (Postfix) with ESMTP id 711D66A94 for ; Fri, 19 Aug 2016 23:13:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2236; q=dns/txt; s=iport; t=1471641208; x=1472850808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=urA1zOUqEvoI2fcAxQ9CgfhTTH4o7/UwJOVMZl1bSjc=; b=YN7zVTwXKJkGgiuI5YymGn6JkdYD/1nMAAozg7MPTbCJxyBjvpk0AjRd pE7Fp9Rk1HFlDoo4K63dyEy3RjFkNFhY6mZH1ukj83ss2Cb1EI/0UZW+U v84g79XDZEHofno9sAN2Zth9PGA8IpJVFxCnbpVi9RK4nyaEiwP8aYh/V 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAgDEdbdX/4ENJK1eg0SBWbdpgX2GH?= =?us-ascii?q?QKBajgUAgEBAQEBAQFeJ4RfAQU6PxACAQg2EDIlAgQBDQ2IKbpfAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEdhiuETYobAQSZRwGPFo9TkDQBHjaDeocefwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,546,1464652800"; d="scan'208";a="141837605" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2016 21:13:27 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7JLDRBG013160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Aug 2016 21:13:27 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 19 Aug 2016 16:13:26 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1210.000; Fri, 19 Aug 2016 16:13:26 -0500 From: "John Daley (johndale)" To: Rahul Lakkireddy , John Fastabend , Adrien Mazarguil CC: "dev@dpdk.org" , Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Wenzhuo Lu , Jan Medala , Jing Chen , Konstantin Ananyev , Matej Vido , "Alejandro Lucero" , Sony Chacko , Jerin Jacob , "Pablo de Lara" , Olga Shern , Kumar A S , Nirranjan Kirubaharan , Indranil Choudhury Thread-Topic: [dpdk-dev] [RFC] Generic flow director/filtering/classification API Thread-Index: AQHR1ulqMB2jpISQEE+UjacaBgX8FKAi9Y6AgACVNACABeuygIAAVesAgAEkr4CAJhe24A== Date: Fri, 19 Aug 2016 21:13:26 +0000 Message-ID: <1111c07e205a46cdb629d4032df2cc77@XCH-RCD-007.cisco.com> References: <20160705181646.GO7621@6wind.com> <20160721081335.GA15856@chelsio.com> <20160721170738.GT7621@6wind.com> <20160725113229.GA24036@chelsio.com> <579640E2.50702@gmail.com> <20160726100731.GA2542@chelsio.com> In-Reply-To: <20160726100731.GA2542@chelsio.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.145.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 21:13:28 -0000 Hi, this is an old thread, but I'll reply to this instead of the RFC v2 sin= ce there is more context here. Thanks for pushing the new api forward Adrien. -john daley > > >>> - Match range of Physical Functions (PFs) on the NIC in a single ru= le > > >>> via masks. For ex: match all traffic coming on several PFs. > > >> > > >> The PF and VF pattern items assume there is a single PF associated > > >> with a DPDK port. VFs are identified with an ID. I basically took > > >> the same definitions as the existing filter types, perhaps this is > > >> not enough for Chelsio adapters. > > >> > > >> Do you expose more than one PF for a DPDK port? The Cisco VIC can support multiple PFs per Ethernet port. These are called= virtual-nics (VNICs). It would be nice to be able to redirect matched Rx p= ackets to another queue on another VNIC. > > >> > > >> Anyway, I'd suggest the same approach as above, automatic > > >> aggregation of rules for performance reasons, otherwise new or > > >> updated PF/VF pattern items, in which case it would be great if you > > >> could provide ideal structure definitions for this use case. > > >> > > > > > > In Chelsio hardware, all the ports of a device are exposed via > > > single PF4. There could be many VFs attached to a PF. Physical NIC > > > functions are operational on PF4, while VFs can be attached to PFs 0-= 3. > > > So, Chelsio hardware doesn't remain tied on a PF-to-Port, one-to-one > > > mapping assumption. > > > > > > There already seems to be a PF meta-item, but it doesn't seem to > > > accept any "spec" and "mask" field. Similarly, the VF meta-item > > > doesn't seem to accept a "mask" field. We could probably enable > > > these fields in the PF and VF meta-items to allow configuration. > > I would like to see an ID property added to the PF action meta-item, where = perhaps a BDF can be specified. This would potentially allow matched Rx pac= kets to be redirected to another VNIC and could be paired with the QUEUE ac= tion meta-item to redirect to a specific queue on a VNIC. The PF ID propert= y set to 0 would have the current specified behavior or redirecting to the = current PF. Is something like this possible?