On 11 September 2017 at 12:11, Bogdan Pricope <bogdan.pric...@linaro.org>
wrote:
> 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
>
I think - yes, there should not be limitation.
Maxim.
>
> 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
> >>
>
