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 F0E85A0530 for ; Thu, 23 Jan 2020 19:23:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EF29B378B; Thu, 23 Jan 2020 19:23:49 +0100 (CET) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by dpdk.org (Postfix) with ESMTP id D8E0C2A6C; Thu, 23 Jan 2020 19:23:46 +0100 (CET) Received: by mail-qt1-f181.google.com with SMTP id i13so3246594qtr.3; Thu, 23 Jan 2020 10:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aOe2mpE9EoAA+5lf04J8sn9j9sHXAkj+zt7upXixKao=; b=VZs+24lFZ+/FiHBPLhcR+V88M8aHsmKsxerMpbEDQf8JZNPIf3Ixt9stpzKpHN1fba 6TYN5uoc4bpRxA3yrJUysF7lS2VoVsoRe92r/zkEmien4qaiq09HIq5k75i8XR9RZnSp AXa3shNnm/4rWKVlxLejSlcb3KUGd409MPSLTHUP43EA8zrw5lues0D6pL5FKPNJYSeZ 4za7nZXlal3QjEULQznGqqCbJdaKMUW86NaVhxj72AWw7Vt8wFtkpKid5ttTpmg5leTI zXfJgDEG76fQ15PoftNNP86NIQPzATQlpije45WbZ22sr0hAWOPwlC/8/R0D7HjiF7jc ElAg== 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=aOe2mpE9EoAA+5lf04J8sn9j9sHXAkj+zt7upXixKao=; b=GRUw9bn2FeJLMHIerk3ArISDYlnopMleZFi1AHZXcrMCR6iIXmMyR+sRlvBjqvIxBJ cIAH28ItrqUxakHO1z3uchVdKcLqhOAFZM1iP97OTS14fuFzoVOy0g0EdBRzEaPH2LLQ NkTZFVgBqEWSRCK4fp5hsexKWhSCqMz/P32R8k51ZNC7aDpjmegMPs4cZFxZq5xfQCGn HyneV3qVgXeCXGze2pM443u7ODKhfQocBWVAtY98VKwb2Z816itASESg338uvBOfJ5Nq yqt4EUi9479b98c9wHGanNfvQrxCQHaRaV5ooa5mjxDFC2VUozhwY8kkUnl8QX79UUq4 iIKA== X-Gm-Message-State: APjAAAUf1axpXIluSJR1Nt2qCK9p5/IM0YnCPW/TfbA83XWTtF0GHBxK QjQPSIUPL9MzWfW1KronUpJ1CQh/DcbawJKrE3QEQXL4 X-Google-Smtp-Source: APXvYqzmp6eJRSW3Md1LTC0lwg+NqFy+8TzGZ5Fu1lyspukS9nGWyBXs0krcFDl8swJXfYbh+bmd8iCLc5PnbnaCrH0= X-Received: by 2002:ac8:2bf9:: with SMTP id n54mr17473185qtn.280.1579803826211; Thu, 23 Jan 2020 10:23:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Zain-ul-Abideen Date: Thu, 23 Jan 2020 23:23:34 +0500 Message-ID: To: Suraj R Gupta Cc: dev@dpdk.org, users 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" I see the current implementation doesn't cater for this escape sequence. U have to implement a little logic to traverse through the empty buffs w.r.t. current packets in buffer via some count. On Thu, Jan 23, 2020, 10:54 PM Suraj R Gupta wrote: > 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 >