Hi,
There is the case where a a pktio has less pktins than available
cores. It is a valid case? We want to support it?
For example: 4 pktins and 8 cores... or default (socket) pktio with
one pktin/one pktout?
Best regards,
Bogdan
On 11 September 2017 at 11:33, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 11 September 2017 at 06: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.
>>
>> > 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.
>>
>
>
> That is not always a case. One pktio can be used in several working
> threads. For that case safe is needed.
>
> All modes are:
> /**
> * Packet input mode
> */
> typedef enum odp_pktin_mode_t {
> /** Direct packet input from the interface */
> ODP_PKTIN_MODE_DIRECT = 0,
> /** Packet input through scheduler and scheduled event queues */
> ODP_PKTIN_MODE_SCHED,
> /** Packet input through plain event queues */
> ODP_PKTIN_MODE_QUEUE,
> /** Application will never receive from this interface */
> ODP_PKTIN_MODE_DISABLED
> } odp_pktin_mode_t;
>
> /**
> * Packet output mode
> */
> typedef enum odp_pktout_mode_t {
> /** Direct packet output on the interface */
> ODP_PKTOUT_MODE_DIRECT = 0,
> /** Packet output through event queues */
> ODP_PKTOUT_MODE_QUEUE,
> /** Packet output through traffic manager API */
> ODP_PKTOUT_MODE_TM,
> /** Application will never send to this interface */
> ODP_PKTOUT_MODE_DISABLED
> } odp_pktout_mode_t;
>
>
> For DIRECT, QUEUE and TM implementation can have different optimization
> regrades is the same pktio or in/out queue connected to that pktio used in
> single thread or shared between threads. Application can not provide
> synchronization in that case because locking should be done on low level
> for some short period of time. Locking ODP calls will significantly slow
> down data path functions.
>
> Best regards,
> Maxim.
>
>
>
>
>>
>> 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
>>
