-----Original Message----- > Date: Fri, 21 Apr 2017 22:31:52 +0000 > From: "Eads, Gage" <gage.e...@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, "dev@dpdk.org" > <dev@dpdk.org> > CC: "Richardson, Bruce" <bruce.richard...@intel.com>, "Van Haaren, Harry" > <harry.van.haa...@intel.com>, "hemant.agra...@nxp.com" > <hemant.agra...@nxp.com>, "nipun.gu...@nxp.com" <nipun.gu...@nxp.com>, > "Vangati, Narender" <narender.vang...@intel.com> > Subject: RE: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW > capability to inject packets to eventdev > > Hi Jerin,
Hi Gage, > > Thanks for getting this ball rolling, and I agree that we need a solution > that covers the three cases you described. OK. Half problem is solved if we agree on problem statement :-) > We've also been thinking about an environment where devices (NIC Rx (or even > Tx), crypto, or a timer "device" that uses librte_timer to inject events) can > plug in eventdev -- whether through a direct connection to the event > scheduler (case #3) or using software to bridge the gap -- such that > application software can have a consistent view of device interfacing on > different platforms. Make sense. Yes, The NPUs can produce events from NIC Rx, NIC Tx, crypto, timer device sources without SW service functions. > > Some initial thoughts on your proposal: > > 1. I imagine that deploying these service functions at the granularity of a > core can be excessive on devices with few (<= 8) cores. For example, if the > crypto traffic rate is low then a cryptodev service function could be > co-scheduled with other service functions and/or application work. I think > we'll need a more flexible deployment of these service functions. I agree. > > 2. Knowing which device type a service function is for would be useful -- > without it, it's not possible to assign the function to the NUMA node on > which the device is located. I guess we can use rte_eth_dev_socket_id() on requested port to get NUMA id. > > 3. Placing the service core logic in the PMDs is nice in terms of application > ease-of-use, but it forces PMD to write one-size-fits-all service core > functions, where, for example, the application's control of the NIC Rx > functionality is limited to the options that struct > rte_event_queue_producer_conf exports. An application may want customized > service core behavior such as: prioritized polling of Rx queues, using Rx > queue interrupts for low traffic rate queues, or (for "closed system" > eventdevs) control over whether/when a service core drops events (and a way > to notify applications of event drops). For such cases, I think the > appropriate solution is allow applications to plug in their own service core > functions (when hardware support isn't present). I agree. I think, we can have reusable producer code as static inline functions in librte_event with multiple event producing strategies and let application to call respective one if HW support is not present or not adequate. I will work towards this theme in RFC v2. > > Some of these thoughts are reflected in the eventdev_pipeline app[1] that > Harry submitted earlier today, like flexible service function deployment. In > that app, the user supplies a device coremask that can pin a service function > to a core, multiplex multiple functions on the core, or even affinitize the > service function to multiple cores (using cmpset-based exclusion to ensure > it's executed by one lcore at a time). Thanks for the sample application.I could make it work with NIC + HW eventdev with some tweaking. I will send the review comment on that email thread. One thing, I noticed with cmpset based scheme is that, at given point of time it can produce at most up to the events one LCORE can support.May not be well suited for low end cores.I think, we need multiple event producer strategy code as common code. > In thinking about this, Narender and I have envisioned something like a > framework for eventdev applications in which these service functions can be > registered and (in a similar manner to eventdev_pipeline's service functions) > executed. That will be useful. I think it will be not just restricted to eventdev applications, I guess, New traffic manager's SW implementation or any future offloads need a framework for service function registration and invocation. > > Thanks, > Gage > > [1] http://dpdk.org/ml/archives/dev/2017-April/064511.html
