Hi guys, Why would you want to deprecate odp_pktio_<recv/send> This maps so neatly over the 'basic' way the packets can be obtained from hardware and sent to the hardware. What if I don't want to use queues and just want an interface to get packets into my application and send from there. The odp_pktio_<recv/send> is an abstraction over whatever be the hardware underneath -- isn't that the ODP philosophy.
Normally all the data plane fast path applications have a high speed polling loop for packets coming from the chip. And ofcourse there has to be a function to dispatch the packet from the chip. In my opinion the 'pktio' is a hardware abstraction and the 'send/recv' are the two very basic/primitive API's which should be supported by ODP. If there are chips which don't support the above paradigm, then so be it, the backend drivers for those chips can leave these functions blank. I am trying to imagine what kind of a chip it is which does not have a way to poll for a packet and send a packet out. I am sure there a lot of applications out there (including mine) which use the odp_pktio_<recv/send> and they will get disturbed with your deprecating this api (and eventually removing it) Regards -Prashant -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stuart Haslam Sent: Friday, November 28, 2014 5:11 PM To: Venkatesh Vivekanandan Cc: lng-odp-forward Subject: Re: [lng-odp] odp_pktio_<recv/send> On Fri, Nov 28, 2014 at 05:53:07AM +0000, Venkatesh Vivekanandan wrote: > Hi Stuart/Petri, > > I couldn't find odp_pktio_<recv/send> in recent pktio design doc. Are we > deprecating these API's? Yes, at least that's what I'm suggesting. >Are we deprecating the burst mode that is currently supported in pktio/l2fwd >applications?. No, they'd be modified to use polled queues and odp_queue_deq_multi(). I think odp_pktio_recv/send were never really intended to be part of the API and they don't fit with the intended ODP push/pull execution models. Also direct I/O (without queues) isn't supported on many of the target platforms, so they'd either not be able to support these APIs or would need a software layer on top of the queue APIs. > > Thanks, > Venkatesh. -- Stuart. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
