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 ACA62A2F6B for ; Wed, 9 Oct 2019 08:11:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 683681C134; Wed, 9 Oct 2019 08:11:58 +0200 (CEST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by dpdk.org (Postfix) with ESMTP id 8EDD11C132 for ; Wed, 9 Oct 2019 08:11:57 +0200 (CEST) Received: by mail-vk1-f170.google.com with SMTP id w3so292164vkm.3 for ; Tue, 08 Oct 2019 23:11:57 -0700 (PDT) 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=9GgtQg37EWA3BZya9HKxVxGEFY4lPOCXiOD2hYfZMro=; b=Esdqr9R1tALw0vKVAtWIcFqTBk+Bw1vvooNFCSxfCEKBYqsAOaYKdTtUXAVMvIiEol Kphv45Ji8uiGXibHqJgUJQwxSQAxCVu6PKMgx5KSqxJMe88JU5sARZTWS6N+f4PSVFDu t7dSI1pB1pnslhUo5HgNmfx64/ZSk1k577bKEmaY0JWBFPscFBe0AeSOx/A5xpfIRJIt PYKI0vt2dHdxR1kLfKht4xTFzOQLFxJiDotQpMhmvAnVmYXVrX+THxL8YGmNj/aApw/e z2DncLWMD2jkNULnV0jYJo3J8dGz1O5SIeXc/YS6QVz79qwPNI+qkf4+1fvubaN4ZkM+ k+ZQ== 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=9GgtQg37EWA3BZya9HKxVxGEFY4lPOCXiOD2hYfZMro=; b=ta8WcIQD8Ywx/ytDF5b53TI8Pn/a7P4Jeb05oh94e+Vam3l95ee0ZmVIvZMTo82ucH bMluLcCBilEAVJdJ4lw3rqyu9DaQA8HN5cz0yvoSFQovZhvyNcP68bw/aVrL27DuhMws 2QIWNWcKENGq9dt6WORHpuNrNkQxiUQBXiv5M599xzYApTlsBiSPot0+AvDeF8mGrq9M HnbcXp+GH7HXW3Q4q4OWveuustikQkRcLnvkiMWFhnx6ruLdw4DHgRLLC1eN7MPazh2h 6iFVSaFmuRw+mvi+So6kG3qVP0Y5k7z5hm6TXABAONn6GS2QHNOn2NfA/dYI8TbCIQaY ChvQ== X-Gm-Message-State: APjAAAUs9BGVDxYXWEw+eVcxtLr+XQqkpfdklIsQaN3aHCuJHdmagOS4 8JYwXXlZAjCj9gNIEqDTa4vsCw7v/p3Z244lTOsKCHkC X-Google-Smtp-Source: APXvYqyHVUs1a01vt5iziG5KlnCx6H6geKfbZBNoRhfpdQuSUCpyB4J1yFXBFusrmx51TzXMoyPsYIHjJrbcpdIQ++c= X-Received: by 2002:a1f:1881:: with SMTP id 123mr1173546vky.26.1570601516759; Tue, 08 Oct 2019 23:11:56 -0700 (PDT) MIME-Version: 1.0 References: <20190925221637.11fb9632@hermes.lan> <20190930075938.77a2c70d@hermes.lan> In-Reply-To: <20190930075938.77a2c70d@hermes.lan> From: Gaurav Bansal Date: Wed, 9 Oct 2019 11:41:43 +0530 Message-ID: To: Stephen Hemminger Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] packet drops with missing rxdIdx count in vmxnet3 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" Hi Stephen, Thanks for the reply. Does that mean receive index skip is expected in case a packet spans across multiple segments ? I am seeing following behaviour : We receive the packets in vmxnet3_recv_pkts function... this is done by checking gen bits (in a while loop). For each packet received, we increment next2proc in comp_ring and then fetch rxdIdx using next2proc value as follows : rcd = &rxq->comp_ring.base[rxq->comp_ring.next2proc].rcd; idx = rcd->rxdIdx; Now for the case when i am seeing packet drops, next2proc is getting incremented by 1 but rxdIdx gets incremented by 2. This is seen by printing the following in gdb : p rxq->comp_ring.next2proc p rxq->comp_ring.base[rxq->comp_ring.next2proc].rcd.rxdIdx $1094 = *262* $1095 = *6* //for next packet $1099 = *263* $1100 = *8* Is this too an expected behaviour ? In that case how we will receive the packet with rxdIdx = 7 ? thanks, gaurav On Mon, Sep 30, 2019 at 8:29 PM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Mon, 30 Sep 2019 11:22:19 +0530 > Gaurav Bansal wrote: > > > hi all, > > havn't heard back on this so far. Can anyone please let me know of the > > possible reasons for the NIC to skip some of the indexes of the > descriptor > > ring in the Rx path (as also shown by the vmxnet3 logs in my previous > mail) > > ? > > thanks, > > gaurav > > > > A packet can span multiple segments if your receive mbuf is too small to > fit > all the data. That would cause the receive data to create a chained mbuf. > > >