On 10 September 2017 at 22:26, Brian Brooks <brian.bro...@linaro.org> wrote:
> Honnappa,
>
> Could your proposal be simplified to: MT-safe pktio should be
> deprecated because it is not a common use case. Applications will
> either use MT-unsafe pktio or the MT-safe scheduler.
Not sure about deprecation. Looks like there is some history to this
feature, we need to consider all of that.
>
>> 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.
>
> Absence of MT-safe does not require 1:1 mapping of thread to pktio. It
> just means that it is the application's responsibility to ensure
> exclusive access to a pktio.
>
>> for high throughput packet I/Os [..] we do not need to support
>> ODP_PKTIO_OP_MT_SAFE
>> We could keep the support for ODP_PKTIO_OP_MT_SAFE for other pkt I/Os.
>
> This would introduce an undesirable leaky abstraction.
>
> BB
>
> On Sun, Sep 10, 2017 at 12:40 PM, Bill Fischofer
> <bill.fischo...@linaro.org> wrote:
>> 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
