From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6B32BA0571; Tue, 3 Mar 2020 13:50:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A07DC1BFEF; Tue, 3 Mar 2020 13:50:36 +0100 (CET) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by dpdk.org (Postfix) with ESMTP id B4B271BFE9 for ; Tue, 3 Mar 2020 13:50:35 +0100 (CET) Received: by mail-wr1-f51.google.com with SMTP id h9so3217800wrr.10 for ; Tue, 03 Mar 2020 04:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nitk-edu-in.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oVZkR5K+/Jwqp2/jhEs1t6MOTyCaH8FPpdxECY2LKyI=; b=Xjj/xv1ldlnq5BB+1L5O4bjQzuTbIoMWOJngJMb/iFoJxAKsuDnnocuZOTptweMSfH 7+h/lY1hGJw3BG+LSVFt9LW5mRwQKsdGYHGZTAMB4SkQWLa/1w/yK/J+ZiV9D4hFWOb7 UPVilNaRNT9Xdr/CyWV1dmdQZ8mA/jcbNYCbMnEWBkV4yKYYRc1j1u0IrVxo3zqZcsSc gJXcu+T0j2rhSGRR/aJtnFGyroCbViFH5gie6Dsp9+GSq6moHKrNZgY8q4SpagH9Xl72 NS4YWZfm9o18hu2wf73QClM2pUPLULaKm5iB+3C4AaouMNk01t96c36TEqSnLuYgsfvT 8PNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oVZkR5K+/Jwqp2/jhEs1t6MOTyCaH8FPpdxECY2LKyI=; b=pXcFr5Deuugeul6PVtSx69Ie+biHhwNkYcdH8jghD7Fp7PY4K1SW/OEoSLP35ST1YJ i9LnhF9IXmZ03jDi66Ri6pUQIC7sTVThZk7xcrQrHZOROlHQzHxScqwwlYcR+ZGWvwfq 4g/WEdgsAShL3bES2mUJPwB2yxJsoqdSaq1R0yFaCBqF57QbB/LUnKJF3Zradqh/Ogk+ 744AJvSSefpzj961jbh61CzQfZJfgTOtB0uPbLR6yn5bJVgzmnb332nnRSmgyBSBcmum 21T5PxCzKYdHxKTg/IK2kH521NGfmzho4yoE1TiGyvsrjMlD8flDQsK703/N/kv94hHb qdKA== X-Gm-Message-State: ANhLgQ3StdZvBKaNZMmBiqiutgJDESx9ZGCpJossr/oxdY/cHNgJnF+k f978gtttj5F0yxs7giLPxuqaM3uzQI7a7HQpps+c3A== X-Google-Smtp-Source: ADFU+vsfvLE99MDJMbbXePRiSCs4k8tQ1G32c+r7CAfcCyJAHTqun88aPCEprJLhRV2K2tOMn55ZEZFBq0UB7PVwj+Y= X-Received: by 2002:adf:94a3:: with SMTP id 32mr5804958wrr.276.1583239834612; Tue, 03 Mar 2020 04:50:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Avinash ." Date: Tue, 3 Mar 2020 18:20:23 +0530 Message-ID: To: "Singh, Jasvinder" Cc: "dev@dpdk.org" , Gokul Bargaje , "Mohit P. Tahiliani" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] DPDK Enqueue Pipeline X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thank you for the clarification. I was trying to get the queue and traffic class information from where the packet is going to be dequeued. Its resolved now. Regards Avinash On Fri, Feb 28, 2020 at 7:09 PM Singh, Jasvinder wrote: > > > > -----Original Message----- > > From: dev On Behalf Of Avinash . > > Sent: Wednesday, February 26, 2020 10:46 AM > > To: dev@dpdk.org > > Cc: Gokul Bargaje ; Mohit P. Tahiliani > > > > Subject: [dpdk-dev] DPDK Enqueue Pipeline > > > > Hi all, > > The DPDK QoS scheduler has a 4-stage pipeline for enqueuing the packets. > > This is used for hiding the latency of prefetching the data structures. > > Why is there no pipeline for dequeuing the packets? > > The dequeue operation happens in stages that involves scanning bitmap > (that contains the active pipes info), followed by extracting information > about TC and queue of the pipe that will be considered for scheduling. As a > result, the information about pipe TC and queue become > available but not exposed to the application as this is internal to > dequeue operation. > > > How does the dequeue function maintain the state of a packet? In other > > words, if I want to backtrace the packet that is dequeued to get the > info of > > what was the traffic class and from which queue the packet was dequeued. > > Is there any way to get this. > > > The QoS dequeue operation is built around multiple grinders (packet > crunching engines) that works on different pipes at a time. Each grinder > follows the state machine (please have a look at the documentation) which > contains multiple stages starting from pipe bitmap scanning, tc and queue > detection, fetching the packet from the queue based on the available > credits, etc, all this information is kept in internal data structure of > the scheduler, and that info can be used to understand the flow or debug > the code. why you want to expose that intermediate info through public API > during execution? > > > > Regards > > > > -- > > Avinash >