From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com
 [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 17EF39A97
 for <dev@dpdk.org>; Wed, 11 Mar 2015 00:54:05 +0100 (CET)
Received: by pdbfp1 with SMTP id fp1so6231067pdb.2
 for <dev@dpdk.org>; Tue, 10 Mar 2015 16:54:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=SskVpjxXRt2smDz1zjKtiTslNoRkuJQ5AF4boFsSes4=;
 b=FPjlJUA8EIR28UBPvubZZ5rL2Ar9SzwklMw9kGKhfugcmnVsaZh9/oCy3D/XsrTOwp
 nesFqX5gKoQ/pzeDoHVnMNWQ47PyfJ2l85We8imMNxXhYTqZ1Hp7WTpHrQdmqh/3IXIY
 5SllIpj/QnMgo/iWkOV8OZu8cO/UU6RYYOOVCLyJ0dqg9QbuEpRfNdsUbhIGToOcs4hx
 hCbohWhxuPjMxMrwcRioxDOJx4prBGk98AF59zlmggJWx2jRGfalU/+OecyqBzR5xcTY
 qKIQwdFv0wMXP/0aFpQzMaDNA/MX0BYJi0jTWEVPNghKmNS17Cshl7W0Ui1yK8hWV2Ca
 yOWQ==
X-Gm-Message-State: ALoCoQmHMFMhmfptyYS+cq4iKib+tPvqtTD4uIAgmPgTwtscvm8sU0cUiwaJcGowvPwg0MFVm7FZ
X-Received: by 10.67.3.196 with SMTP id by4mr71519976pad.74.1426031644359;
 Tue, 10 Mar 2015 16:54:04 -0700 (PDT)
Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net.
 [50.53.82.155])
 by mx.google.com with ESMTPSA id q6sm2842804pdr.35.2015.03.10.16.54.03
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 10 Mar 2015 16:54:03 -0700 (PDT)
Date: Tue, 10 Mar 2015 11:35:59 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Yong Wang <yongwang@vmware.com>
Message-ID: <20150310113559.4073f04f@urahara>
In-Reply-To: <D1237B72.39F61%yongwang@vmware.com>
References: <1425600635-20628-1-git-send-email-stephen@networkplumber.org>
 <1425600635-20628-8-git-send-email-stephen@networkplumber.org>
 <D1237604.39F07%yongwang@vmware.com>
 <D1237B72.39F61%yongwang@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, Stephen Hemminger <shemming@brocade.com>
Subject: Re: [dpdk-dev] [PATCH v3 07/10] vmxnet3: support jumbo frames
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2015 23:54:05 -0000

On Mon, 9 Mar 2015 23:32:48 +0000
Yong Wang <yongwang@vmware.com> wrote:

> >
> >I didn=E2=80=99t see where mtu is used to calculate how many rx descript=
ors will
> >be needed for each packet.  Furthermore, as pointed out by the following
> >code comments, the device requires the first rx buffer of a packet be of
> >type VMXNET3_RXD_BTYPE_HEAD with the remaining buffers of type
> >VMXNET3_RXD_BTYPE_NODY.  This needs to be taken care of when populating =
rx
> >rings in vmxnet3_post_rx_bufs(). Currently we don=E2=80=99t do this beca=
use no
> >scatter-rx is supported and only one descriptor is needed for a packet
> >(thus all types should be HEAD). Otherwise, the device will complain wit=
h =20
>=20
> To clarify, in this case only the 1st ring will be used and thus all types
> will be HEAD.
>=20
> >error returned.  For the 2nd rx ring, type needs to be BODY for all
> >descriptors still.

Looking in more detail, the code as submitted looks fine:

* The # of rx descriptors needed for each packet is responsibility of
  the application. Before and after this patch the # of Rx descriptors
  for each ring (head/body) is determined by vmxnet3_rx_queue_setup.
  And the driver always allocates the same number of descriptors
  for both Rx rings.

  One could argue that was a bug in the original driver, since it needlessly
  allocated mbufs for the second ring and never used them. I suppose
  as a optimization in future, the second ring could be sized as 0
  and no buffers allocated unless doing rx-scatter (this is what the
  Linux driver does. But that change is independent of this.

* Buffers are correctly reallocated as needed when consumed.

* The code works for bulk transfer and performance tests in jumbo mode.

I see no requirement to change this patch.
 =20