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 69197A0533; Thu, 23 Jan 2020 18:53:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0801C2A6C; Thu, 23 Jan 2020 18:53:53 +0100 (CET) Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by dpdk.org (Postfix) with ESMTP id 47E9F2A62 for ; Thu, 23 Jan 2020 18:53:51 +0100 (CET) Received: by mail-qv1-f49.google.com with SMTP id x1so1883430qvr.8 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=okGUwJUZA7cPHRd9Br8gZlm7RKDPSZr8tw0h2ihjgzTUIF9Voh4ZMm00+ZvU/7RT/h ow3OZ3501WJk7Eh0cS5cVYb8vdc1Xew5c/1orf6FzxL1eeN8QB0BX5xpikrjGz5Yx3Ix aEouGdac5BVyPGkbdzpu+3TKq5QXJdk6cg5dBwFEiTZwcaPfRBw2g1mVdqux/t0PItcj L4CHhPGXCs5xSPrZ5itoKmhhoxVlNW2kMJSCZJk5mzIjdc7lPf2UIGCVDlSO+4nI4Pds X+3jdpr1ePx/l8ruSYPY4qzkZCpBSd41rMNrB2+w3gkMcaELTPKbsSAzkCy07xINGYtk yqeg== X-Gm-Message-State: APjAAAXIHglEla+u0UztmAArU/T3BPmIscX0nLLCAO3hdITUMU3LJBlT SxaaMN7VRHp0J7bnx+lzUNP8FHC6u2n+eA/gTr3TCAfC 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-dev] [dpdk-users] Issue in draining packets when head is null 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" 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