From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH 06/26] net/octeontx/base: probe PKI and PKO PCIe VF devices Date: Mon, 11 Sep 2017 23:57:32 +0530 Message-ID: <20170911182731.GE26002@jerin> References: <20170831145436.5397-1-jerin.jacob@caviumnetworks.com> <20170831145436.5397-7-jerin.jacob@caviumnetworks.com> <1a02f2ba-bbd0-bc5b-1d0d-bdbcc88f7aba@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, santosh.shukla@caviumnetworks.com To: Ferruh Yigit Return-path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0040.outbound.protection.outlook.com [104.47.42.40]) by dpdk.org (Postfix) with ESMTP id 2272F1396 for ; Mon, 11 Sep 2017 20:27:53 +0200 (CEST) Content-Disposition: inline In-Reply-To: <1a02f2ba-bbd0-bc5b-1d0d-bdbcc88f7aba@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Tue, 5 Sep 2017 18:44:22 +0100 > From: Ferruh Yigit > To: Jerin Jacob , dev@dpdk.org > CC: santosh.shukla@caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCH 06/26] net/octeontx/base: probe PKI and PKO > PCIe VF devices > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.3.0 > > On 8/31/2017 3:54 PM, Jerin Jacob wrote: > > An octeontx ethdev device consists of multiple PKO VF devices and an PKI > > VF device. On Octeontx HW, each Rx queues are enumerated as SSOVF device > > which is exposed as event_octeontx device, Tx queues are enumerated as > > PKOVF device, and ingress packet configuration is accomplished through > > PKIVF device. > > > > In order to expose as an single ethdev instance, On PCIe VF probe, > > the driver stores the information associated with the PCIe VF device and > > later with vdev infrastructure creates ethdev device with earlier > > probed PCIe VF device. > > So, is following correct: > > BGX is MAC interface, > in ingress it consists of single PKIVF (packet input) device, > in egress it consists of PKOVF (packet output) devices. Yes. > > PKIVF and PKOVF are physical eventdev devices. No they are network related co processors. Not the eventdev device. The eventdev HW is abstracted through driver/event/octeontx > > First physical devices are probed, later virtual ethdev is created which > gets/puts packets into these event devices. Yes. > > A graph in documentation can be very helpful for this. > > Also patchset can create multiple ethdev ports, why is this? And how A PKOVF PCIe VF device has 8 Tx queues which can be from any MAC interface. The created ethdev ports maps to each physical MAC interface. > eventdev - ethdev port mapping done for that case? One octeontx eventdev port is mapped as one octeontx ethdev Rx queue. > > Thanks, > ferruh > > > > > Signed-off-by: Jerin Jacob > > Co-authored-by: Santosh Shukla > > <...>