Why using a HW feature (which was not an error in the HW designers view) would be considered a "programming" error? My understanding is that ODP is about programming the networking SoC and what is commonly supported by different HW platforms should be also supported by ODP.
Alex On 28 November 2014 at 16:10, Taras Kondratiuk <[email protected]> wrote: > On 11/28/2014 01:47 PM, Stuart Haslam wrote: > >> On Fri, Nov 28, 2014 at 09:48:29AM +0000, Alexandru Badicioiu wrote: >> >>> >>> >>> On 27 November 2014 at 18:56, Stuart Haslam <[email protected] >>> <mailto:[email protected]>> wrote: >>> Attempts to enq to a pktin queue or deq from a pktout queue are >>> programming errors, so abort. >>> [Alex] Is this an ODP convention valid for all implementations? I f we >>> talk about HW I think these are debatable and SoC dependent. >>> In the most general case a queue may have multiple producers and >>> multiple consumers. For example FSL DPAA does not impose any restriction on >>> enqueue - any accelerator(port) or core can enqueue on any queue by placing >>> commands to Queue manager block. However, on dequeue, for pktout queues >>> (assumed to be consumed by a singleTx port) only the port can dequeue. >>> >>> >> Behaviour needs to be consistent across implementations so if there are >> valid use cases for enqueue to a pktio inq, and they can be supported, >> we need to define the semantics as it's currently not clear. >> >> Taras, I see the keystone implementation currently doesn't support >> enqueue to a pktio inq, is that because the platform doesn't support it >> or it's just not implemented? >> > > It is not implemented, because I've considered it as a programming > error. There is no limitation in HW, just packet should be formatted > properly, to be correctly handled by dequeue function. >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
