On 31/05/2017, 12:18, "Elo, Matias (Nokia - FI/Espoo)" <[email protected]> wrote:
> >> On 31 May 2017, at 12:04, Ola Liljedahl <[email protected]> wrote: >> >> >> >> On 31/05/2017, 10:38, "Peltonen, Janne (Nokia - FI/Espoo)" >> <[email protected]> wrote: >> >>> >>> >>> Ola Liljedahl wrote: >>>> On 23/05/2017, 16:49, "Peltonen, Janne (Nokia - FI/Espoo)" >>>> <[email protected]> wrote: >>>> >>>> >>>>> >>>>>> +static int ord_enq_multi(uint32_t queue_index, void *p_buf_hdr[], >>>>>> + int num, int *ret) >>>>>> +{ >>>>>> + (void)queue_index; >>>>>> + (void)p_buf_hdr; >>>>>> + (void)num; >>>>>> + (void)ret; >>>>>> + return 0; >>>>>> +} >>>>> >>>>> How is packet order maintained when enqueuing packets read from an >>>> ordered >>>>> queue to a pktout queue? Matias' recent fix uses the ord_enq_multi >>>>> scheduler >>>>> function for that, but this version does not do any ordering. Or is >>>>>the >>>>> ordering guaranteed by some other means? >>>> The scalable scheduler standard queue enqueue function also handles >>>> ordered queues. odp_queue_scalable.c can refer to the same >>>> thread-specific >>>> data as odp_schedule_scalable.c so we don¹t need this internal >>>> interface. >>>> We could perhaps adapt the code to use this interface but I think this >>>> interface is just an artefact of the implementation of the default >>>> queues/scheduler. >>> >>> The problem is that odp_pktout_queue_config() sets qentry->s.enqueue >>> to pktout_enqueue() and that does not have any of the scalable >>>scheduler >>> specific magic that odp_queue_scalable.c:queue_enq{_multi}() has. So >>> ordering does not happen for pktout queues even if it works for other >>> queues, right? >> This must be a recent change, it doesn’t look like that in the working >> branch we are using. >> I see the code when changing to the master branch. >> The code in pktout_enqueue() does look like a hack: >> if (sched_fn->ord_enq_multi(qentry->s.index, (void **)buf_hdr, >> len, &nbr)) >> A cast to “void **”??? >> >> What’s the purpose of calling ord_enq_multi() here? To save (stash) >> packets if the thread is out-of-order? >> And when the thread is in-order, it is re-enqueueing the packets which >> again will invoke pktout_enqueue/pktout_enq_multi but this time >> ord_enq_multi() will not save the packets, instead they will actually be >> transmitted by odp_pktout_send()? >> > >Since transmitting packets may fail, out-of-order packets cannot be >stashed here. You mean that the TX queue of the pktio might be full so not all packets will actually be enqueued for transmission. This is an interesting case but is it a must to know how many packets are actually accepted? Packets can always be dropped without notice, the question is from which point this is acceptable. If packets enqueued onto a pktout (egress) queue are accepted, this means that they must also be put onto the driver TX queue (as done by odp_pktout_send)? >With the current scheduler implementation sched_fn->ord_enq_multi() waits >until >in-order and always returns 0 (in case of pktout queue). After this >odp_pktout_send() >is called. > >-Matias >
