From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John Daley (johndale)" Subject: Re: [RFC] Generic flow director/filtering/classification API 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 To: Rahul Lakkireddy , John Fastabend , Adrien Mazarguil 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) In-Reply-To: <20160726100731.GA2542@chelsio.com> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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?