We can discuss this during tomorrow's ARCH call, and probably further
at Connect. MT Safe is the default behavior and it's opposite ("MT
Unsafe") was added as a potential optimization when applications
assure implementations that only a single thread will be polling a
PktIn queue or adding to a Pktout queue.Ideally, we'd like to retire all application I/O polling and use the scheduler exclusively, but that's that's a longer-term goal. For now we have both. On Sun, Sep 10, 2017 at 8:11 AM, Honnappa Nagarahalli <honnappa.nagaraha...@linaro.org> wrote: > Hi, > I think there are 2 ways in which pkt I/O will be used: > > 1) Polling method - in which one pkt I/O will be created for each > receive worker thread. In this case, support for ODP_PKTIO_OP_MT_SAFE > is not required. > 2) Event method - the scheduler is used to receive packets. In this > case the scheduler will provide the exclusive access to a pkt I/O. > Again in this case support for ODP_PKTIO_OP_MT_SAFE is not required. > > I am thinking, for high throughput packet I/Os such as dpdk or ODP > native drivers (in the future), we do not need to support > ODP_PKTIO_OP_MT_SAFE. The odp_pktio_open API call can return an error > if ODP_PKTIO_OP_MT_SAFE is asked for. > > We could keep the support for ODP_PKTIO_OP_MT_SAFE for other pkt I/Os. > > This will save space in cache for the locks as well as instruction cycles. > > Thank you, > Honnappa
