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 > >> >