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 E94DCA0533 for ; Thu, 23 Jan 2020 18:54:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5C87C343C; Thu, 23 Jan 2020 18:53:56 +0100 (CET) Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) by dpdk.org (Postfix) with ESMTP id 4D4192A6C for ; Thu, 23 Jan 2020 18:53:51 +0100 (CET) Received: by mail-qv1-f48.google.com with SMTP id dp13so1898632qvb.7 for ; Thu, 23 Jan 2020 09:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iith.ac.in; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YRAH4fLT8ZctE9rtkz4T36Cer70NI9ryP5FC5fUCsD8=; b=ZmZqKVVaZKk48nzAwZT3yECOnKGlfpXRYlr3ghBExjveGjGZiILW1S21LCmT5zbWY4 vkKdBhPlm8Jem+61bdgJueAcjW2Sz8lleKzpvYM4wDI1iVn67qHFV+K/gtybWWXnpgiI O9DC9NNG+ee6GZhhIRfYQsoWuI/uw9kLdkH+w= 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=YRAH4fLT8ZctE9rtkz4T36Cer70NI9ryP5FC5fUCsD8=; b=kM0IqASp+Wr2gB8D4lvMpuftfwNhBa2aK7Y5GxxwtOuDbgNEulNnIbZclnzMnHDWKr VY/5eBiJwVz8BwqaaBOeaC++RIVOUG3pqS3MTkkBP4ElBJhFusyuGzfY3jU9wkpwiXf4 zKQHV1Yd8Vz8zlOivxr+pNus3eleOqngAcyu9Dqvlezv/1XQ5J+b2gNyhhDHI3TSTzui imbJ9LUWeYmmr9P7OxEDL0dV+1YKotJj75msPB3iAx7/tQqDhA3XzQaT2jyl5BOm0AVD nN1q9cg4+ytjz6uQmO89q+LyjMhJqdBxLy6I8sUeN/e4Vgdgu5QRokURXookP4h8N5qq Pz6A== X-Gm-Message-State: APjAAAXYbqgYm9eaDpYDf1p+XeBaGS+LoZJEIlEuvL4AMV1+sH4Apr9f hXUkehEBtlwNOBpLLUHKCjs/Fpz8TMS9b+8Fr6bDXw== X-Google-Smtp-Source: APXvYqzgxVtdCNxqeCFtn/4hRANAkeO/iolasp2MHDsHCM0sRHp2yFc9slK9fyeH3dJRl6mf+nbd9+HcauqfiLdlzb4= X-Received: by 2002:ad4:4389:: with SMTP id s9mr16635254qvr.99.1579802030176; Thu, 23 Jan 2020 09:53:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suraj R Gupta Date: Thu, 23 Jan 2020 23:23:37 +0530 Message-ID: To: dev@dpdk.org Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] [dpdk-dev] Issue in draining packets when head is null X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Folks, Any Ideas on this. On Mon, Jan 13, 2020 at 1:04 PM Suraj R Gupta wrote: > Hi all, > This is regarding an issue in the draining packet using rte_reorder_drain. > Suppose we have a window size of 16 and we get packets with sequence no > like 0,1,2,4,5,6. On performing drain operation, I retrieve packets like > 0,1,2. > Since now order_buf->entries[order_buf->head] i.e. order_buf->entries[3] > is null i won't be able to any more like 4,5,6. I would be able to do it > only when I get at a packet with a sequence number above window size. This > may be highly undesirable if we have large window sizes say 1024, 2048, > etc. we wouldn't be able to drain any more packets until a packet above > window size is received. Also since the struct rte_rorder_buffer are > defined in the source .c file, we are not able to move head of buffer from > applications. *Is there any specific reasons why it is implemented like > this in the library. Are there any ways to overcome this.* > -- > Thanks and Regards > Suraj R Gupta > -- Thanks and Regards Suraj R Gupta