It looks fine to me. On 5/19/15, 7:31 AM, "Richardson, Bruce" <bruce.richardson at intel.com> wrote:
>On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote: >> Hi all, >> >> after a small amount of offline discussion with Marc Sune, here is an >> alternative proposal for a higher-level interface - aka pktdev - to >>allow a >> common Rx/Tx API across device types handling mbufs [for now, ethdev, >>ring >> and KNI]. The key code is in the first patch fo the set - the second is >>an >> example of a trivial usecase. >> >> What is different about this to previously: >> * wrapper class, so no changes to any existing ring, ethdev >>implementations >> * use of function pointers for RX/TX with an API that maps to ethdev >> - this means there is little/no additional overhead for ethdev calls >> - inline special case for rings, to accelerate that. Since we are at >>a >> higher level, we can special case process some things if >>appropriate. This >> means the impact to ring ops is one (predictable) branch per burst >> * elimination of the queue abstraction. For the ring and KNI, there is >>no >> concept of queues, so we just wrap the functions directly (no need >>even for >> wrapper functions, the api's match so we can call directly). This also >> means: >> - adding in features per-queue, is far easier as we don't need to >>worry about >> having arrays of multiple queues. For example: >> - adding in buffering on TX (or RX) is easier since again we only >>have a >> single queue. >> * thread safety is made easier using a wrapper. For a MP ring, we can >>create >> multiple pktdevs around it, and each thread will then be able to use >>their >> own copy, with their own buffering etc. >> >> However, at this point, I'm just looking for general feedback on this >>as an >> approach. I think it's quite flexible - even more so than the earlier >>proposal >> we had. It's less proscriptive and doesn't make any demands on any >>other libs. >> >> Comments/thoughts welcome. >> >> Bruce Richardson (2): >> Add example pktdev implementation >> example app showing pktdevs used in a chain >> > >Any comments on this RFC before I see about investing further time in it >to clean >it up a bit and submit as a non-RFC patchset for merge in 2.1? > >/Bruce
